Re: [Python-Dev] Deprecating builtin id (and moving it to sys())
Guido The built-in namespace is searched last for a reason -- the Guido design is such that if you don't care for a particular built-in Guido you don't need to know about it. In my mind there are three classes of builtins from the standpoint of overriding. Pychecker complains if you override any of them, but I think that many times it does so unnecessarily. The first class includes those builtins that you will likely find in many code samples and should just never be overridden. For me these include abs, map, list, int, range, zip, the various exceptions, etc. The second class of builtins consists of objects or functions that are fairly special-purpose. You might not really care if they are overridden, depending on context. For me this class includes compile, id, reload, execfile, ord, etc. Finally, there is the subset of builtins that is included almost solely as a convenience for use at the interpreter prompt. They include quit, exit and copyright. I could care less if I override them in my code, and don't think pychecker should either. Skip ___ 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 Friday 19 August 2005 02:22, Guido van Rossum wrote: On 8/17/05, Anthony Baxter [EMAIL PROTECTED] wrote: If you _really_ want to call a local variable 'id' you can (but shouldn't). Disagreed. The built-in namespace is searched last for a reason -- the design is such that if you don't care for a particular built-in you don't need to know about it. I'm not sure what you're disagreeing with. Are you saying you _can't_ call a variable 'id', or that it's OK to do this? You also can't/shouldn't call a variable 'class', 'def', or 'len' -- but I don't see any movement to allow these... Please don't propagate the confusion between reserved keywords and built-in names! It's not a matter of 'confusion', more that there are some names you can't or shouldn't use in Python. When coding twisted, often the most obvious 'short' name for a Deferred is 'def', but of course that doesn't work. Anthony ___ Python-Dev mailing list Python-Dev@python.org 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/20/05, Anthony Baxter [EMAIL PROTECTED] wrote: On Friday 19 August 2005 02:22, Guido van Rossum wrote: On 8/17/05, Anthony Baxter [EMAIL PROTECTED] wrote: If you _really_ want to call a local variable 'id' you can (but shouldn't). Disagreed. The built-in namespace is searched last for a reason -- the design is such that if you don't care for a particular built-in you don't need to know about it. I'm not sure what you're disagreeing with. Are you saying you _can't_ call a variable 'id', or that it's OK to do this? That it's OK. You also can't/shouldn't call a variable 'class', 'def', or 'len' -- but I don't see any movement to allow these... Please don't propagate the confusion between reserved keywords and built-in names! It's not a matter of 'confusion', more that there are some names you can't or shouldn't use in Python. When coding twisted, often the most obvious 'short' name for a Deferred is 'def', but of course that doesn't work. My point is that there are two reasons for not using such a name. With 'def', you *can't*. With 'len', you *could* (but it would be unwise). With 'id', IMO it's okay. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org 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/18/05, Guido van Rossum [EMAIL PROTECTED] wrote: On 8/17/05, Anthony Baxter [EMAIL PROTECTED] wrote: If you _really_ want to call a local variable 'id' you can (but shouldn't). Disagreed. The built-in namespace is searched last for a reason -- the design is such that if you don't care for a particular built-in you don't need to know about it. In practice, it causes much confusion if you ever use a local variable that has the same name as the built-in namespace. If you intend to use id as a variable, it leads to confusing messages when a typo or editing error accidentally removes the definition, because the name will still be defined for you. It also leads to confusion when you later want to use the builtin in the same module or function (or in the debugger). If Python defines the name, I don't want to provide a redefinition. Jeremy ___ Python-Dev mailing list Python-Dev@python.org 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/19/05, Jeremy Hylton [EMAIL PROTECTED] wrote: On 8/18/05, Guido van Rossum [EMAIL PROTECTED] wrote: On 8/17/05, Anthony Baxter [EMAIL PROTECTED] wrote: If you _really_ want to call a local variable 'id' you can (but shouldn't). Disagreed. The built-in namespace is searched last for a reason -- the design is such that if you don't care for a particular built-in you don't need to know about it. In practice, it causes much confusion if you ever use a local variable that has the same name as the built-in namespace. If you intend to use id as a variable, it leads to confusing messages when a typo or editing error accidentally removes the definition, because the name will still be defined for you. It also leads to confusion when you later want to use the builtin in the same module or function (or in the debugger). If Python defines the name, I don't want to provide a redefinition. This has startled me a few times, but never for more than 30 seconds. In correct code there sure isn't any confusion. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org 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())
Anthony Baxter wrote: 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... This is getting off-topic, but... In C#, you can: you write @class, @void, @return. Apparently, this is so that you can access arbitrary COM objects (which may happen to use C# keywords as method names). Of course, we would put an underscore after the name in that case. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org 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, Anthony Baxter [EMAIL PROTECTED] wrote: If you _really_ want to call a local variable 'id' you can (but shouldn't). Disagreed. The built-in namespace is searched last for a reason -- the design is such that if you don't care for a particular built-in you don't need to know about it. You also can't/shouldn't call a variable 'class', 'def', or 'len' -- but I don't see any movement to allow these... Please don't propagate the confusion between reserved keywords and built-in names! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/pedronis%40strakt.com ___ Python-Dev mailing list Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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 Python-Dev@python.org 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
Python-Dev@python.org
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
