Re: PRE-PEP: new Path class

Discussion in 'Python' started by Gerrit Holl, Jan 8, 2004.

  1. Gerrit Holl

    Gerrit Holl Guest

    Michael Chermside wrote:
    > I agree... paths should be immutable.
    >
    > Instead of .normalize_inplace() which changes the behavior of the
    > Path, how about .get_normalized_string() (please find a better name)
    > which allows access to the normalized version without mutating the
    > Path object? (Or perhaps it should be .get_normalized_Path()... I'm
    > not sure.)


    If we make it immutable, we can simply do path.normalize(), which
    returns the normalized path. Or am I overlooking something?

    yours,
    Gerrit.

    --
    147. If she have not borne him children, then her mistress may sell her
    for money.
    -- 1780 BC, Hammurabi, Code of Law
    --
    PrePEP: Builtin path type
    http://people.nl.linux.org/~gerrit/creaties/path/pep-xxxx.html
    Asperger's Syndrome - a personal approach:
    http://people.nl.linux.org/~gerrit/english/
    Gerrit Holl, Jan 8, 2004
    #1
    1. Advertising

  2. Gerrit Holl

    Peter Hansen Guest

    Gerrit Holl wrote:
    >
    > Michael Chermside wrote:
    > > I agree... paths should be immutable.
    > >
    > > Instead of .normalize_inplace() which changes the behavior of the
    > > Path, how about .get_normalized_string() (please find a better name)
    > > which allows access to the normalized version without mutating the
    > > Path object? (Or perhaps it should be .get_normalized_Path()... I'm
    > > not sure.)

    >
    > If we make it immutable, we can simply do path.normalize(), which
    > returns the normalized path. Or am I overlooking something?


    I haven't been following (either discussion) closely, but this sounds similar
    to some posts I read about a discussing involved a .reverse() method, and
    the apparent conclusion that .reversed() [note the 'd'] was more appropriate
    as it didn't imply that the object was being modified in-place, but that
    it was returning a reversed version of itself. Same thing could apply here...

    -Peter
    Peter Hansen, Jan 8, 2004
    #2
    1. Advertising

  3. Gerrit Holl

    Syver Enstad Guest

    Peter Hansen <> writes:

    > I haven't been following (either discussion) closely, but this
    > sounds similar to some posts I read about a discussing involved a
    > .reverse() method, and the apparent conclusion that .reversed()
    > [note the 'd'] was more appropriate as it didn't imply that the
    > object was being modified in-place, but that it was returning a
    > reversed version of itself. Same thing could apply here...


    Good point, but what about asNormalized() or asReversed()? Or
    as_reversed() or as_normalized() if that is the coding
    convention. Doesn't that communicate the intent even better?



    --

    Syver Enstad
    Syver Enstad, Jan 8, 2004
    #3
  4. Gerrit Holl

    Peter Hansen Guest

    Naming convention for non-inplace methods (was Re: PRE-PEP: new Pathclass)

    Syver Enstad wrote:
    >
    > Peter Hansen <> writes:
    >
    > > I haven't been following (either discussion) closely, but this
    > > sounds similar to some posts I read about a discussing involved a
    > > .reverse() method, and the apparent conclusion that .reversed()
    > > [note the 'd'] was more appropriate as it didn't imply that the
    > > object was being modified in-place, but that it was returning a
    > > reversed version of itself. Same thing could apply here...

    >
    > Good point, but what about asNormalized() or asReversed()? Or
    > as_reversed() or as_normalized() if that is the coding
    > convention. Doesn't that communicate the intent even better?


    I wouldn't object strenuously to any one of the three approaches,
    although the simple .normalized() and .reversed() version feels
    slightly more Pythonic to me, merely because the other two don't
    seem to be existing conventions in, say, the standard libraries.

    I'd go with whatever precedent has already been set, if one has
    been set, and otherwise open a new discussion as the topic has a
    lot of merit...

    -Peter
    Peter Hansen, Jan 8, 2004
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John Roth

    PRE-PEP: new Path class

    John Roth, Jan 5, 2004, in forum: Python
    Replies:
    31
    Views:
    736
    Christoph Becker-Freyseng
    Jan 11, 2004
  2. Michael Chermside

    PRE-PEP: new Path class

    Michael Chermside, Jan 8, 2004, in forum: Python
    Replies:
    0
    Views:
    291
    Michael Chermside
    Jan 8, 2004
  3. Christoph Becker-Freyseng

    PEP for new modules (I read PEP 2)

    Christoph Becker-Freyseng, Jan 15, 2004, in forum: Python
    Replies:
    3
    Views:
    360
    Gerrit Holl
    Jan 16, 2004
  4. Reinhold Birkenfeld

    [path-PEP] Path inherits from basestring again

    Reinhold Birkenfeld, Jul 23, 2005, in forum: Python
    Replies:
    34
    Views:
    696
    Reinhold Birkenfeld
    Jul 30, 2005
  5. Juha Nieminen
    Replies:
    3
    Views:
    1,126
    Juha Nieminen
    Feb 22, 2008
Loading...

Share This Page