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()
corresponding as
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-strings
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 possible to the
[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__',
[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 an
[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!), but apart
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 possible to the
[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'] to mean the same
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 a class that allows
x.y and
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.TAB HIT HERE
a.1 a.x
In [5]: a.1
[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
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 class 'mywrapper.IClassPtr'.
And condition word[:n] == attr throws an exception.
Is it possible to
(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
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 assigns to
14 matches
Mail list logo
