Path PEP: What should Path(None) do?

[Michael Hoffman]

Currently it returns Path('None'). This means I have to do a check on
input before pathifying it to make sure it is not None.

Perhaps it should throw ValueError?

 

[Reinhold Birkenfeld]

Currently it returns Path('None'). This means I have to do a check on
input before pathifying it to make sure it is not None.

Perhaps it should throw ValueError?

The problem is that Path() currently acts like str() and will therefore
accept almost anything that has a string representation.

We can do two things: 1) restrict Path.__new__ arguments to be strings
or unicode only, or 2) special-case None and what else comes in mind.

I think 1) is the proper solution. Path() is not a general stringifier
as str(), and shouldn't act like one.

Reinhold

 

[Peter Hansen]

Currently it returns Path('None'). This means I have to do a check on
input before pathifying it to make sure it is not None.

Perhaps it should throw ValueError?

Without checking, I suspect it is merely doing str(x) or unicode(x) on
whatever is passed to it:
path(u'3.14159')

Therefore I think the question should be broadened beyond just None.
Should Path(x) simply call str(x) on the object or should it raise
ValueError or TypeError or something if it's not a basestring?

Given that pretty much *everything* in Python can have str() called on
it, I think we should ask for a modicum of type-safety here and reject
non-strings as input.

-Peter

 

[Reinhold Birkenfeld]

Without checking, I suspect it is merely doing str(x) or unicode(x) on
whatever is passed to it:

path(u'3.14159')

Therefore I think the question should be broadened beyond just None.
Should Path(x) simply call str(x) on the object or should it raise
ValueError or TypeError or something if it's not a basestring?

Given that pretty much *everything* in Python can have str() called on
it, I think we should ask for a modicum of type-safety here and reject
non-strings as input.

Settled.

Reinhold