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 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
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
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 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
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
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
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,
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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,
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
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
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
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
[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
28 matches
Mail list logo
