Re: [Python-Dev] Python Doc problems
Guido van Rossum wrote: > 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. :-) > The calming influence of c.l.py appears to have worked its magic on xah to the extent that his most recent post didn't contain any expletives. Maybe there's hope for him yet. 668-and-counting-ly y'rs - steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden ___ 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 wrote: > 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. > By these statistics I think the answer to the original question is clearly "no" in the general case. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden ___ 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] Tix not included in 2.5 for Windows
Christos Georgiou schrieb: > Does anyone know why this happens? I can't find any information pointing to > this being deliberate. It may well be that Tix wasn't included on Windows. I don't test Tix regularly, and nobody reported missing it during the beta test. Please submit a bug report to sf.net/projects/python. Notice that Python 2.5 ships with a different Tcl version than 2.4; using the 2.4 Tix binaries in 2.5 may cause crashes. Regards, Martin ___ 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)
Bob Ippolito schrieb: > 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). Right. Although I do wonder what kind of software people write to run into this problem. As Guido points out, the numbers must be the result from some computation, or created by an extension module by different means. If people have many *simultaneous* copies of 0.0, I would expect there is something else really wrong with the data structures or algorithms they use. Regards, Martin ___ 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)
Martin v. Löwis wrote:
> Bob Ippolito schrieb:
>> 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).
>
> Right. Although I do wonder what kind of software people write to run
> into this problem. As Guido points out, the numbers must be the result
> from some computation, or created by an extension module by different
> means. If people have many *simultaneous* copies of 0.0, I would expect
> there is something else really wrong with the data structures or
> algorithms they use.
I suspect the problem would typically stem from floating point values that are
read in from a human-readable file rather than being the result of a
'calculation' as such:
>>> float('1') is float('1')
False
>>> float('0') is float('0')
False
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
Re: [Python-Dev] Tix not included in 2.5 for Windows
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Please submit a bug report to sf.net/projects/python. Done: www.python.org/sf/1568240 ___ 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, a lot of extension code, like ours use PyFloat_FromDouble(foo); This can be from vectors and stuff. Very often these are values from a database. Integral float values are very common in such case and id didn't occur to me that they weren't being reused, at least for small values. Also, a lot of arithmetic involving floats is expected to end in integers, like computing some index from a float value. Integers get promoted to floats when touched by them, as you know. Anyway, I now precreate integral values from -10 to 10 with great effect. The cost is minimal, the benefit great. Cheers, Kristján -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of "Martin v. Löwis" Sent: 30. september 2006 08:48 To: Bob Ippolito Cc: [email protected] Subject: Re: [Python-Dev] Caching float(0.0) Bob Ippolito schrieb: > 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). Right. Although I do wonder what kind of software people write to run into this problem. As Guido points out, the numbers must be the result from some computation, or created by an extension module by different means. If people have many *simultaneous* copies of 0.0, I would expect there is something else really wrong with the data structures or algorithms they use. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/kristjan%40ccpgames.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] PEP 355 status
[EMAIL PROTECTED] writes: > 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. I think I agree with this too. For another source of ideas there is the 'py.path' bit of the py lib, which, um, doesn't seem to be documented terribly well, but allows access to remote svn repositories as well as local filesytems (at least). Cheers, mwh -- 3. Syntactic sugar causes cancer of the semicolon. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html ___ 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
OK. Pronouncement: PEP 355 is dead. The authors (or the PEP editor) can update the PEP. I'm looking forward to a new PEP. --Guido On 9/30/06, Michael Hudson <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] writes: > > > 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. > > I think I agree with this too. For another source of ideas there is > the 'py.path' bit of the py lib, which, um, doesn't seem to be > documented terribly well, but allows access to remote svn repositories > as well as local filesytems (at least). > > Cheers, > mwh > > -- > 3. Syntactic sugar causes cancer of the semicolon. > -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html > ___ > 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
[Python-Dev] PEP 351 - do while
Hi, Just an opinion, but many uses of the ‘while true loop’ are instances of a ‘do loop’. I appreciate the language layout question, so I’ll give you an alternative: do: while Cheers, Hans Polak. This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message. ___ 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 Coghlan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>I suspect the problem would typically stem from floating point values that
>are
>read in from a human-readable file rather than being the result of a
>'calculation' as such:
For such situations, one could create a translation dict for both common
float values and for non-numeric missing value indicators. For instance,
flotran = {'*': None, '1.0':1.0, '2.0':2.0, '4.0':4.0}
The details, of course, depend on the specific case.
tjr
___
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] Tix not included in 2.5 for Windows
Christos Georgiou wrote: > 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: Also note: the Os/X universal seems to include a Tix runtime for the non-Intel processor, but not for the Intel processor. This makes me think there is a build problem. -- Scott David Daniels [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
[Python-Dev] Possible semantic changes for PEP 352 in 2.6
I am working on PEP 352 stuff for 2.6 and there are two changes that I think should be made that are not explicitly laid out in the PEP.First, and most dramatic, involves what is legal to list in an 'except' clause. Right now you can listing *anything*. This means ``except 42`` is totally legal even though raising a number is not. Since I am deprecating catching string exceptions, I can go ahead and deprecate catching *any* object that is not a legitimate object to be raised. The second thing is changing PyErr_GivenExceptionMatches() to return 0 on false, 1 on true, and -1 on error. As of right now there is no defined error return value. While it could be suggested to check PyErr_Occurred() after every call, there is a way to have the return value reflect all possible so I think this changed should be made. Anybody have objections with any of the changes I am proposing?-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)
On 9/30/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> >I suspect the problem would typically stem from floating point values that
> >are
> >read in from a human-readable file rather than being the result of a
> >'calculation' as such:
>
> For such situations, one could create a translation dict for both common
> float values and for non-numeric missing value indicators. For instance,
> flotran = {'*': None, '1.0':1.0, '2.0':2.0, '4.0':4.0}
> The details, of course, depend on the specific case.
But of course you have to know that common float values are never
cached and that it may cause you problems. Some users may expect them
to be because common strings and integers are cached.
-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] PEP 355 status
Guido van Rossum wrote: > OK. Pronouncement: PEP 355 is dead. The authors (or the PEP editor) > can update the PEP. > > I'm looking forward to a new PEP. It would be terrific if you gave us some clue about what is wrong in PEP355, so that the next guy does not waste his time. For instance, I find PEP355 incredibly good for my own path manipulation (much cleaner and concise than the awful os.path+os+shutil+stat mix), and I have trouble understanding what is *so* wrong with it. You said "it's an amalgam of unrelated functionality", but you didn't say what exactly is "unrelated" for you. Giovanni Bajo ___ 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)
Steve> By these statistics I think the answer to the original question
Steve> is clearly "no" in the general case.
As someone else (Guido?) pointed out, the literal case isn't all that
interesting. I modified floatobject.c to track a few interesting
floating point values:
static unsigned int nfloats[5] = {
0, /* -1.0 */
0, /* 0.0 */
0, /* +1.0 */
0, /* everything else */
0, /* whole numbers from -10.0 ... 10.0 */
};
PyObject *
PyFloat_FromDouble(double fval)
{
register PyFloatObject *op;
if (free_list == NULL) {
if ((free_list = fill_free_list()) == NULL)
return NULL;
}
if (fval == 0.0) nfloats[1]++;
else if (fval == 1.0) nfloats[2]++;
else if (fval == -1.0) nfloats[0]++;
else nfloats[3]++;
if (fval >= -10.0 && fval <= 10.0 && (int)fval == fval) {
nfloats[4]++;
}
/* Inline PyObject_New */
op = free_list;
free_list = (PyFloatObject *)op->ob_type;
PyObject_INIT(op, &PyFloat_Type);
op->ob_fval = fval;
return (PyObject *) op;
}
static void
_count_float_allocations(void)
{
fprintf(stderr, "-1.0: %d\n", nfloats[0]);
fprintf(stderr, " 0.0: %d\n", nfloats[1]);
fprintf(stderr, "+1.0: %d\n", nfloats[2]);
fprintf(stderr, "rest: %d\n", nfloats[3]);
fprintf(stderr, "whole numbers -10.0 to 10.0: %d\n", nfloats[4]);
}
then called atexit(_count_float_allocations) in _PyFloat_Init and ran "make
test". The output was:
...
./python.exe -E -tt ../Lib/test/regrtest.py -l
...
-1.0: 29048
0.0: 524241
+1.0: 91561
rest: 1749807
whole numbers -10.0 to 10.0: 1151442
So for a largely non-floating point "application", a fair number of floats
are allocated, a bit over 25% of them are -1.0, 0.0 or +1.0, and nearly 50%
of them are whole numbers between -10.0 and 10.0, inclusive.
Seems like it at least deserves a serious look. It would be nice to have
the numeric crowd contribute to this subject as well.
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] Tix not included in 2.5 for Windows
On 9/30/06, Scott David Daniels <[EMAIL PROTECTED]> wrote: > Christos Georgiou wrote: > > 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: > > Also note: the Os/X universal seems to include a Tix runtime for the > non-Intel processor, but not for the Intel processor. This > makes me think there is a build problem. Are you sure about that? What file are you referring to specifically? -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] Tix not included in 2.5 for Windows
Bob Ippolito wrote:
> On 9/30/06, Scott David Daniels <[EMAIL PROTECTED]> wrote:
>> Christos Georgiou wrote:
>>> Does anyone know why this happens? I can't find any information pointing to
>>> this being deliberate.
>> Also note: the Os/X universal seems to include a Tix runtime for the
>> non-Intel processor, but not for the Intel processor. This
>> makes me think there is a build problem.
>
> Are you sure about that? What file are you referring to specifically?
OK, from the 2.5 universal: (hand-typed, I e-mail from another machine)
=== Using Idle ===
>>> import Tix
>>> Tix.Tk()
Traceback (most recent call last):
File "(pyshell#8)", line 1, in (module)
Tix.Tk()
File "/Library/Frameworks/Python.framework/Versions/2.5/
lib/python2.5/lib-tk/Tix.py", line 210 in __init__
self.tk.eval('package require Tix')
TclError: no suitable image found. Did find:
/Library/Tcl/Tix8.4/libTix8.4.dylib: mach-o, but wrong architecture.
=== From the command line ===
>>> import Tix
>>> Tix.Tk()
Traceback (most recent call last):
File "", line 1, in (module)
File "/Library/Frameworks/Python.framework/Versions/2.5/
lib/python2.5/lib-tk/Tix.py", line 210 in __init__
self.tk.eval('package require Tix')
_tkinter.TclError: no suitable image found. Did find:
/Library/Tcl/Tix8.4/libTix8.4.dylib: mach-o, but wrong architecture.
-- Scott David Daniels
[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] Tix not included in 2.5 for Windows
On 9/30/06, Scott David Daniels <[EMAIL PROTECTED]> wrote:
> Bob Ippolito wrote:
> > On 9/30/06, Scott David Daniels <[EMAIL PROTECTED]> wrote:
> >> Christos Georgiou wrote:
> >>> Does anyone know why this happens? I can't find any information pointing
> >>> to
> >>> this being deliberate.
> >> Also note: the Os/X universal seems to include a Tix runtime for the
> >> non-Intel processor, but not for the Intel processor. This
> >> makes me think there is a build problem.
> >
> > Are you sure about that? What file are you referring to specifically?
>
> OK, from the 2.5 universal: (hand-typed, I e-mail from another machine)
>
>
> === Using Idle ===
> >>> import Tix
> >>> Tix.Tk()
>
> Traceback (most recent call last):
>File "(pyshell#8)", line 1, in (module)
> Tix.Tk()
>File "/Library/Frameworks/Python.framework/Versions/2.5/
> lib/python2.5/lib-tk/Tix.py", line 210 in __init__
> self.tk.eval('package require Tix')
> TclError: no suitable image found. Did find:
> /Library/Tcl/Tix8.4/libTix8.4.dylib: mach-o, but wrong architecture.
>
> === From the command line ===
>
> >>> import Tix
> >>> Tix.Tk()
>
> Traceback (most recent call last):
>File "", line 1, in (module)
>File "/Library/Frameworks/Python.framework/Versions/2.5/
> lib/python2.5/lib-tk/Tix.py", line 210 in __init__
> self.tk.eval('package require Tix')
> _tkinter.TclError: no suitable image found. Did find:
> /Library/Tcl/Tix8.4/libTix8.4.dylib: mach-o, but wrong architecture.
Those files are not distributed with Python.
-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
[Python-Dev] Weekly Python Patch/Bug Summary
Patch / Bug Summary ___ Patches : 422 open ( +2) / 3415 closed ( +5) / 3837 total ( +7) Bugs: 933 open (+18) / 6212 closed (+26) / 7145 total (+44) RFE : 237 open ( +2) / 239 closed ( +1) / 476 total ( +3) New / Reopened Patches __ platform.py support for IronPython (2006-09-23) http://python.org/sf/1563842 opened by Anthony Baxter pybench support for IronPython (2006-09-23) http://python.org/sf/1563844 opened by Anthony Baxter Py_signal_pipe (2006-09-24) http://python.org/sf/1564547 opened by Gustavo J. A. M. Carneiro tarfile depends on undocumented behaviour (2006-09-25) http://python.org/sf/1564981 opened by Seo Sanghyeon use LSB version information to detect a platform (2006-09-25) http://python.org/sf/1565037 opened by Matthias Klose doc changes for SMTP_SSL (2006-09-28) http://python.org/sf/1567274 opened by Monty Taylor super() and instancemethod() shouldn't accept keyword args (2006-09-29) CLOSED http://python.org/sf/1567691 opened by ?iga Seilnacht Patches Closed __ Python 2.5 fails with -Wl,--as-needed in LDFLAGS (2006-09-21) http://python.org/sf/1562825 closed by masterdriverz super() and instancemethod() shouldn't accept keyword args (2006-09-29) http://python.org/sf/1567691 closed by gbrandl Enable SSL for smtplib (2005-09-05) http://python.org/sf/1282340 closed by gbrandl pyclbr reports different module for Class and Function (2006-09-18) http://python.org/sf/1560617 closed by gbrandl datetime's strftime limits strings to 127 chars (2006-09-12) http://python.org/sf/1557390 closed by gbrandl New / Reopened Bugs ___ Quitter object masked (2006-05-01) http://python.org/sf/1479785 reopened by kbk ,msi fails for AMD Turion 64 mobile (2006-09-21) CLOSED http://python.org/sf/1563185 opened by Andy Harrington temporary file(s) (2006-09-22) CLOSED http://python.org/sf/1563236 opened by Grzegorz Makarewicz http//... test file (2006-09-22) CLOSED http://python.org/sf/1563238 opened by Grzegorz Makarewicz python_d python (2006-09-22) http://python.org/sf/1563243 opened by Grzegorz Makarewicz IDLE doesn't load - apparently without firewall problems (2006-09-22) http://python.org/sf/1563630 opened by dani struct.unpack doens't support buffer protocol objects (2006-09-23) http://python.org/sf/1563759 reopened by loewis struct.unpack doens't support buffer protocol objects (2006-09-23) http://python.org/sf/1563759 opened by Adal Chiriliuc Build of Python 2.5 on AIX 5.3 with GCC Fails (2006-09-22) http://python.org/sf/1563807 opened by Daniel Clark Typo in whatsnew/pep-342.html (2006-09-23) CLOSED http://python.org/sf/1563963 opened by Xavier Bassery IDLE invokes completion even when running code (2006-09-23) http://python.org/sf/1563981 opened by Martin v. Löwis 2.6 changes stomp on 2.5 docs (2006-09-23) http://python.org/sf/1564039 opened by ggpauly Fails to install on Fedora Core 5 (2006-09-20) CLOSED http://python.org/sf/1562171 reopened by mnsummerfield BaseCookie does not support "$Port" (2006-09-24) http://python.org/sf/1564508 opened by Anders Aagaard Unicode comparison change in 2.4 vs. 2.5 (2006-09-24) CLOSED http://python.org/sf/1564763 opened by Joe Wreschnig update Lib/plat-linux2/IN.py (2006-09-25) http://python.org/sf/1565071 opened by Matthias Klose Misbehaviour in zipfile (2006-09-25) CLOSED http://python.org/sf/1565087 opened by Richard Philips make plistlib.py available in every install (2006-09-25) http://python.org/sf/1565129 opened by Matthias Klose os.stat() subsecond file mode time is incorrect on Windows (2006-09-25) http://python.org/sf/1565150 opened by Mike Glassford Repair or Change installation error (2006-09-26) http://python.org/sf/1565509 opened by Greg Hazel does not raise SystemError on too many nested blocks (2006-09-26) http://python.org/sf/1565514 opened by Greg Hazel gc allowing tracebacks to eat up memory (2006-09-26) http://python.org/sf/1565525 opened by Greg Hazel webbrowser on gnome runs wrong browser (2006-09-26) CLOSED http://python.org/sf/1565661 opened by kangabroo 'all' documentation missing online (2006-09-26) http://python.org/sf/1565797 opened by Alan sets missing from standard types list in ref (2006-09-26) http://python.org/sf/1565919 opened by Georg Brandl pyexpat produces fals parsing results in CharacterDataHandle (2006-09-26) CLOSED http://python.org/sf/1565967 opened by Michael Gebetsroither RE (regular expression) matching stuck in loop (2006-09-27) http://python.org/sf/1566086 opened by Fabien Devaux T_ULONG -> double rounding in PyMember_GetOne() (2006-09-27) http://python.org/sf/1566140 opened by P
Re: [Python-Dev] PEP 355 status
Giovanni Bajo wrote: > Guido van Rossum wrote: > >> OK. Pronouncement: PEP 355 is dead. The authors (or the PEP editor) >> can update the PEP. >> >> I'm looking forward to a new PEP. > > It would be terrific if you gave us some clue about what is wrong in PEP355, > so > that the next guy does not waste his time. For instance, I find PEP355 > incredibly good for my own path manipulation (much cleaner and concise than > the > awful os.path+os+shutil+stat mix), and I have trouble understanding what is > *so* wrong with it. > > You said "it's an amalgam of unrelated functionality", but you didn't say what > exactly is "unrelated" for you. Things the PEP 355 path object lumps together: - string manipulation operations - abstract path manipulation operations (work for non-existent filesystems) - read-only traversal of a concrete filesystem (dir, stat, glob, etc) - addition & removal of files/directories/links within a concrete filesystem Dumping all of these into a single class is certainly practical from a utility point of view, but it's about as far away from beautiful as you can get, which creates problems from a learnability point of view, and from a capability-based security point of view. PEP 355 itself splits the methods up into 11 distinct categories when listing the interface. At the very least, I would want to split the interface into separate abstract and concrete interfaces. The abstract object wouldn't care whether or not the path actually existed on the current filesystem (and hence could be relied on to never raise IOError), whereas the concrete object would include the many operations that might need to touch the real IO device. (the PEP has already made a step in the right direction here by removing the methods that accessed a file's contents, leaving that job to the file object where it belongs). There's a case to be made for the abstract object inheriting from str or unicode for compatiblity with existing code, but an alternative would be to enhance the standard library to better support the use of non-basestring objects to describe filesystem paths. A PEP should at least look into what would have to change at the Python API level and the C API level to go that route rather than the inheritance route. For the concrete interface, the behaviour is very dependent on whether the path refers to a file, directory or symlink on the current filesystem. For an OO filesystem interface, does it really make sense to leave them all lumped into the one class with a bunch of isdir() and islink() style methods? Or does it make more sense to have a method on the abstract object that will return the appropriate kind of filesystem info object? If the latter, then how would you deal with the issue of state coherency (i.e. it was a file when you last touched it on the filesystem, but someone else has since changed it to a link)? (that last question actually lends strong support to the idea of a *single* concrete interface that dynamically responds to changes in the underlying filesystem). Another key difference between the two is that the abstract objects would be hashable and serialisable, as their state is immutable and independent of the filesystem. For the concrete objects, the only immutable part of their state is the path name - the rest would reflect the state of the filesystem at the current point in time. 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
Re: [Python-Dev] PEP 351 - do while
Hans Polak wrote: > Hi, > > > > Just an opinion, but many uses of the ‘while true loop’ are instances of > a ‘do loop’. I appreciate the language layout question, so I’ll give you > an alternative: > > > > do: > > > > > > while > I believe you meant to write PEP 315 in the subject line :) To fully account for loop else clauses, this suggestion would probably need to be modified to look something like this: Basic while loop: while : else: Using break to avoid code duplication: while True: if not : break Current version of PEP 315: do: while : else: This suggestion: do: while else: I personally like that style, and if the compiler can dig through a function looking for yield statements to identify generators, it should be able to dig through a do-loop looking for the termination condition. As I recall, the main objection to this style was that it could hide the loop termination condition, but that isn't actually mentioned in the PEP (and in the typical do-while case, the loop condition will still be clearly visible at the end of the loop body). Regards, 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
Re: [Python-Dev] PEP 355 status
On Sun, 01 Oct 2006 13:56:53 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote: >Things the PEP 355 path object lumps together: > - string manipulation operations > - abstract path manipulation operations (work for non-existent filesystems) > - read-only traversal of a concrete filesystem (dir, stat, glob, etc) > - addition & removal of files/directories/links within a concrete filesystem > >Dumping all of these into a single class is certainly practical from a utility >point of view, but it's about as far away from beautiful as you can get, which >creates problems from a learnability point of view, and from a >capability-based security point of view. PEP 355 itself splits the methods up >into 11 distinct categories when listing the interface. > >At the very least, I would want to split the interface into separate abstract >and concrete interfaces. The abstract object wouldn't care whether or not the >path actually existed on the current filesystem (and hence could be relied on >to never raise IOError), whereas the concrete object would include the many >operations that might need to touch the real IO device. (the PEP has already >made a step in the right direction here by removing the methods that accessed >a file's contents, leaving that job to the file object where it belongs). > >There's a case to be made for the abstract object inheriting from str or >unicode for compatiblity with existing code, I think that compatibility can be achieved by having a "pathname" string attribute or similar to convert to a string when appropriate. It's not like datetime inherits from str to facilitate formatting or anything like that. >but an alternative would be to >enhance the standard library to better support the use of non-basestring >objects to describe filesystem paths. A PEP should at least look into what >would have to change at the Python API level and the C API level to go that >route rather than the inheritance route. In C, this is going to be really difficult. Existing C APIs want to use C functions to deal with pathnames, and many libraries are not going to support arbitrary VFS I/O operations. For some libraries, like GNOME or KDE, you'd have to use the appropriate VFS object for their platform. >For the concrete interface, the behaviour is very dependent on whether the >path refers to a file, directory or symlink on the current filesystem. For an >OO filesystem interface, does it really make sense to leave them all lumped >into the one class with a bunch of isdir() and islink() style methods? Or does >it make more sense to have a method on the abstract object that will return >the appropriate kind of filesystem info object? I don't think returning different types of objects makes sense. This sort of typing is inherently prone to race conditions. If you get a "DirectoryPath" object in Python, and then the underlying filesystem changes so that the name that used to be a directory is now a file (or a device, or UNIX socket, or whatever), how do you change the underlying type? >If the latter, then how would >you deal with the issue of state coherency (i.e. it was a file when you last >touched it on the filesystem, but someone else has since changed it to a >link)? (that last question actually lends strong support to the idea of a >*single* concrete interface that dynamically responds to changes in the >underlying filesystem). In non-filesystem cases, for example the "zip path" case, there are inherent failure modes that you can't really do anything about (what if the zip file is removed while you're in the middle of manipulating it?) but there are actual applications which depend on the precise atomic semantics and error conditions associated with moving, renaming, and deleting directories and files, at least on POSIX systems. The way Twisted does this is that FilePath objects explicitly cache the results of "stat" and then have an explicit "restat" method for resychronizing with the current state of the filesystem. None of their methods for *manipulating* the filesystem look at this state, since it is almost guaranteed to be out of date :). >Another key difference between the two is that the abstract objects would be >hashable and serialisable, as their state is immutable and independent of the >filesystem. For the concrete objects, the only immutable part of their state >is the path name - the rest would reflect the state of the filesystem at the >current point in time. It doesn't really make sense to separate these to me; whenever you're serializing or hashing that information, the "mutable" parts should just be discarded. ___ 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
