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
[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
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
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
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
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
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.
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, 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, 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 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-stri
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 possibl
[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__', '__d
> [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
> > [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 po
[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!), b
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 testi
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 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 poss
-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
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.
21 matches
Mail list logo
