James Y Knight wrote:
> 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()
>>>
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
[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
> > [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
> [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.
The dir() builtin does quite a bit more than obj.__dict__.keys().
>>> class A(list):
x = 1
>>> dir(A)
['__add__', '__class__', '__contains__', '__delattr__', '__d
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
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
[Michael Hudson]
> I wonder if dir() should strip non-strings?
-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-strin
Guido van Rossum wrote:
> (3) I think a better patch is to use str(word)[:n] instead of word[:n].
Mmh, I'm not so sure that's a good idea, as it leads to this:
In [1]: class f: pass
...:
In [2]: a=f()
In [3]: a.__dict__[1] = 8
In [4]: a.x = 0
In [5]: a.
a.1 a.x
In [5]: a.1
-
Michael Hudson wrote:
> [EMAIL PROTECTED] writes:
>
>> You don't need something like a buggy SWIG to put non-strings in dir().
>>
> class C: pass
>> ...
> C.__dict__[3] = "bad wolf"
> dir(C)
>> [3, '__doc__', '__module__']
>>
>> This is likely to happen "legitimately", for instance in
[EMAIL PROTECTED] writes:
> You don't need something like a buggy SWIG to put non-strings in dir().
>
class C: pass
> ...
C.__dict__[3] = "bad wolf"
dir(C)
> [3, '__doc__', '__module__']
>
> This is likely to happen "legitimately", for instance in a class that allows
> x.y and x['y'
You don't need something like a buggy SWIG to put non-strings in dir().
>>> class C: pass
...
>>> C.__dict__[3] = "bad wolf"
>>> dir(C)
[3, '__doc__', '__module__']
This is likely to happen "legitimately", for instance in a class that allows
x.y and x['y'] to mean the same thing. (if the user ass
Guido van Rossum wrote:
> (1) Please use the SF patch manager.
>
> (2) Please don't propose adding more bare "except:" clauses to the
> standard library.
>
> (3) I think a better patch is to use str(word)[:n] instead of word[:n].
Sorry to jump in, but this same patch was proposed for ipython, a
(1) Please use the SF patch manager.
(2) Please don't propose adding more bare "except:" clauses to the
standard library.
(3) I think a better patch is to use str(word)[:n] instead of word[:n].
On 8/14/05, Michael Krasnyk <[EMAIL PROTECTED]> wrote:
> Hello all,
>
> Recently I've found that rlco
15 matches
Mail list logo
