Re: [Python-Dev] Python Doc problems

Barry Warsaw wrote: > There's also the pull between wanting to write reference docs for > those who know what they've forgotten (I love that phrase!) and > writing the introductory or "how it hangs together" documentation. The trick to this, I think, is not to try to make the same piece of d

Re: [Python-Dev] Python Doc problems

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 28, 2006, at 8:49 PM, <[EMAIL PROTECTED]> wrote: > What is lost according to him is information about how the elements of > a module work together. The docstrings tend to be narrowly focused on > the particular function or variable, and too of

Re: [Python-Dev] Python Doc problems

[EMAIL PROTECTED] wrote: > xah lee writes: > > > anyway, i've rewrote the Python's RE module documentation, at: > > http://xahlee.org/perl-python/python_re-write/lib/module-re.html > > -1 > > The current docs could be improved (but not by me, at least not > today), but I don't consider the g

[Python-Dev] Python Doc problems

xah lee writes: > anyway, i've rewrote the Python's RE module documentation, at: > http://xahlee.org/perl-python/python_re-write/lib/module-re.html -1 The current docs could be improved (but not by me, at least not today), but I don't consider the general direction of Xah's edits desirable.

Re: [Python-Dev] Python Doc problems

Josiah Carlson writes: > fine). While I have heard comments along the lines of "the docs could > be better", I've never heard the claim that the Python docs are "lousy". FYI, I have heard this, recently, from Tom Lord (aka developer of Arch, rx, guile, etc). Since he also took a swipe at Emac

Re: [Python-Dev] weakref enhancements

Raymond Hettinger wrote: > Also, I question the utility of maintaining a weakref to a method or > attribute instead of holding one for the object or class. As long as > the enclosing object or class lives, so too will their methods and > attributes. So what is the point of a tighter weakref gr

Re: [Python-Dev] weakref enhancements

On 9/28/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > There are *definitely* use cases for keeping bound methods around. > > > > Contrived example: > > > >one_of = set([1,2,3,4]).__contains__ > >filter(one_of, [2,4,6,8,10]) > > ISTM, the example shows the (undisputed) utility of regu

Re: [Python-Dev] weakref enhancements

> There are *definitely* use cases for keeping bound methods around. > > Contrived example: > >one_of = set([1,2,3,4]).__contains__ >filter(one_of, [2,4,6,8,10]) ISTM, the example shows the (undisputed) utility of regular bound methods. How does it show the need for methods bound weakly t

Re: [Python-Dev] weakref enhancements

On 9/28/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [Alex Martelli] > > >I've had use cases for "weakrefs to boundmethods" (and there IS a > >Cookbook recipe for them), > > > Weakmethods make some sense (though they raise the question of why bound > methods are being kept when the underlying

Re: [Python-Dev] weakref enhancements

[Alex Martelli] >I've had use cases for "weakrefs to boundmethods" (and there IS a >Cookbook recipe for them), > Weakmethods make some sense (though they raise the question of why bound methods are being kept when the underlying object is no longer in use -- possibly as unintended side-effect of

Re: [Python-Dev] weakref enhancements

On 9/28/06, tomer filiba <[EMAIL PROTECTED]> wrote: > > I'm sceptical that these would find use in practice. > > [..] > > Also, I question the utility of maintaining a weakref to a method or > > attribute instead of holding one for the object or class. As long as > > the enclosing object or class

Re: [Python-Dev] weakref enhancements

> I'm sceptical that these would find use in practice.> [..]> Also, I question the utility of maintaining a weakref to a method or> attribute instead of holding one for the object or class.  As long as > the enclosing object or class lives, so too will their methods and> attributes.  So what is the

Re: [Python-Dev] difficulty of implementing phase 2 of PEP 302 in Python source

> Phillip J. Eby schrieb: > > I would say that the C code is *delicate*, not necessarily bad. In most > > ways, it's rather straightforward, it's actually the requirements that are > > complex. :) >From what I recall, that's right. The C code's main disadvantage is that it isn't very well comme

