Michael Hoffman wrote:
> Reinhold Birkenfeld wrote:
>
>> It's much the same as with @ decorators. Those who have used them much
>> don't object to the syntax any more.
>
> I do and I still think they are ugly.
Shouldn't have generalized that. Add "most of" where you like.
Reinhold
--
http://ma
Reinhold Birkenfeld wrote:
> It's much the same as with @ decorators. Those who have used them much
> don't object to the syntax any more.
I do and I still think they are ugly.
--
Michael Hoffman
--
http://mail.python.org/mailman/listinfo/python-list
NickC wrote:
> [Re: how to get at the base class]
>
> Do you really want to have a "only works for Path" way to get at the
> base class, rather than using the canonical Path.__bases__[0]?
>
> How about a new property in the os.path module instead? Something like
> os.path.path_type.
>
> Then os.
NickC wrote:
> [Re: alternatives to overloading '/']
>
> Is there a reason the Path constructor is limited to a single argument?
> If it allowed multiple arguments, the following would seem very
> straightforward:
>
> p = Path(somePath, user.getFolder(), 'archive', oldPath + ".bak")
That's a qui
NickC wrote:
> I'm usually not much of a purist, but C++ has convinced me that
> overloading an operator to mean something entirely unrelated to its
> mathematical meaning can be very unwise.
Me too. In general. I've yet to overload a single operator that way in
years of writing Python code, th
[Re: how to get at the base class]
Do you really want to have a "only works for Path" way to get at the
base class, rather than using the canonical Path.__bases__[0]?
How about a new property in the os.path module instead? Something like
os.path.path_type.
Then os.path.path_type is unicode if an
[Re: alternatives to overloading '/']
Is there a reason the Path constructor is limited to a single argument?
If it allowed multiple arguments, the following would seem very
straightforward:
p = Path(somePath, user.getFolder(), 'archive', oldPath + ".bak")
I'm usually not much of a purist, but C
Personally, I *like* the current distinction between + as a regular
string join, which gives the already much discussed benefit of allowing
paths to be dropped in seamlessly and painlessly anywhere strings are
currently used, and then having in addition the / operator for
"concatenate with a path s
Reinhold Birkenfeld wrote:
> Peter Hansen wrote:
> > Reinhold Birkenfeld wrote:
> >> One thing is still different, though: a Path instance won't compare to a
> >> regular
> >> string.
> >
> > Could you please expand on what this means? Are you referring to doing
> > < and >= type operations on Pa
