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
Hello all,
Recently I've found that rlcompleter does not work correctly with SWIG
generated classes.
In some cases dir(object) containes not only strings, but also type of
the object, smth like .
And condition "word[:n] == attr" throws an exception.
Is it possible to solve this problem with follo
16 matches
Mail list logo
