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:
http://mail.python.org/pipermail/python-dev/2006-July/067095.htm
Sounds like a good plan, though I'm not sure if it's worth doing in
2.6 -- I'd be happy with doing this just in 3k.
I'm not sure what you mean by "adding a method slot" -- certainly it's
possible to define a method __foo__ and call it directly without
having a special tp_foo in the type object, an
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 l
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 m
No objection on targetting 2.6 if other developers agree. Seems this
is well under way. good work!
On 11/6/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> tomer filiba wrote:
> > cool. first time i build the entire interpreter, 'twas fun :)
> > currently i "retained" support for __members__ and __me
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 approp
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 fi
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 defaul
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
Thomas Heller 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*
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 a
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
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
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()
17 matches
Mail list logo
