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 y
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
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
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
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 do
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
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...
Th
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.
-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
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 li
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
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. f
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
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.
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
> pla
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 t
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 exp
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
[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
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 m
20 matches
Mail list logo
