Guido van Rossum wrote:
(what about vars(), btw?)
Interesting question! Right now vars() and dir() don't seem to use the
same set of keys; e.g.:
class C: pass
...
c = C()
c.foo = 42
vars(c)
{'foo': 42}
dir(c)
['__doc__', '__module__', 'foo']
It makes some sense for vars(x) to
Fredrik Lundh wrote:
Guido van Rossum wrote:
No objection on targetting 2.6 if other developers agree. Seems this
is well under way. good work!
given that dir() is used extensively by introspection tools, I'm
not sure I'm positive to a __dir__ that *overrides* the standard
dir()
Fredrik Lundh wrote:
Guido van Rossum wrote:
No objection on targetting 2.6 if other developers agree. Seems this
is well under way. good work!
given that dir() is used extensively by introspection tools, I'm
not sure I'm positive to a __dir__ that *overrides* the standard
dir()
Guido van Rossum wrote:
No objection on targetting 2.6 if other developers agree. Seems this
is well under way. good work!
given that dir() is used extensively by introspection tools, I'm
not sure I'm positive to a __dir__ that *overrides* the standard
dir() behaviour. *adding* to the default
On 11/10/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
No objection on targetting 2.6 if other developers agree. Seems this
is well under way. good work!
given that dir() is used extensively by introspection tools, I'm
not sure I'm positive to a __dir__ that
Fredrik Lundh schrieb:
Guido van Rossum wrote:
No objection on targetting 2.6 if other developers agree. Seems this
is well under way. good work!
given that dir() is used extensively by introspection tools, I'm
not sure I'm positive to a __dir__ that *overrides* the standard
dir()
Guido van Rossum wrote:
I think that ought to go into the guidlines for what's an acceptable
__dir__ implementation. We don't try to stop people from overriding
__add__ as subtraction either.
to me, overriding dir() is a lot more like overriding id() than over-
riding +. I don't think an
On 11/10/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
I think that ought to go into the guidlines for what's an acceptable
__dir__ implementation. We don't try to stop people from overriding
__add__ as subtraction either.
to me, overriding dir() is a lot more like
On Tuesday 07 November 2006 19:00, Guido van Rossum wrote:
No objection on targetting 2.6 if other developers agree. Seems this
is well under way. good work!
Sounds fine to me! Less magic under the hood is less magic, and that's always
a good thing. The use case for it seems completely
okay, everything's fixed.
i updated the patch and added a small test to:
Lib/test/test_builtins.py::test_dir
-tomer
On 11/7/06, Nick Coghlan [EMAIL PROTECTED] wrote:
tomer filiba wrote:
cool. first time i build the entire interpreter, 'twas fun :)
currently i retained support for
as well as updating the documentation in various
places (the dir and PyObject_Dir documentation, obviously, but also the list
of magic methods in the language reference).
oops, i meant everything except that
-tomer
On 11/7/06, tomer filiba [EMAIL PROTECTED] wrote:
okay, everything's fixed.
so, if you remember, i suggested adding __dir__ to objects, so as to make
dir() customizable, remove the deprecated __methods__ and __members__,
and make it symmetrical to other built-in functions.
you can see the original post here:
cool. first time i build the entire interpreter, 'twas fun :)
currently i retained support for __members__ and __methods__,
so it doesn't break anything and is compatible with 2.6.
i really hope it will be included in 2.6 as today i'm using ugly hacks
in RPyC to make remote objects appear like
tomer filiba wrote:
cool. first time i build the entire interpreter, 'twas fun :)
currently i retained support for __members__ and __methods__,
so it doesn't break anything and is compatible with 2.6.
i really hope it will be included in 2.6 as today i'm using ugly hacks
in RPyC to make
14 matches
Mail list logo
