Re: [Python-Dev] weakref enhancements
this may still be premature, but i see people misunderstood the purpose.
weakattrs are not likely to be used "externally", out of the scope of
the object.
they are just meant to provide an easy to use means for not holding cyclic
references between parents and children.
many graph-like structures, i.e., rpyc's node and proxies, are interconnected
in both ways, and weakattrs help to solve that: i don't want a proxy of a node
to keep the node alive.
weakmethods are used very similarly. nodes have a method called
"getmodule", that performs remote importing of modules. i expose these
modules as a namespace object, so you could do:
>>> mynode.modules.sys
or
>>> mynode.modules.xml.dom.minidom.parseString
instead of
>>> mynode.getmodule("xml.dom.minidom").parseString
here's a sketch:
def ModuleNamespace:
def __init__(self, importerfunc):
self.importerfunc = importerfunc
class Node:
def __init__(self, stream):
self.modules = ModuleNamespace(self.getmodule)
@ weakmethod
def getmodule(self, name):
i define this getmodule method as a *weakmethod*, so the mere existence
of the ModuleNamespace instance will not keep the node alive. when the
node loses all external references, the ModuleNamespace should just
"commit suicide", and allow the node to be reclaimed.
yes, you can do all of these with today's weakref, but it takes quite
a lot of hassle to manually set up weakproxies every time.
-tomer
On 9/29/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 object is no longer in use --
> possibly as unintended side-effect of aggressive optimization).
>
> I'm more concerned about weakattr which hides the weak referencing from
> client code when it is usually the client that needs to know about the
> refcounts:
>
>n = SomeClass(x)
>obj.a = n
>del n # hmm, what happens now?
>
> If obj.a is a weakattr, then n get vaporized; otherwise, it lives.
>
> It is clearer and less error-prone to keep the responsibility with the
> caller:
>
>n = SomeClass(x)
>obj.a = weakref.proxy(n)
>del n # now, it is clear what happens
>
> The wiki-space example shows objects that directly assign a copy of self
> to an attribute of self. Even in that simplified, self-referential
> example, it is clear that correct functioning (when __del__ gets called)
> depends knowing whether or not assignments are creating references.
> Accordingly, the code would be better-off if the weak-referencing
> assignment was made explicit rather than hiding the weak-referencing
> wrapper in a descriptor.
>
>
>
> Raymond
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Caching float(0.0)
I just discovered that in a program of mine it was wasting 7MB out of 200MB by storing multiple copies of 0.0. I found this a bit suprising since I'm used to small ints and strings being cached. I added the apparently nonsensical lines +if age == 0.0: +age = 0.0 # return a common object for the common case and got 7MB of memory back! Eg :- Python 2.5c1 (r25c1:51305, Aug 19 2006, 18:23:29) [GCC 4.1.2 20060814 (prerelease) (Debian 4.1.1-11)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a=0.0 >>> print id(a), id(0.0) 134738828 134738844 >>> Is there any reason why float() shouldn't cache the value of 0.0 since it is by far and away the most common value? A full cache of floats probably doesn't make much sense though since there are so many 'more' of them than integers and defining small isn't obvious. -- Nick Craig-Wood <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Doc problems
On 29-sep-2006, at 4:24, Greg Ewing wrote: An example of a good way to do it is the original Inside Macintosh series. Each chapter started with a narrative-style "About this module" kind of section, that introduced the relevant concepts and explained how they fitted together, without going into low-level details. Then there was a "Reference" section that systematically went through and gave all the details of the API. Yep, this is exactly what I often miss in the Python library docs. The module intro sections often do contain the "executive summary" of the module, so that you can quickly see whether this module could indeed help you solve the problem at hand. But then you go straight to descriptions of classes and methods, and there is often no info on how things are plumbed together, both within the module (how the classes relate to each other) and more globally (how this module relates to others, see also). A similar thing occurs one level higher in the library hierarchy: the section introductions are little more that a list of all the modules in the section. -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Doc problems
On Fri, Sep 29, 2006 at 09:49:35AM +0900, [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 often discuss > implementation details. I agree with this, and am not very interested in tools such as epydoc for this reason. In such autogenerated documentation, you wind up with a list of every single class and function, and both trivial and important classes are given exactly the same emphasis. Such docs are useful as a reference when you know what class you need to look at, but then pydoc also works well for that purpose. --amk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] os.unlink() closes file?
It seems (I haven't looked at source) that os.unlink() will close the file? If so, please make this optional. It breaks the unix idiom for making a temporary file. (Yes, I know there is a tempfile module, but I need some behavior it doesn't implement so I want to do it myself). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.unlink() closes file?
On Friday, September 29, 2006, at 02:22PM, Neal Becker <[EMAIL PROTECTED]> wrote: >It seems (I haven't looked at source) that os.unlink() will close the file? > >If so, please make this optional. It breaks the unix idiom for making a >temporary file. > >(Yes, I know there is a tempfile module, but I need some behavior it doesn't >implement so I want to do it myself). On what platform? Do you have a script that demonstrates your problem? If yes, please file a bug in the bugtracker at http://www.sf.net/projects/python. AFAIK os.unlink doesn't close files, and I cannot reproduce this problem (python2.3 on Solaris 9). Ronald ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Doc problems
Andrew> In such autogenerated documentation, you wind up with a list of Andrew> every single class and function, and both trivial and important Andrew> classes are given exactly the same emphasis. I find this true where I work as well. Doxygen is used as a documentation generation tool for our C++ class libraries. Too many people use that as a crutch to often avoid writing documentation altogether. It's worse in many ways than tools like epydoc, because you don't need to write any docstrings (or specially formatted comments) to generate reams and reams of virtual paper. This sort of documentation is all but useless for a Python programmer like myself. I don't really need to know the five syntactic constructor variants. I need to know how to use the classes which have been exposed to me. I guess this is a long-winded way of saying, "me too". Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.unlink() closes file?
Ronald Oussoren wrote: > > On Friday, September 29, 2006, at 02:22PM, Neal Becker > <[EMAIL PROTECTED]> wrote: > >>It seems (I haven't looked at source) that os.unlink() will close the >>file? >> >>If so, please make this optional. It breaks the unix idiom for making a >>temporary file. >> >>(Yes, I know there is a tempfile module, but I need some behavior it >>doesn't implement so I want to do it myself). > > On what platform? Do you have a script that demonstrates your problem? If > yes, please file a bug in the bugtracker at > http://www.sf.net/projects/python. > > AFAIK os.unlink doesn't close files, and I cannot reproduce this problem > (python2.3 on Solaris 9). > Sorry, my mistake. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Caching float(0.0)
Nick Craig-Wood wrote: > Is there any reason why float() shouldn't cache the value of 0.0 since > it is by far and away the most common value? says who ? (I just checked the program I'm working on, and my analysis tells me that the most common floating point value in that program is 121.216, which occurs 32 times. from what I can tell, 0.0 isn't used at all.) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Caching float(0.0)
Acting on this excellent advice, I have patched in a reuse for -1.0, 0.0 and 1.0 for EVE Online. We use vectors and stuff a lot, and 0.0 is very, very common. I'll report on the refcount of this for you shortly. K > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > On Behalf Of Fredrik Lundh > Sent: 29. september 2006 15:11 > To: [email protected] > Subject: Re: [Python-Dev] Caching float(0.0) > > Nick Craig-Wood wrote: > > > Is there any reason why float() shouldn't cache the value > of 0.0 since > > it is by far and away the most common value? > > says who ? > > (I just checked the program I'm working on, and my analysis > tells me that the most common floating point value in that > program is 121.216, which occurs 32 times. from what I can > tell, 0.0 isn't used at all.) > > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/kristjan%40c cpgames.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Caching float(0.0)
Well gentlemen, I did gather some stats on the frequency of
PyFloat_FromDouble().
out of the 1000 first different floats allocated, we get this frequency
distribution once our server has started up:
- stats [1000]({v=0.0 c=410612
},{v=1. c=107838 },{v=0.75000 c=25487
},{v=5. c=22557 },...) std::vector >
+ [0] {v=0.0 c=410612 } entry
+ [1] {v=1. c=107838 }entry
+ [2] {v=0.75000 c=25487 }entry
+ [3] {v=5. c=22557 } entry
+ [4] {v=1. c=18530 } entry
+ [5] {v=-1. c=14950 }entry
+ [6] {v=2. c=14460 } entry
+ [7] {v=1500.0 c=13470 } entry
+ [8] {v=100.00 c=11913 } entry
+ [9] {v=0.5 c=11497 }entry
+ [10]{v=3. c=9833 } entry
+ [11]{v=20.000 c=9019 } entry
+ [12]{v=0.90002 c=8954 } entry
+ [13]{v=10.000 c=8377 } entry
+ [14]{v=4. c=7890 } entry
+ [15]{v=0.050003 c=7732 }entry
+ [16]{v=1000.0 c=7456 } entry
+ [17]{v=0.40002 c=7427 } entry
+ [18]{v=-100.00 c=7071 } entry
+ [19]{v=5000.0 c=6851 } entry
+ [20]{v=100.00 c=6503 } entry
+ [21]{v=0.070007 c=6071 }entry
(here I omit the rest).
In addition, my shared 0.0 double has some 20 references at this point.
0.0 is very, very common. The same can be said about all the integers up to
5.0 as well as -1.0
I think I will add a simple cache for these values for Eve.
something like:
int i = (int) fval;
if ((double)i == fval && i>=-1 && i<6) {
Py_INCREF(table[i]);
return table[i];
}
Cheers,
Kristján
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> On Behalf Of Kristján V. Jónsson
> Sent: 29. september 2006 15:18
> To: Fredrik Lundh; [email protected]
> Subject: Re: [Python-Dev] Caching float(0.0)
>
> Acting on this excellent advice, I have patched in a reuse
> for -1.0, 0.0 and 1.0 for EVE Online. We use vectors and
> stuff a lot, and 0.0 is very, very common. I'll report on
> the refcount of this for you shortly.
>
> K
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]
> > On Behalf Of Fredrik Lundh
> > Sent: 29. september 2006 15:11
> > To: [email protected]
> > Subject: Re: [Python-Dev] Caching float(0.0)
> >
> > Nick Craig-Wood wrote:
> >
> > > Is there any reason why float() shouldn't cache the value
> > of 0.0 since
> > > it is by far and away the most common value?
> >
> > says who ?
> >
> > (I just checked the program I'm working on, and my analysis
> tells me
> > that the most common floating point value in that program
> is 121.216,
> > which occurs 32 times. from what I can tell, 0.0 isn't
> used at all.)
> >
> >
> >
> > ___
> > Python-Dev mailing list
> > [email protected]
> > http://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe:
> > http://mail.python.org/mailman/options/python-dev/kristjan%40c
> cpgames.com
> >
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/kristjan%40c
cpgames.com
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 355 status
What's the status of PEP 355, Path - Object oriented filesystem paths? We'd like to start using the current reference implementation but we'd like to do it in a manner that minimizes any changes needed when Path becomes part of stdlib. In particular, the reference implementation in http://wiki.python.org/moin/PathModule names the class 'path' instead of 'Path', which seems like a source of name conflict problems. How would you recommend one starts using it now, as is or renaming class path to Path? Thanks -- Luis P Caamano Atlanta, GA USA ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Caching float(0.0)
On 9/29/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > (I just checked the program I'm working on, and my analysis tells me > that the most common floating point value in that program is 121.216, > which occurs 32 times. from what I can tell, 0.0 isn't used at all.) *bemused look* Fredrik, can you share the reason why this number occurs 32 times in this program? I don't mean to imply anything by that; it just sounds like it might be a fun story. :) Anyway, this kind of static analysis is probably more entertaining than relevant. For your enjoyment, the most-used float literals in python25\Lib, omitting test directories, are: 1e-006: 5 hits 4.0: 6 hits 0.05: 7 hits 6.0: 8 hits 0.5: 13 hits 2.0: 25 hits 0.0: 36 hits 1.0: 62 hits There are two hits each for -1.0 and -0.5. In my own Python code, I don't even have enough float literals to bother with. -j ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Caching float(0.0)
"Jason Orendorff" <[EMAIL PROTECTED]> wrote: > > Anyway, this kind of static analysis is probably more entertaining > than relevant. ... Well, yes. One can tell that by the piffling little counts being bandied about! More seriously, yes, it is Well Known that 0.0 is the Most Common Floating-Point Number is most numerical codes; a lot of older (and perhaps modern) sparse matrix algorithms use that to save space. In the software floating-point that I have started to draft some example code but have had to shelve (no, I haven't forgotten) the values I predefine are Invalid, Missing, True Zero and Approximate Zero. The infinities and infinitesimals (a.k.a. signed zeroes) could also be included, but are less common and more complicated. And so could common integers and fractions. It is generally NOT worth doing a cache lookup for genuinely numerical code, as the common cases that are not the above rarely account for enough of the numbers to be worth it. I did a fair amount of investigation looking for compressibility at one time, and that conclusion jumped out at me. The exact best choice depends entirely on what you are doing. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Caching float(0.0)
I see some confusion in this thread. If a *LITERAL* 0.0 (or any other float literal) is used, you only get one object, no matter how many times it is used. But if the result of a *COMPUTATION* returns 0.0, you get a new object for each such result. If you have 70 MB worth of zeros, that's clearly computation results, not literals. Attempts to remove literal references from source code won't help much. I'm personally +0 on caching computational results with common float values such as 0 and small (positive or negative) powers of two, e.g. 0.5, 1.0, 2.0. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Doc problems
On 9/29/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > An example of a good way to do it is the original Inside > Macintosh series. Each chapter started with a narrative-style > "About this module" kind of section, that introduced the > relevant concepts and explained how they fitted together, > without going into low-level details. Then there was a > "Reference" section that systematically went through and > gave all the details of the API. The "How to use this module" sections sound like /F's "The Python Standard Library", of which I keep the dead tree version on my desk and the PDF vesion on my hard drive for when I'm coding in the pub. It or something like it would be a superb addition to the (already very good IMHO) Python docs. -- Cheers, Simon B, [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Doc problems
Simon Brunning wrote: > The "How to use this module" sections sound like /F's "The Python > Standard Library", of which I keep the dead tree version on my desk > and the PDF vesion on my hard drive for when I'm coding in the pub. It > or something like it would be a superb addition to the (already very > good IMHO) Python docs. that's what my old seealso proposal was supposed to address: http://effbot.org/zone/idea-seealso.htm the standard library's seealso file is here: http://effbot.org/librarybook/seealso.xml ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Doc problems
On 9/29/06, A.M. Kuchling <[EMAIL PROTECTED]> wrote: > On Fri, Sep 29, 2006 at 09:49:35AM +0900, [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 often discuss > > implementation details. > > I agree with this, and am not very interested in tools such as epydoc > for this reason. In such autogenerated documentation, you wind up > with a list of every single class and function, and both trivial and > important classes are given exactly the same emphasis. Such docs are > useful as a reference when you know what class you need to look at, > but then pydoc also works well for that purpose. Right. BTW isn't xah a well-known troll? (There are exactly 666 Google hits for the query ``xah troll'' -- draw your own conclusions. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 355 status
I would recommend not using it. IMO it's an amalgam of unrelated functionality (much like the Java equivalent BTW) and the existing os and os.path modules work just fine. Those who disagree with me haven't done a very good job of convincing me, so I expect this PEP to remain in limbo indefinitely, until it is eventually withdrawn or rejected. --Guido On 9/29/06, Luis P Caamano <[EMAIL PROTECTED]> wrote: > What's the status of PEP 355, Path - Object oriented filesystem paths? > > We'd like to start using the current reference implementation but we'd > like to do it in a manner that minimizes any changes needed when Path > becomes part of stdlib. > > In particular, the reference implementation in > http://wiki.python.org/moin/PathModule names the class 'path' instead > of 'Path', which seems like a source of name conflict problems. > > How would you recommend one starts using it now, as is or renaming > class path to Path? > > Thanks > > -- > Luis P Caamano > Atlanta, GA USA > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 355 status
Thanks for your reply, that's the kind of info I was looking for to decide what to do. Good enough, I'll move on then. Thanks -- Luis P Caamano Atlanta, GA USA On 9/29/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > I would recommend not using it. IMO it's an amalgam of unrelated > functionality (much like the Java equivalent BTW) and the existing os > and os.path modules work just fine. Those who disagree with me haven't > done a very good job of convincing me, so I expect this PEP to remain > in limbo indefinitely, until it is eventually withdrawn or rejected. > > --Guido > > On 9/29/06, Luis P Caamano <[EMAIL PROTECTED]> wrote: > > What's the status of PEP 355, Path - Object oriented filesystem paths? > > > > We'd like to start using the current reference implementation but we'd > > like to do it in a manner that minimizes any changes needed when Path > > becomes part of stdlib. > > > > In particular, the reference implementation in > > http://wiki.python.org/moin/PathModule names the class 'path' instead > > of 'Path', which seems like a source of name conflict problems. > > > > How would you recommend one starts using it now, as is or renaming > > class path to Path? > > > > Thanks > > > > -- > > Luis P Caamano > > Atlanta, GA USA > > ___ > > Python-Dev mailing list > > [email protected] > > http://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > > http://mail.python.org/mailman/options/python-dev/guido%40python.org > > > > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 355 status
Shouldn't that paragraph be added to the PEP (e.g. under a "Status" subheading)? enjoying-top-posting-ly, Georg Guido van Rossum wrote: > I would recommend not using it. IMO it's an amalgam of unrelated > functionality (much like the Java equivalent BTW) and the existing os > and os.path modules work just fine. Those who disagree with me haven't > done a very good job of convincing me, so I expect this PEP to remain > in limbo indefinitely, until it is eventually withdrawn or rejected. > > --Guido > > On 9/29/06, Luis P Caamano <[EMAIL PROTECTED]> wrote: >> What's the status of PEP 355, Path - Object oriented filesystem paths? >> >> We'd like to start using the current reference implementation but we'd >> like to do it in a manner that minimizes any changes needed when Path >> becomes part of stdlib. >> >> In particular, the reference implementation in >> http://wiki.python.org/moin/PathModule names the class 'path' instead >> of 'Path', which seems like a source of name conflict problems. >> >> How would you recommend one starts using it now, as is or renaming >> class path to Path? >> >> Thanks >> >> -- >> Luis P Caamano >> Atlanta, GA USA >> ___ >> Python-Dev mailing list >> [email protected] >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/guido%40python.org >> > > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Doc problems
> If there are "rampant criticisms" of the Python docs, then those that > are complaining should take specific examples of their complaints to the > sourceforge bug tracker and submit documentation patches for the > relevant sections. And personally, I've not noticed that criticisms of > the Python docs are "rampant", but maybe there is some "I hate Python > docs" newsgroup or mailing list that I'm not subscribed to. Meh! The number one complaint IS that you have to take your complaints to the sourceforge bug tracker and submit documentation patches. For documentation changes, that is way to much overhead for to little gain. But thankfully I think there are people working on fixing those problems which is very nice. -- mvh Björn ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Tix not included in 2.5 for Windows
Does anyone know why this happens? I can't find any information pointing to this being deliberate. I just upgraded to 2.5 on Windows (after making sure I can build extensions with the freeware VC++ Toolkit 2003) and some of my programs stopped operating. I saw in a French forum that someone else had the same problem, and what they did was to copy the relevant files from a 2.4.3 installation. I did the same, and it seems it works, with only a console message appearing as soon as a root window is created: attempt to provide package Tix 8.1 failed: package Tix 8.1.8.4 provided instead Cheers. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Doc problems
"BJörn Lindqvist" <[EMAIL PROTECTED]> wrote: > > If there are "rampant criticisms" of the Python docs, then those that > > are complaining should take specific examples of their complaints to the > > sourceforge bug tracker and submit documentation patches for the > > relevant sections. And personally, I've not noticed that criticisms of > > the Python docs are "rampant", but maybe there is some "I hate Python > > docs" newsgroup or mailing list that I'm not subscribed to. > > Meh! The number one complaint IS that you have to take your complaints > to the sourceforge bug tracker and submit documentation patches. For > documentation changes, that is way to much overhead for to little > gain. But thankfully I think there are people working on fixing those > problems which is very nice. Are you telling me that people want to be able to complain into the ether and get their complaints heard? I hope not, because that would be insane. Also, "doc patches" are basically "the function foo() should be documented as ...", users don't need to know or learn TeX. Should there be an easier method of submitting doc fixes, etc.? Sure. But people are still going to need to actually *report* the fixes they want, which they aren't doing in *any* form now. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Doc problems
On 9/29/06, BJörn Lindqvist <[EMAIL PROTECTED]> wrote: > If there are "rampant criticisms" of the Python docs, then those that> are complaining should take specific examples of their complaints to the> sourceforge bug tracker and submit documentation patches for the > relevant sections. And personally, I've not noticed that criticisms of> the Python docs are "rampant", but maybe there is some "I hate Python> docs" newsgroup or mailing list that I'm not subscribed to. Meh! The number one complaint IS that you have to take your complaintsto the sourceforge bug tracker and submit documentation patches. Fordocumentation changes, that is way to much overhead for to little gain. But thankfully I think there are people working on fixing thoseproblems which is very nice.The PSF Infrastructure committe has already met and drafted our suggestions. Expect a post to the list on Monday or Tuesday outlining our recommendation on a new issue tracker. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Caching float(0.0)
Nick Craig-Wood wrote: > Is there any reason why float() shouldn't cache the value of 0.0 since > it is by far and away the most common value? 1.0 might be another candidate for cacheing. Although the fact that nobody has complained about this before suggests that it might not be a frequent enough problem to be worth the effort. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Caching float(0.0)
On 9/29/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > Nick Craig-Wood wrote: > > > Is there any reason why float() shouldn't cache the value of 0.0 since > > it is by far and away the most common value? > > 1.0 might be another candidate for cacheing. > > Although the fact that nobody has complained about this > before suggests that it might not be a frequent enough > problem to be worth the effort. My guess is that people do have this problem, they just don't know where that memory has gone. I know I don't count objects unless I have a process that's leaking memory or it grows so big that I notice (by swapping or chance). That said, I've never noticed this particular issue.. but I deal with mostly strings. I have had issues with the allocator a few times that I had to work around, but not this sort of issue. -bob ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Doc problems
Josiah Carlson wrote:
> "BJörn Lindqvist" <[EMAIL PROTECTED]> wrote:
>>> If there are "rampant criticisms" of the Python docs, then those that
>>> are complaining should take specific examples of their complaints to the
>>> sourceforge bug tracker and submit documentation patches for the
>>> relevant sections. And personally, I've not noticed that criticisms of
>>> the Python docs are "rampant", but maybe there is some "I hate Python
>>> docs" newsgroup or mailing list that I'm not subscribed to.
>> Meh! The number one complaint IS that you have to take your complaints
>> to the sourceforge bug tracker and submit documentation patches. For
>> documentation changes, that is way to much overhead for to little
>> gain. But thankfully I think there are people working on fixing those
>> problems which is very nice.
>
> Are you telling me that people want to be able to complain into the
> ether and get their complaints heard? I hope not, because that would be
> insane. Also, "doc patches" are basically "the function foo() should be
> documented as ...", users don't need to know or learn TeX. Should there
> be an easier method of submitting doc fixes, etc.? Sure. But people are
> still going to need to actually *report* the fixes they want, which they
> aren't doing in *any* form now.
Maybe a doc fix day (similar to the bug fix day) would be good. That way we
can
report a lot of minor doc fix's at once and then they can be fixed in batches.
For example of things I think may be thought of as too trivial to report but
effect readability and ease of use with pythons help() function ...
A *lot* of doc strings have lines that wrap when they are displayed by pythons
help() in a standard 80 column console window.
There are also two (maybe more) modules that have single backslash characters
in
their doc strings that get ate when viewed by pydoc.
cookielib.py - has single '\'s in a diagram.
SimpleXMLRPCServer.py - line 31... code example with line continuation.
I wonder if double \ should also be allowed as line continuations so that
doctests would look and work ok in doc strings when viewed by pythons help()?
Anyway if someone wants to search for other things of that type they can play
around with the hacked together tool included below. Setting it low enough so
that indented methods don't wrap with the help() function brings up several
thousand instances. I'm hoping most of those are duplicated/inherited doc
strings.
Many of those are documented format lines with the form ...
name( longs_list_of_arguments ... ) -> long_list_of_return_types ...
Rather than fix all of those, I'm changing the version of pydoc I've been
rewriting to wordwrap lines. Although that's not the prettiest solution, it's
better than breaking the indented margin.
Have fun... ;-)
Ron
"""
Find doc string lines are not longer than n characters.
Dedenting the doc strings before testing may give more
meaningful results.
"""
import sys
import os
import inspect
import types
class NullType(object):
""" A simple Null object to use when None is a valid
argument, or when redirecting print to Null. """
def write(self, *args):
pass
def __repr__(self):
return "Null"
Null = NullType()
check = 'CHECKING__'
checkerr = 'ERROR CHECKING'
err_obj = []
err_num = 0
stdout = sys.stdout
stderr = sys.stderr
seporator = ''
linelength = 100
def main():
sys_path = sys.path
# remove invalid dirs
for f in sys_path[:]:
try:
os.listdir(f)
except:
sys_path.remove(f)
#checkmodule('__builtin__')
for mod in sys.builtin_module_names:
checkmodule(mod)
for dir_ in sys.path:
for f in os.listdir(dir_):
if f.endswith('.py') or f.endswith('.pyw') or f.endswith('.pyd'):
try:
checkmodule(f.partition('.')[0])
except Exception:
print seporator
print checkerr, f, err_obj
print ' %s: %s' % (sys.exc_type.__name__, sys.exc_value)
print seporator
def checkmodule(modname):
global err_obj
err_obj = [modname]
# Silent text printed on import.
sys.stdout = sys.stderr = Null
try:
module = __import__(modname)
finally:
sys.stdout = stdout
sys.stderr = stderr
try:
checkobj(module) # module doc string
for o1 in dir(module):
obj1 = getattr(module, o1)
err_obj = [modname, o1]
checkobj(obj1) # class and function doc strings
for o2 in dir(obj1):
obj2 = getattr(obj1, o2)
err_obj = [modname, o1, o2]
checkobj(obj2) # method doc strings
finally:
del module
def checkobj(obj):
Re: [Python-Dev] PEP 355 status
On Fri, 29 Sep 2006 12:38:22 -0700, Guido van Rossum <[EMAIL PROTECTED]> wrote: >I would recommend not using it. IMO it's an amalgam of unrelated >functionality (much like the Java equivalent BTW) and the existing os >and os.path modules work just fine. Those who disagree with me haven't >done a very good job of convincing me, so I expect this PEP to remain >in limbo indefinitely, until it is eventually withdrawn or rejected. Personally I don't like the path module in question either, and I think that PEP 355 presents an exceptionally weak case, but I do believe that there are several serious use-cases for "object oriented" filesystem access. Twisted has a module for doing this: http://twistedmatrix.com/trac/browser/trunk/twisted/python/filepath.py I hope to one day propose this module as a replacement, or update, for PEP 355, but I have neither the time nor the motivation to do it currently. I wouldn't propose it now; it is, for example, mostly undocumented, missing some useful functionality, and has some weird warts (for example, the name of the path-as-string attribute is "path"). However, since it's come up I thought I'd share a few of the use-cases for the general feature, and the things that Twisted has done with it. 1: Testing. If you want to provide filesystem stubs to test code which interacts with the filesystem, it is fragile and extremely complex to temporarily replace the 'os' module; you have to provide a replacement which knows about all the hairy string manipulations one can perform on paths, and you'll almost always forget some weird platform feature. If you have an object with a narrow interface to duck-type instead; for example, a "walk" method which returns similar objects, or an "open" method which returns a file-like object, mocking the appropriate parts of it in a test is a lot easier. The proposed PEP 355 module can be used for this, but its interface is pretty wide and implicit (and portions of it are platform-specific), and because it is also a string you may still have to deal with platform-specific features in tests (or even mixed os.path manipulations, on the same object). This is especially helpful when writing tests for error conditions that are difficult to reproduce on an actual filesystem, such as a network filesystem becoming unavailable. 2: Fast failure, or for lack of a better phrase, "type correctness". PEP 355 gets close to this idea when it talks about datetimes and sockets not being strings. In many cases, code that manipulates filesystems is passing around 'str' or 'unicode' objects, and may be accidentally passed the contents of a file rather than its name, leading to a bizarre failure further down the line. FilePath fails immediately with an "unsupported operand types" TypeError in that case. It also provides nice, immediate feedback at the prompt that the object you're dealing with is supposed to be a filesystem path, with no confusion as to whether it represents a relative or absolute path, or a path relative to a particular directory. Again, the PEP 355 module's subclassing of strings creates problems, because you don't get an immediate and obvious exception if you try to interpolate it with a non-path-name string, it silently "succeeds". 3: Safety. Almost every web server ever written (yes, including twisted.web) has been bitten by the "/../../../" bug at least once. The default child(name) method of Twisted's file path class will only let you go "down" (to go "up" you have to call the parent() method), and will trap obscure platform features like the "NUL" and "CON" files on Windows so that you can't trick a program into manipulating something that isn't actually a file. You can take strings you've read from an untrusted source and pass them to FilePath.child and get something relatively safe out. PEP 355 doesn't mention this at all. 4: last, but certainly not least: filesystem polymorphism. For an example of what I mean, take a look at this in-development module: http://twistedmatrix.com/trac/browser/trunk/twisted/python/zippath.py It's currently far too informal, and incomplete, and there's no specified interface. However, this module shows that by being objects and not module-methods, FilePath objects can also provide a sort of virtual filesystem for Python programs. With FilePath plus ZipPath, You can write Python programs which can operate on a filesystem directory or a directory within a Zip archive, depending on what object they are passed. On a more subjective note, I've been gradually moving over personal utility scripts from os.path manipulations to twisted.python.filepath for years. I can't say that this will be everyone's experience, but in the same way that Python scripts avoid the class of errors present in most shell scripts (quoting), t.p.f scripts avoid the class of errors present in most Python scripts (off-by-one errors when looking at separators or e
Re: [Python-Dev] PEP 355 status
[EMAIL PROTECTED] wrote: > I hope that eventually Python will include some form of OO filesystem > access, but I am equally hopeful that the current PEP 355 path.py is not > it. +1 Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