Re: [Python-Dev] weakref enhancements

> Also, I question the utility of maintaining a weakref to a method or > attribute instead of holding one for the object or class. Strike that paragraph -- the proposed weakattrs have references away from the object, not to the object. Raymond ___ Py

Re: [Python-Dev] weakref enhancements

tomer filiba wrote: > i'd like to suggest adding weak attributes and weak methods to the std > weakref > module. . . . > > i think these two features are quite useful, and being part of the > stdlib, would > provide programmers with easy-to-use solutions to object-aliveness issues. > > more i

Re: [Python-Dev] difficulty of implementing phase 2 of PEP 302 in Python source

Phillip J. Eby schrieb: > At 11:25 AM 9/28/2006 -0700, Brett Cannon wrote: >>I will think about it, but I am still trying to get the original question >>of how bad the C code is compared to rewriting import in Python from >>people. =) > > I would say that the C code is *delicate*, not necessari

[Python-Dev] weakref enhancements

i'd like to suggest adding weak attributes and weak methods to the std weakrefmodule. weakattrs are weakly-referenced attributes. when the value they reference is no longer strongly-referenced by something else, the weakattrs "nullify" themselves. weakmethod is a method decorator, like classmethod

Re: [Python-Dev] difficulty of implementing phase 2 of PEP 302 in Python source

At 11:25 AM 9/28/2006 -0700, Brett Cannon wrote: >I will think about it, but I am still trying to get the original question >of how bad the C code is compared to rewriting import in Python from >people. =) I would say that the C code is *delicate*, not necessarily bad. In most ways, it's rath

Re: [Python-Dev] difficulty of implementing phase 2 of PEP 302 in Python source

On 9/27/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: At 05:26 PM 9/27/2006 -0700, Brett Cannon wrote:>Ah, OK.  So for importing 'email', the zipimporter would call the .pyc>importer and it would ask the zipimporter, "can you get me email.pyc?" and >if it said no it would move on to asking the .py

Re: [Python-Dev] Python Doc problems

xah lee <[EMAIL PROTECTED]> wrote: > There are a lot reports on the lousy state of python docs. I'm not > much in the python community so i don't know what the developers are > doing anything about it. I don't know about everyone else, but when I recieve comments like "the docs are lousy, fix

Re: [Python-Dev] AST structure and maintenance branches

On 9/28/06, Anthony Baxter <[EMAIL PROTECTED]> wrote: > On Friday 29 September 2006 00:30, Jeremy Hylton wrote: > > On 9/23/06, Anthony Baxter <[EMAIL PROTECTED]> wrote: > > > I'd like to propose that the AST format returned by passing PyCF_ONLY_AST > > > to compile() get the same guarantee in main

Re: [Python-Dev] AST structure and maintenance branches

On Friday 29 September 2006 00:30, Jeremy Hylton wrote: > On 9/23/06, Anthony Baxter <[EMAIL PROTECTED]> wrote: > > I'd like to propose that the AST format returned by passing PyCF_ONLY_AST > > to compile() get the same guarantee in maintenance branches as the > > bytecode format - that is, unless

Re: [Python-Dev] AST structure and maintenance branches

On 9/23/06, Anthony Baxter <[EMAIL PROTECTED]> wrote: > I'd like to propose that the AST format returned by passing PyCF_ONLY_AST to > compile() get the same guarantee in maintenance branches as the bytecode > format - that is, unless it's absolutely necessary, we'll keep it the same. > Otherwise a

[Python-Dev] Collecting 2.4.4 fixes

I've put some candidate fixes and listed some tasks at . --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/

[Python-Dev] Python Doc problems

There are a lot reports on the lousy state of python docs. I'm not much in the python community so i don't know what the developers are doing anything about it. anyway, i've rewrote the Python's RE module documentation, at: http://xahlee.org/perl-python/python_re-write/lib/module-re.html and