FAQ

[Python] I support PEP 326

Gary Robinson
Jan 22, 2004 at 4:25 pm
I've recently had a couple of cases of needing exactly what it proposes, and
having to kluge around the fact that it's not there. It's a great idea.

If there anywhere else I should be expressing my opinion on this, let me
know.

--Gary

--
Putting http://wecanstopspam.org in your email helps it pass through
overzealous spam filters.

Gary Robinson
CEO
Transpose, LLC
grobinson at transpose.com
207-942-3463
Company: http://www.transpose.com
Blog: http://www.garyrobinson.net
reply

Search Discussions

35 responses

  • Paul Prescod at Jan 22, 2004 at 5:40 pm
    As a matter of style wouldn't it be nice to refer to PEPs both by number
    and by name? It is just a minor oversight but there is a tendency of
    communities to migrate to refering to things just by numbers in a way
    that excludes newcomers or hobbiests.

    NOT directed at you in particular Gary!

    Paul Prescod
  • Jeremy Hylton at Jan 22, 2004 at 7:13 pm

    On Thu, 2004-01-22 at 12:40, Paul Prescod wrote:
    As a matter of style wouldn't it be nice to refer to PEPs both by number
    and by name? It is just a minor oversight but there is a tendency of
    communities to migrate to refering to things just by numbers in a way
    that excludes newcomers or hobbiests.

    NOT directed at you in particular Gary!
    What's PEP 326 again?

    Jeremy
  • Gary Robinson at Jan 22, 2004 at 7:25 pm
    What's PEP 326 again?

    Sorry... it's a proposal that Python incorporates two singleton constants
    that represent top and bottom values: Max and Min might be the names.

    Max would be bigger than anything it's compared to and Min would be smaller.
    It would be very convenient -- in code I was writing a week or two ago I was
    thinking "wouldn't it be great if python had..." exactly what PEP 326
    proposes. It would have saved... well... a few minutes. But those add up!

    The PEP document gives a lot of examples of why it would be good.

    http://www.python.org/peps/pep-0326.html

    --Gary

    --
    Putting http://wecanstopspam.org in your email helps it pass through
    overzealous spam filters.

    Gary Robinson
    CEO
    Transpose, LLC
    grobinson at transpose.com
    207-942-3463
    Company: http://www.transpose.com
    Blog: http://www.garyrobinson.net


    >
  • John Roth at Jan 22, 2004 at 6:23 pm
    "Gary Robinson" <grobinson at transpose.com> wrote in message
    news:mailman.654.1074788734.12720.python-list at python.org...
    I've recently had a couple of cases of needing exactly what it proposes, and
    having to kluge around the fact that it's not there. It's a great idea.

    If there anywhere else I should be expressing my opinion on this, let me
    know.
    Just in case anyone can't find the PEP - it's the one that proposes
    specific objects that will always sort highest and lowest.

    I'm mildly in favor; it seems to be useful for some cases, and it
    also seems easy enough to do. Of course, it would make None
    the second smallest object.

    John Roth
    --Gary

    --
  • A. Lloyd Flanagan at Jan 26, 2004 at 7:58 pm
    "John Roth" <newsgroups at jhrothjr.com> wrote in message news:<10105bn3bsi63c9 at news.supernews.com>...
    Just in case anyone can't find the PEP - it's the one that proposes
    specific objects that will always sort highest and lowest.

    I'm mildly in favor; it seems to be useful for some cases, and it
    also seems easy enough to do. Of course, it would make None
    the second smallest object.

    John Roth
    +1 on the PEP. The names Max and Min seem fine to me, but I'm not
    married to them.

    What would be the consequence of making Min and None compare equal?
    Then the "None as second lowest" issue goes away. I can't think of an
    example where that would cause problems, but there probably are
    some...
  • Josiah Carlson at Jan 26, 2004 at 8:24 pm

    +1 on the PEP. The names Max and Min seem fine to me, but I'm not
    married to them.

    What would be the consequence of making Min and None compare equal?
    Then the "None as second lowest" issue goes away. I can't think of an
    example where that would cause problems, but there probably are
    some...
    The issue is that when Min and None are in a sequence that gets sorted,
    you can end up with Minimums and Nones getting interspersed like so:
    [Min, None, Min...]

    In general, that behavior is frowned upon.

    - Josiah
  • Andrew Koenig at Jan 27, 2004 at 3:54 pm

    The issue is that when Min and None are in a sequence that gets sorted,
    you can end up with Minimums and Nones getting interspersed like so:
    [Min, None, Min...]
    If Min and None were two different names for the same object, such behavior
    would be moot.
    However, the following anomalies might then appear:
    None
    None
    Min
    None

    (after all, if they're the same object, how is the interpreter to know which
    print name to use?)
  • Josiah Carlson at Jan 27, 2004 at 9:49 pm

    Andrew Koenig wrote:
    The issue is that when Min and None are in a sequence that gets sorted,
    you can end up with Minimums and Nones getting interspersed like so:
    [Min, None, Min...]

    If Min and None were two different names for the same object, such behavior
    would be moot.
    However, the following anomalies might then appear:
    None
    None
    Min
    None

    (after all, if they're the same object, how is the interpreter to know which
    print name to use?)
    Additionally, None comparing smaller than everything else is neither
    intuitive, nor really documented (as reiterated a few times by a few
    different people in python-dev). It was an arbitrary decision, but
    better than None comparing larger than everything.

    - Josiah
  • Josiah Carlson at Jan 22, 2004 at 7:39 pm

    I've recently had a couple of cases of needing exactly what it proposes, and
    having to kluge around the fact that it's not there. It's a great idea.

    If there anywhere else I should be expressing my opinion on this, let me
    know.
    Gary,

    I'm glad you like my PEP. In general, many other people have found the
    objects to be a useful addition. Seemingly the only stalling point is
    where the Max/Min values are going to be placed, and what they should be
    called. If you feel like looking at a listing of the possible locations
    and names, check the previous version in cvs:
    http://cvs.sourceforge.net/viewcvs.py/*checkout*/python/python/nondist/peps/pep-0326.txt?content-type=text%2Fplain&rev=1.2

    The listing was removed in the latest version because it detracted from
    the specific functionality, which is more important than location. If
    you feel like posting your exact use for the Max/Min value, that would
    be great.

    - Josiah
  • Erik Max Francis at Jan 23, 2004 at 2:06 am

    Gary Robinson wrote:

    I've recently had a couple of cases of needing exactly what it
    proposes, and
    having to kluge around the fact that it's not there. It's a great
    idea.

    If there anywhere else I should be expressing my opinion on this, let
    me
    know.
    Seems quite reasonable to me. The only issue I'd take with it is the
    choice of Min and Max for the names of the singletons; they're a little
    too close to the functions min and max, which obviously they're both
    likely to be used with. I would suggest something a little more verbose
    such as Minimum and Maximum, or if you want to get silly, Infimum and
    Supremum.

    --
    __ Erik Max Francis && max at alcyone.com && http://www.alcyone.com/max/
    / \ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
    \__/ Love is the most subtle form of self-interest.
    -- Holbrook Jackson
  • Roy Smith at Jan 23, 2004 at 2:13 am
    In article <401081A1.E4C34F00 at alcyone.com>,
    Erik Max Francis wrote:
    Gary Robinson wrote:
    I've recently had a couple of cases of needing exactly what it
    proposes, and
    having to kluge around the fact that it's not there. It's a great
    idea.

    If there anywhere else I should be expressing my opinion on this, let
    me
    know.
    Seems quite reasonable to me. The only issue I'd take with it is the
    choice of Min and Max for the names of the singletons; they're a little
    too close to the functions min and max, which obviously they're both
    likely to be used with. I would suggest something a little more verbose
    such as Minimum and Maximum, or if you want to get silly, Infimum and
    Supremum.
    I suppose you could special-case min() and max() to return the
    appropriate singletons if called with no arguments.

    There's something very nice about that. There's also something very
    ugly about it. I'm having a hard time deciding which is stronger :-)


    From http Fri Jan 23 06:06:32 2004
    From: http (Paul Rubin)
    Date: 22 Jan 2004 21:06:32 -0800
    Subject: cgi concurrency approaches?
    Message-ID: <7x7jzjgso7.fsf@ruckus.brouhaha.com>

    I'm wondering if folks here have favorite lightweight ways of dealing
    with concurrency in cgi's. Take a simple case:

    You want to write a cgi that implements a simple counter. The first
    time it's called, it prints "1". The next time, "2", etc. The naive
    implementation looks something like:

    fd = open("counter.num", "rw")
    n = int(fd.read())
    fd.seek(0, 0)
    fd.write("%d"% n+1)
    print "Content-type: text/html\n\n"
    print n

    but of course there's the obvious race condition if two people hit the
    cgi at the same time.

    Fancier solutions include running an transactional database in another
    process and connecting to it, setting up a daemon that remembers the
    counter value in memory and serializes access through a socket that
    the cgi opens, using a file-system specific hack like linking to
    counter file to lock it, having a timeout/retry if the counter is
    locked, with a possible hangup if a lock file gets left around by
    accident, etc. Each is a big pain in the neck.

    Anyone have some simpler approaches?
  • Josiah Carlson at Jan 23, 2004 at 5:49 am

    I suppose you could special-case min() and max() to return the
    appropriate singletons if called with no arguments.

    There's something very nice about that. There's also something very
    ugly about it. I'm having a hard time deciding which is stronger :-)
    That behavior was called very bad names by Guido. We shall not speak of
    it any longer. Heh.

    - Josiah
  • Andrew Koenig at Jan 23, 2004 at 5:55 am

    I suppose you could special-case min() and max() to return the
    appropriate singletons if called with no arguments.

    There's something very nice about that. There's also something very
    ugly about it. I'm having a hard time deciding which is stronger :-)
    I'm afraid it's not right, because calling min() with no arguments should
    return Max and calling max() with no arguments should return Min.

    This behavior is correct because it preserves the intuitive property that if
    s1 and s2 are (possibly empty) sequences, min(min(s1),min(s2)) should be
    equal to min(s1+s2), and similarly for max. If you like, Max is the
    identity element for min and Min is the identity element for max.
  • Paul Prescod at Jan 23, 2004 at 6:57 am

    Andrew Koenig wrote:

    I suppose you could special-case min() and max() to return the
    appropriate singletons if called with no arguments.

    There's something very nice about that. There's also something very
    ugly about it. I'm having a hard time deciding which is stronger :-)

    I'm afraid it's not right, because calling min() with no arguments should
    return Max and calling max() with no arguments should return Min.

    This behavior is correct because it preserves the intuitive property that if
    s1 and s2 are (possibly empty) sequences, min(min(s1),min(s2)) should be
    equal to min(s1+s2), and similarly for max. If you like, Max is the
    identity element for min and Min is the identity element for max.
    Calling min with no arguments need not be the same as calling it with an
    empty sequence argument. That is not necessarily an argument for making
    the empty function call return something arguably strange...

    Paul Prescod
  • Andrew Koenig at Jan 23, 2004 at 2:46 pm

    Calling min with no arguments need not be the same as calling it with an
    empty sequence argument. That is not necessarily an argument for making
    the empty function call return something arguably strange...
    I agree with you that it's strange, but it's right. It might interest you
    to know that APL has behaved the same way for more than 35 years. In APL,
    the usual way of obtaining the largest positive value is to ask for the
    lowest element of an empty sequence.

    In Python, if you give min or max a single argument, it is assumed to be a
    sequence, and if that sequence is empty, you get an exception. If you give
    it more than one argument, those arguments are treated as elements of a
    sequence, and you get an exception if there are no arguments (i.e. if the
    sequence is empty).

    Therefore, if min([]) were to return Max (which, although surprising, I
    still think is reasonable), then min() should also return Max.
  • Erik Max Francis at Jan 23, 2004 at 9:07 am

    Paul Prescod wrote:

    Calling min with no arguments need not be the same as calling it with
    an
    empty sequence argument.
    Since min(S) and min(*S) behave identically, I submit to you that they
    _should_ be.

    --
    __ Erik Max Francis && max at alcyone.com && http://www.alcyone.com/max/
    / \ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
    \__/ The only source of knowledge is experience.
    -- Albert Einstein
  • A.Schmolck at Jan 23, 2004 at 1:10 pm

    Erik Max Francis <max at alcyone.com> writes:

    Since min(S) and min(*S) behave identically, I submit to you that they
    _should_ be.
    They don't. (See bottom for example).

    'as





















































    min([[1]])
    [1]
    min(*[[1]])
    1
  • Andrew Koenig at Jan 26, 2004 at 3:57 pm

    Calling min with no arguments need not be the same as calling it with an
    empty sequence argument. That is not necessarily an argument for making
    the empty function call return something arguably strange...
    Having min() and min([]) return different values is also arguably strange.
  • David M. Cooke at Jan 23, 2004 at 2:59 am

    At some point, Erik Max Francis wrote:
    Gary Robinson wrote:
    If there anywhere else I should be expressing my opinion on this, let
    me
    know.
    Seems quite reasonable to me. The only issue I'd take with it is the
    choice of Min and Max for the names of the singletons; they're a little
    too close to the functions min and max, which obviously they're both
    likely to be used with. I would suggest something a little more verbose
    such as Minimum and Maximum, or if you want to get silly, Infimum and
    Supremum.
    Or, expressing the idea that they're the ends of a number line:

    PosInf, NegInf
    PosInfinity, NegInfinity
    PositiveInfinity, NegativeInfinity

    If IEEE floating point was done correctly everywhere, I'd say make
    them the corresponding floating-point constants (Inf+ and Inf-).

    Or,
    FreakingHuge, FreakingHugeTheOtherWay

    --
    \/|<
    /--------------------------------------------------------------------------\
    David M. Cooke
    cookedm(at)physics(dot)mcmaster(dot)ca
  • Erik Max Francis at Jan 23, 2004 at 3:15 am

    "David M. Cooke" wrote:

    Or, expressing the idea that they're the ends of a number line:

    PosInf, NegInf
    PosInfinity, NegInfinity
    PositiveInfinity, NegativeInfinity

    If IEEE floating point was done correctly everywhere, I'd say make
    them the corresponding floating-point constants (Inf+ and Inf-).
    The "if" conditional here is bad. Naming something "infinity" if it
    weren't the IEEE floating point constants as well would be seriously
    misleading.

    After all, this _isn't_ a number line since we're talking about
    comparing arbitrary objects.
    Or,
    FreakingHuge, FreakingHugeTheOtherWay
    Don't be silly; that latter one should be FreakingUnhuge :-).

    --
    __ Erik Max Francis && max at alcyone.com && http://www.alcyone.com/max/
    / \ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
    \__/ Things are as they are because they were as they were.
    -- Thomas Gold
  • Roy Smith at Jan 23, 2004 at 3:41 am
    In article <401091D5.EFA41F7 at alcyone.com>,
    Erik Max Francis wrote:
    "David M. Cooke" wrote:
    Or, expressing the idea that they're the ends of a number line:

    PosInf, NegInf
    PosInfinity, NegInfinity
    PositiveInfinity, NegativeInfinity

    If IEEE floating point was done correctly everywhere, I'd say make
    them the corresponding floating-point constants (Inf+ and Inf-).
    The "if" conditional here is bad. Naming something "infinity" if it
    weren't the IEEE floating point constants as well would be seriously
    misleading.

    After all, this _isn't_ a number line since we're talking about
    comparing arbitrary objects.
    Or,
    FreakingHuge, FreakingHugeTheOtherWay
    Don't be silly; that latter one should be FreakingUnhuge :-).
    You could name them Python and Perl. Then you could do stuff like:

    for language in allLanguages:
    if Perl < language < Python:
    print language, "is more than Perl but less than Python"
  • Josiah Carlson at Jan 23, 2004 at 3:25 am

    Or, expressing the idea that they're the ends of a number line:

    PosInf, NegInf
    PosInfinity, NegInfinity
    PositiveInfinity, NegativeInfinity

    If IEEE floating point was done correctly everywhere, I'd say make
    them the corresponding floating-point constants (Inf+ and Inf-).

    Or,
    FreakingHuge, FreakingHugeTheOtherWay
    PosInf, NegInf
    PosInfinity, NegInfinity
    PositiveInfinity, NegativeInfinity

    All suggest that the Max and Min (or whatever you want to call them) are
    numbers. Such a thing is misleading, and also tends to tie PEP 326 with
    PEP 754 (IEEE 754 Floating Point Special Values, which makes the case
    for a consistant name for +/- FP Infinity).

    As stated in my PEP:

    Guido has brought up [2]_ the fact that there exists two constants
    that can be used in the interim for maximum values: sys.maxint and
    floating point positive infinity (1e309 will evaluate to positive
    infinity). However, each has their drawbacks.

    - On most architectures sys.maxint is arbitrarily small (2**31-1 or
    2**63-1) and can be easily eclipsed by large 'long' integers or
    floating point numbers.

    - Comparing long integers larger than the largest floating point
    number representable against any float will result in an exception
    being raised::
    cmp(1.0, 10**309)
    Traceback (most recent call last):
    File "<stdin>", line 1, in ?
    OverflowError: long int too large to convert to float

    Even when large integers are compared against positive infinity::
    cmp(1e309, 10**309)
    Traceback (most recent call last):
    File "<stdin>", line 1, in ?
    OverflowError: long int too large to convert to float

    - These same drawbacks exist when numbers are small.
  • Mel Wilson at Jan 23, 2004 at 2:51 pm
    In article <buq4ap$fsb$1 at news.service.uci.edu>,
    Josiah Carlson wrote:
    Or, expressing the idea that they're the ends of a number line:

    PosInf, NegInf
    PosInfinity, NegInfinity
    PositiveInfinity, NegativeInfinity
    Highest and Lowest?

    Regards. Mel.
  • Josiah Carlson at Jan 23, 2004 at 7:48 pm

    Mel Wilson wrote:
    In article <buq4ap$fsb$1 at news.service.uci.edu>,
    Josiah Carlson wrote:
    Or, expressing the idea that they're the ends of a number line:

    PosInf, NegInf
    PosInfinity, NegInfinity
    PositiveInfinity, NegativeInfinity

    Highest and Lowest?

    Regards. Mel.
    That was a suggestion, as was High and Low. I removed potential
    locations because it detracts from the main focus of the PEP, the
    existance of the objects.
    - Josiah
  • John Roth at Jan 23, 2004 at 12:14 pm
    "David M. Cooke" <cookedm+news at physics.mcmaster.ca> wrote in message
    news:qnky8rzid3y.fsf at arbutus.physics.mcmaster.ca...
    At some point, Erik Max Francis wrote:
    Gary Robinson wrote:
    If there anywhere else I should be expressing my opinion on this, let
    me
    know.
    Seems quite reasonable to me. The only issue I'd take with it is the
    choice of Min and Max for the names of the singletons; they're a little
    too close to the functions min and max, which obviously they're both
    likely to be used with. I would suggest something a little more verbose
    such as Minimum and Maximum, or if you want to get silly, Infimum and
    Supremum.
    Or, expressing the idea that they're the ends of a number line:

    PosInf, NegInf
    PosInfinity, NegInfinity
    PositiveInfinity, NegativeInfinity

    If IEEE floating point was done correctly everywhere, I'd say make
    them the corresponding floating-point constants (Inf+ and Inf-).
    If you do that you lose the ability to have those two constants be
    in a list that *also* has end delimiters. A large part of the proposal
    is that the end delimiters shouldn't have any other meaning: in other
    words, there's no rational reason to use them in any other context
    than ordering. (People will always come up with irrational reasons,
    of course.) [grin]

    John Roth
    --
    \/|<
    /--------------------------------------------------------------------------\
    David M. Cooke
    cookedm(at)physics(dot)mcmaster(dot)ca
  • Jeremy Fincher at Jan 27, 2004 at 9:18 pm
    Gary Robinson <grobinson at transpose.com> wrote in message news:<mailman.654.1074788734.12720.python-list at python.org>...
    I've recently had a couple of cases of needing exactly what it proposes, and
    having to kluge around the fact that it's not there. It's a great idea.

    If there anywhere else I should be expressing my opinion on this, let me
    know.
    I'm also in support of this PEP, and have cases in which I would use
    the new singletons.

    The biggest reason I believe the PEP should be accepted is that you
    simply *can't* "roll your own" in a heterogenous environment. If I
    have my Min/Max objects and you have your Min/Max objects, someone's
    objects simply aren't going to work as expected.

    I'm in favor of Minimum and Maximum, though, if only for ease in
    discussing Python: the capital isn't obvious both verbally or at the
    beginning of a properly written sentence.

    Jeremy
  • Josiah Carlson at Jan 27, 2004 at 10:40 pm

    I'm also in support of this PEP, and have cases in which I would use
    the new singletons.

    The biggest reason I believe the PEP should be accepted is that you
    simply *can't* "roll your own" in a heterogenous environment. If I
    have my Min/Max objects and you have your Min/Max objects, someone's
    objects simply aren't going to work as expected.

    I'm in favor of Minimum and Maximum, though, if only for ease in
    discussing Python: the capital isn't obvious both verbally or at the
    beginning of a properly written sentence.
    Unfortunately, I have a feeling that the PEP may be killed because there
    doesn't seem to be a location/name that is agreeable to those with
    voting power in python-dev.

    A new module included into the standard library seems to be the easiest
    way to get it into Python. However, considering that you cannot
    guarantee that the Max/Min will get their __cmp__ method called (when
    comparing against user-defined classes), you cannot guarantee the ordering.

    If it were to get special treatment, by including it as a pseudo-builtin
    (always in Python, but doesn't have a name in __builtin__), it is a 5
    line modification to PyObject_Compare in object.c to guarantee the
    orderings with Max/Min:
    http://mail.python.org/pipermail/python-dev/2004-January/042275.html


    That email also makes a case for min() and max() returning the minimum
    and maximum object respectively, whose string representations would be
    'min()' and 'max()' respectively. It would result in the overloading of
    the min and max functions, but there is no general consensus in
    python-dev; some people like it due to its similarity to using int(),
    list(), dict(), float(), str(), long(), etc., but others (including
    Guido himself) think that min() and max() /should/ produce TypeErrors.

    I'm thinking that maybe it should produce a warning for a release or two
    (that it used to produce a TypeError, unless 'from future import
    extremes' is at the beginning of a script), but in Python 2.5 or 2.6
    remove the warning.

    Yeah. If someone has a strong opinion either way, perhaps you should
    comment in python-dev. If anyone has a better name/location suggestion,
    (that is not listed as an option in the current or previous versions in CVS:
    http://python.org/peps/pep-0326.html
    http://cvs.sourceforge.net/viewcvs.py/*checkout*/python/python/nondist/peps/pep-0326.txt?content-type=text%2Fplain&rev=1.2
    ), you suggestions are definitely appreciated.

    Thank you,
    - Josiah
  • Jeremy Fincher at Jan 28, 2004 at 4:00 am
    Josiah Carlson <jcarlson at nospam.uci.edu> wrote in message news:<bv6ph8$181$1 at news.service.uci.edu>...
    Unfortunately, I have a feeling that the PEP may be killed because there
    doesn't seem to be a location/name that is agreeable to those with
    voting power in python-dev.
    I simply can't understand this aversion to sticking useful things in
    the builtin namespace. Especially when marginally useful things like
    reversed (a trivially written 3-line generator) have been put there.

    Jeremy
  • Anthony Baxter at Jan 28, 2004 at 4:10 am

    Jeremy Fincher wrote
    I simply can't understand this aversion to sticking useful things in
    the builtin namespace. Especially when marginally useful things like
    reversed (a trivially written 3-line generator) have been put there.
    len(dir(__builtins__))
    125

    That's a _lot_ of stuff in one module. Even if you exclude the 40-odd
    exceptions that are there, that's still a lot of guff in one big flat
    namespace.

    Anthony
  • Gerrit Holl at Jan 28, 2004 at 9:02 am

    Anthony Baxter wrote:
    len(dir(__builtins__))
    125

    That's a _lot_ of stuff in one module. Even if you exclude the 40-odd
    exceptions that are there, that's still a lot of guff in one big flat
    namespace.
    Any plans to clean it up in Python 3.0?

    In my opinion, a lot of builtins could either be deleted or moved into a
    module:

    buffer
    complex -> to math
    open (use file)
    long
    abs -> to math
    apply -> use extended syntax
    compile -> to sys
    divmod -> to math
    execfile -> to sys
    filter, reduce -> to functional?
    intern -> ?
    map -> use list comp
    oct/hex -> to math?
    range/xrange (unify)
    round -> to math

    Gerrit.

    --
    227. If any one deceive a barber, and have him mark a slave not for
    sale with the sign of a slave, he shall be put to death, and buried in his
    house. The barber shall swear: "I did not mark him wittingly," and shall
    be guiltless.
    -- 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/
  • Skip Montanaro at Jan 28, 2004 at 2:52 pm

    That's a _lot_ of stuff in one module. Even if you exclude the 40-odd
    exceptions that are there, that's still a lot of guff in one big flat
    namespace.
    Gerrit> Any plans to clean it up in Python 3.0?

    Yes, there has been some discussion about this on python-dev. It doesn't
    appear a PEP's been written yet.

    Skip
  • Josiah Carlson at Jan 28, 2004 at 3:12 pm

    Skip Montanaro wrote:
    That's a _lot_ of stuff in one module. Even if you exclude the 40-odd
    exceptions that are there, that's still a lot of guff in one big flat
    namespace.
    Gerrit> Any plans to clean it up in Python 3.0?

    Yes, there has been some discussion about this on python-dev. It doesn't
    appear a PEP's been written yet.

    Skip
    Hey Skip,

    I know you commented on the flat namespace of __builtin__, but I've not
    seen any comments on PEP 326. Don't feel like you need to answer, but
    what are your feelings on it (even if you hate the PEP and give it a -1,
    you'll not hurt my feelings)?

    - Josiah
  • Skip Montanaro at Jan 28, 2004 at 3:34 pm
    Josiah> I know you commented on the flat namespace of __builtin__, but
    Josiah> I've not seen any comments on PEP 326.

    http://mail.python.org/pipermail/python-dev/2004-January/042308.html

    I guess I don't sort() stuff enough...

    Skip
  • Jeremy Fincher at Jan 28, 2004 at 3:26 pm
    Anthony Baxter <anthony at interlink.com.au> wrote in message news:<mailman.884.1075263037.12720.python-list at python.org>...
    len(dir(__builtins__))
    125

    That's a _lot_ of stuff in one module. Even if you exclude the 40-odd
    exceptions that are there, that's still a lot of guff in one big flat
    namespace.
    There certainly is, but are the mistakes of the past going to doom us
    to put things in the wrong place until we get to clean it up? I think
    the one appropriate place for the proposed constants is __builtins__,
    for the obvious reasons that (a) all other singleton constants are
    there (None, True, False) and (b) ease of implementation of cmp (with
    Maximum and Minimum in __builtins__, it's a 5-line change, I read on
    Python-dev).

    Yes, __builtins__ is bloated, but as Mr. Holl mentioned, a significant
    amount of it can be removed once Guido's willing to break
    backwards-compatibility. But why make 3.0 even more
    backwards-incompatible than it is now by sticking rightful builtins
    somewhere else just to keep the builtin namespace artificially
    smaller?

    (Or consider this: as a native speaker of English, I have a working
    vocabulary of tens of thousands of English words, and a non-working
    vocabulary in the hundreds of thousands. Do people really believe
    that the difference between 125 and 127 (or 150, or 200) builtins is
    going to increase my cognitive load significantly?)

    Jeremy
  • Heather Coppersmith at Jan 28, 2004 at 12:33 am

    On 27 Jan 2004 13:18:43 -0800, tweedgeezer at hotmail.com (Jeremy Fincher) wrote:

    ... If I have my Min/Max objects and you have your Min/Max
    objects, someone's objects simply aren't going to work as
    expected.
    Sure they will: Mine is mymodule.Min; yours is yourmodule.Min.
    Use "from import" at your own risk and peril.

    Regards,
    Heather

    --
    Heather Coppersmith
    That's not right; that's not even wrong. -- Wolfgang Pauli

Related Discussions