[Python-Dev] Deprecating builtin id (and moving it to sys())
In Launchpad (mainly because SQLObject is used) we end up with quite a few locals named id. Apart from the fact that naturally clobbering builtins is a bad idea, we get quite a few warnings when linting throughout the codebase. I've fixed these as I've found them, but today Andrew pointed out to me that this is noted in: http://www.python.org/doc/essays/ppt/regrets/PythonRegrets.ppt I wonder: is moving id() to sys doable in the 2.5 cycle, with a deprecation warning being raised for people using the builtin? We'd then phase it out in one of the latter 2.x versions. I've done some searching through my code and id() isn't the most-used builtin, so from my perspective the impact would be limited, but of course others might think otherwise. Is it worth writing a PEP for this, or is it crack? Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3376 0125 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecating builtin id (and moving it to sys())
[Christian Robottom Reis] > I've done some searching through my code and id() isn't the most-used > builtin, so from my perspective the impact would be limited, but of > course others might think otherwise. > > Is it worth writing a PEP for this, or is it crack? FWIW, I use id() all the time and like having it as a builtin. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecating builtin id (and moving it to sys())
On 8/17/05, Christian Robottom Reis <[EMAIL PROTECTED]> wrote: > I've done some searching through my code and id() isn't the most-used > builtin, so from my perspective the impact would be limited, but of > course others might think otherwise. All of my primary uses of id would not show up in such a search. id is handy when debugging, when using the interactive interpreter and temporarily in scripts (print id(something), something for when repr(something) doesn't show the id). In my experience teaching python, id at the interactive interpreter is invaluable, which is why any proposal to move it would get a -1. The fundamental issue is that I want to explain reference semantics well before I talk about packages and the associated import call. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecating builtin id (and moving it to sys())
I'd like to see the builtin id() removed so that I can use it as a local variable name without clashing with the builtin name. I certainly use the id() function, but not as often as I have a local variable I'd like to name id. The sys module seems like a natural place to put id(), since it is exposing something about the implementation of Python rather than something about the language; the language offers the is operator to check ids. Jeremy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecating builtin id (and moving it to sys())
Christian Robottom Reis wrote: > In Launchpad (mainly because SQLObject is used) we end up with quite a > few locals named id. Apart from the fact that naturally clobbering > builtins is a bad idea, we get quite a few warnings when linting > throughout the codebase. I've fixed these as I've found them, but today > Andrew pointed out to me that this is noted in: > > http://www.python.org/doc/essays/ppt/regrets/PythonRegrets.ppt > > I wonder: is moving id() to sys doable in the 2.5 cycle, with a > deprecation warning being raised for people using the builtin? We'd then > phase it out in one of the latter 2.x versions. > > I've done some searching through my code and id() isn't the most-used > builtin, so from my perspective the impact would be limited, but of > course others might think otherwise. > > Is it worth writing a PEP for this, or is it crack? As I can see, this is not going to happen before Py3k, as it is completely breaking backwards compatibility. As such, a PEP would be unnecessary. Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecating builtin id (and moving it to sys())
Jeremy Hylton wrote: > I'd like to see the builtin id() removed so that I can use it as a > local variable name without clashing with the builtin name. I > certainly use the id() function, but not as often as I have a local > variable I'd like to name id. The sys module seems like a natural > place to put id(), since it is exposing something about the > implementation of Python rather than something about the language; the > language offers the is operator to check ids. > it is worth to remember that id() functionality is not cheap for Python impls using moving GCs. Identity mappings would be less taxing. > Jeremy > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/pedronis%40strakt.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecating builtin id (and moving it to sys())
On Wed, 2005-08-17 at 12:37, Jeremy Hylton wrote: > I'd like to see the builtin id() removed so that I can use it as a > local variable name without clashing with the builtin name. I > certainly use the id() function, but not as often as I have a local > variable I'd like to name id. Same here. > The sys module seems like a natural > place to put id(), since it is exposing something about the > implementation of Python rather than something about the language; the > language offers the is operator to check ids. +1 -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecating builtin id (and moving it to sys())
On 8/17/05, Barry Warsaw <[EMAIL PROTECTED]> wrote: > On Wed, 2005-08-17 at 12:37, Jeremy Hylton wrote: > > I'd like to see the builtin id() removed so that I can use it as a > > local variable name without clashing with the builtin name. I > > certainly use the id() function, but not as often as I have a local > > variable I'd like to name id. > > Same here. > > > The sys module seems like a natural > > place to put id(), since it is exposing something about the > > implementation of Python rather than something about the language; the > > language offers the is operator to check ids. > > +1 > -Barry +1 -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecating builtin id (and moving it to sys())
On Wed, Aug 17, 2005 at 06:37:11PM +0200, Reinhold Birkenfeld wrote: > As I can see, this is not going to happen before Py3k, as it is completely > breaking backwards compatibility. As such, a PEP would be unnecessary. We could add sys.id for 2.5 and remove __builtin__.id a some later time (e.g. for 3.0). Neil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecating builtin id (and moving it to sys())
On 8/17/05, Neil Schemenauer <[EMAIL PROTECTED]> wrote: > On Wed, Aug 17, 2005 at 06:37:11PM +0200, Reinhold Birkenfeld wrote: > > As I can see, this is not going to happen before Py3k, as it is completely > > breaking backwards compatibility. As such, a PEP would be unnecessary. > > We could add sys.id for 2.5 and remove __builtin__.id a some later > time (e.g. for 3.0). +1 for adding it to sys in 2.5, removing the builtin one in 3.0. .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SWIG and rlcompleter
On 8/16/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > -0 The behavior of dir() already a bit magical. Python is much simpler > to comprehend if we have direct relationships like dir() and vars() > corresponding as closely as possible to the object's dictionary. If > someone injects non-strings into an attribute dictionary, why should > dir() hide that fact? Indeed, there seem to be two camps, those who want dir to reflect __dict__ and those who want dir to reflect attributes of an object. It seems to me that those who want dir to reflect __dict__ should just use __dict__ in the first place. However, in the case of dir handling non-strings, should dir handle non-valid identifiers as well, that is to say that while foo.__dict__[2] = ... is an obvious case what about foo.__dict__["1"] ? Right now the documentation says that it returns "attributes", and I would not consider non-strings to be attributes, so either the documentation or the implementation should rectify this disagreement. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SWIG and rlcompleter
On 8/17/05, Timothy Fitz <[EMAIL PROTECTED]> wrote: > On 8/16/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > -0 The behavior of dir() already a bit magical. Python is much simpler > > to comprehend if we have direct relationships like dir() and vars() > > corresponding as closely as possible to the object's dictionary. If > > someone injects non-strings into an attribute dictionary, why should > > dir() hide that fact? > > Indeed, there seem to be two camps, those who want dir to reflect __dict__ > and those who want dir to reflect attributes of an object. It seems to > me that those who want dir to reflect __dict__ should just use > __dict__ in the first place. Right. > However, in the case of dir handling non-strings, should dir handle > non-valid identifiers as well, that is to say that while > foo.__dict__[2] = ... is an obvious case what about foo.__dict__["1"] > ? See below. > Right now the documentation says that it returns "attributes", and I > would not consider non-strings to be attributes, so either the > documentation or the implementation should rectify this disagreement. I think that dir() should hide non-strings; these aren't attributes if you believe the definition that an attribute name is something acceptable to getattr() or setattr(). Following this definition, the string "1" is a valid attribute name (even though it's not a valid identifier), but the number 1 is not. Try it. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SWIG and rlcompleter
[Timothy Fitz] > It seems to > me that those who want dir to reflect __dict__ should just use > __dict__ in the first place. The dir() builtin does quite a bit more than obj.__dict__.keys(). >>> class A(list): x = 1 >>> dir(A) ['__add__', '__class__', '__contains__', '__delattr__', '__delitem__', '__delslice__', '__dict__', '__doc__', '__eq__', '__ge__', '__getattribute__', '__getitem__', '__getslice__', '__gt__', '__hash__', '__iadd__', '__imul__', '__init__', '__iter__', '__le__', '__len__', '__lt__', '__module__', '__mul__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__reversed__', '__rmul__', '__setattr__', '__setitem__', '__setslice__', '__str__', '__weakref__', 'append', 'count', 'extend', 'index', 'insert', 'pop', 'remove', 'reverse', 'sort', 'x'] >>> A.__dict__.keys() ['__dict__', 'x', '__module__', '__weakref__', '__doc__'] Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SWIG and rlcompleter
> [Timothy Fitz] > > It seems to > > me that those who want dir to reflect __dict__ should just use > > __dict__ in the first place. [Raymond] > The dir() builtin does quite a bit more than obj.__dict__.keys(). Well that's the whole point, right? We shouldn't conflate the two. I don't see this as an argument why it would be bad to delete non-string-keys found in __dict__ from dir()'s return value. I don't think that the equation set(x.__dict__) <= set(dir(x)) provides enough value to try and keep it. A more useful relationship is name in dir(x) <==> getattr(x, name) is valid -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SWIG and rlcompleter
> > [Timothy Fitz] > > > It seems to > > > me that those who want dir to reflect __dict__ should just use > > > __dict__ in the first place. > > [Raymond] > > The dir() builtin does quite a bit more than obj.__dict__.keys(). > > Well that's the whole point, right? Perhaps. I wasn't taking a position. Just noting that Timothy's comment over-simplified the relationship. > A more useful relationship is > > name in dir(x) <==> getattr(x, name) is valid That would be a useful invariant. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SWIG and rlcompleter
[me] > > A more useful relationship is > > > > name in dir(x) <==> getattr(x, name) is valid [Raymond] > That would be a useful invariant. Well, the <== part can't really be guaranteed due to the existence of __getattr__ overriding (and all bets are off if __getattribute__ is overridden!), but apart from those, stripping non-strings in dir() would be a big help towards making the invariant true. So I'm +1 on that. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] A testing challenge
When was the last time someone thanked you for writing a test? I tried to think of the last time it happened to me and I can't remember. Well at Spikesource we want to thank you not just for helping the Python community but for your testing efforts too and we are running a participatory testing contest. This is a competition where there are no losers, every project gains if new tests are written. For more details see below, it is open worldwide. feel free to send questions to me. thanks calvin *_Open Testing Contest with Over $20,000 in Prizes_* Committers! SpikeSource is sponsoring a contest to help increase the participatory testing of open source software. Awards will be given to open source projects that have the greatest increase in code coverage from September 15 through December 31, 2005. Project sign-up is due by August 31^st and the contest begins on September 15^th . Visit http://www.spikesource.com/contest/ for complete details and to register your project. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecating builtin id (and moving it to sys())
Barry Warsaw wrote: >On Wed, 2005-08-17 at 12:37, Jeremy Hylton wrote: > > >>I'd like to see the builtin id() removed so that I can use it as a >>local variable name without clashing with the builtin name. I >>certainly use the id() function, but not as often as I have a local >>variable I'd like to name id. >> >> > >Same here. > > > >>The sys module seems like a natural >>place to put id(), since it is exposing something about the >>implementation of Python rather than something about the language; the >>language offers the is operator to check ids. >> >> > >+1 >-Barry > > +1 eric ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SWIG and rlcompleter
On Aug 17, 2005, at 2:55 PM, Timothy Fitz wrote: > On 8/16/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > >> -0 The behavior of dir() already a bit magical. Python is much >> simpler >> to comprehend if we have direct relationships like dir() and vars() >> corresponding as closely as possible to the object's dictionary. If >> someone injects non-strings into an attribute dictionary, why should >> dir() hide that fact? >> > > Indeed, there seem to be two camps, those who want dir to reflect > __dict__ > and those who want dir to reflect attributes of an object. It seems to > me that those who want dir to reflect __dict__ should just use > __dict__ in the first place. > > However, in the case of dir handling non-strings, should dir handle > non-valid identifiers as well, that is to say that while > foo.__dict__[2] = ... is an obvious case what about foo.__dict__["1"] > ? > > Right now the documentation says that it returns "attributes", and I > would not consider non-strings to be attributes, so either the > documentation or the implementation should rectify this disagreement. > I initially was going to say no, there's no reason to restrict your idea of "attributes" to be purely strings, because surely you could use non-strings as attributes if you wished to. But Python proves me wrong: >>> class X: pass >>> X.__dict__[1] = 5 >>> dir(X) [1, '__doc__', '__module__'] >>> getattr(X, 1) TypeError: getattr(): attribute name must be string If dir() is supposed to return the list of attributes, it does seem logical that it should be possible to pass those names into getattr. I think I'd actually call that a defect in getattr() that it doesn't allow non-string attributes, not a defect in dir(). Ooh...even more annoying, it doesn't even allow unicode attributes that use characters outside the default encoding (ASCII). But either way, there's absolutely no reason to worry about the attribute string being a valid identifier. That's pretty much only a concern for tab-completion in python shells. James ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecating builtin id (and moving it to, sys())
-1 for this proposal from me. I use id some and therefore the change
would break some of my code. Breaking existing code without some
overwhelming reason is a very bad idea, in my opinion. The reason cited
here, that the name is so natural that one is tempted to use it, applies
to many builtins. Ever written dict = {} and then said to yourself, gee,
that isn't a very good idea? I have.
Besides that, the fact that an object has an identity, behaviors, and
data is primary. For teaching beginners id() is important.
Paul
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecating builtin id (and moving it to sys())
On Thursday 18 August 2005 00:02, Christian Robottom Reis wrote: > I wonder: is moving id() to sys doable in the 2.5 cycle, with a > deprecation warning being raised for people using the builtin? We'd then > phase it out in one of the latter 2.x versions. I'm neutral on putting id() also into sys. I'm -1 on either issuing a deprecation warning or, worse yet, removing the id() builtin. The warnings system is expensive to call, and I know from a brief look at a bunch of code that I use id() inside some tight inner loops. Removing it entirely is gratuitous breakage, for a not very high payoff. If you _really_ want to call a local variable 'id' you can (but shouldn't). You also can't/shouldn't call a variable 'class', 'def', or 'len' -- but I don't see any movement to allow these... Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
