Mailman 3 September 2004 - Python-Dev

RE: [Python-Dev] A cute new way to get an infinite loop
by Batista, Facundo Sept. 23, 2004

Sept. 23, 2004

[Raymond Hettinger] #- In comparison, the classic form doesn't seem as magical: #- #- x = [1] #- for y in x: #- x.append(-y) #- The eternal inherent risk of modify the iterable being iterated. Who didn't ever fall in this? . Facundo

1 0

FW: [Python-Dev] Noam's open regex requests
by Raymond Hettinger Sept. 23, 2004

Sept. 23, 2004

Haven't heard a peep on this one. Is anyone going to be miffed if I accept Noam's requests? Raymond Hettinger -----Original Message----- From: python-dev-bounces+python=rcn.com(a)python.org [mailto:python-dev-bounces+python=rcn.com@python.org] On Behalf Of Raymond Hettinger Sent: Saturday, September 18, 2004 6:34 PM To: python-dev(a)python.org Cc: 'Noam Raphael' Subject: [Python-Dev] Noam's open regex requests [Noam Raphael] > I've suggested three things that I think should be done in that > case, and nobody objected. > > 1. Add a prominent note in the module contents page or in the module's > main page, stating that some functionality can only be acheived by using > compiled REs. I would make that read "The methods of compiled regular expressions allow more options than their simplified function counterparts. Most non-trivial applications always use the compiled form." > 2. Document the optional parameters which let you specify the start and > end pos in the findall and finditer methods of a compiled RE object. This seems reasonable to me. The API is already exposed and is useful. Why not document it. AFAICT, there are no plans to take away the functionality. > 3. Add the optional parameter "flags" to the findall and finditer > functions. Then, the four functions match, search, findall and finditer > would have the same interface: function(pattern, string[, flags]). This also seems reasonable to me. It is marginally useful and it may reduce the learning curve ever so slightly. There is nothing special about findall() and finditer() that makes them different from match() and search() with respect to flags. Raymond Hettinger _______________________________________________ Python-Dev mailing list Python-Dev(a)python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python%40rcn.com

3 3

Weekly Python Patch/Bug Summary
by Kurt B. Kaiser Sept. 22, 2004

Sept. 22, 2004

Patch / Bug Summary ___________________ Patches : 235 open ( -6) / 2633 closed (+11) / 2868 total ( +5) Bugs : 767 open ( +3) / 4463 closed (+10) / 5230 total (+13) RFE : 151 open ( +1) / 131 closed ( +0) / 282 total ( +1) New / Reopened Patches ______________________ (2004-09-18) CLOSED http://python.org/sf/1030422 opened by Jeff Connelly aka shellreef Patch for bug #780725 (2004-09-20) http://python.org/sf/1031213 opened by atsuo ishimoto Clean up discussion of new C thread idiom (2004-09-20) http://python.org/sf/1031233 opened by Greg Chapman atexit decorator (2004-09-21) http://python.org/sf/1031687 opened by Raymond Hettinger Add API to logging package to allow intercooperation. (2004-09-21) http://python.org/sf/1032206 opened by Dave Wilson Patches Closed ______________ Decimal performance enhancements (2004-09-01) http://python.org/sf/1020845 closed by rhettinger topdir calculated incorrectly in bdist_rpm (2004-09-03) http://python.org/sf/1022003 closed by jafo add support for the AutoReq flag in bdist_rpm (2004-09-03) http://python.org/sf/1022011 closed by jafo Adding IPv6 host handling to httplib (2004-09-15) http://python.org/sf/1028502 closed by loewis Add status code constants to httplib (2004-09-10) http://python.org/sf/1025790 closed by loewis tarfile.py longnames are truncated in getnames() (2004-09-16) http://python.org/sf/1029061 closed by loewis Patch for bug 933795. term.h and curses on Solaris (2004-08-19) http://python.org/sf/1012280 closed by loewis fix bug 807871 : tkMessageBox.askyesno wrong result (2004-08-29) http://python.org/sf/1018509 closed by loewis Error when int sent to PyLong_AsUnsignedLong (2004-09-08) http://python.org/sf/1024670 closed by loewis WinSock 2 support on Win32 w/ MSVC++ 6 (fix #860134) (2004-03-03) http://python.org/sf/908631 closed by loewis (2004-09-18) http://python.org/sf/1030422 closed by jeffconnelly New / Reopened Bugs ___________________ email.Utils not mentioned (2004-09-17) http://python.org/sf/1030118 opened by Jeff Blaine rfc822 __iter__ problem (2004-09-17) http://python.org/sf/1030125 opened by Mike Foord socket is not garbage-collected under specific circumstances (2004-09-18) CLOSED http://python.org/sf/1030249 opened by Matthias Klose distutils' dry-run wants to create some real build dirs (2004-09-18) http://python.org/sf/1030250 opened by Matthias Klose os.system exhausts file descriptors (2004-09-18) CLOSED http://python.org/sf/1030388 opened by Eray Ozkural os.path.join() does not raise TypeError (2004-09-18) http://python.org/sf/1030499 opened by Pierre Fortin PyMapping_Check crashes when argument is NULL (2004-09-19) CLOSED http://python.org/sf/1030557 opened by Michiel de Hoon PyOS_InputHook broken (2004-09-19) http://python.org/sf/1030629 opened by Michiel de Hoon Email message croaks the new email pkg parser (2004-09-19) http://python.org/sf/1030941 opened by Skip Montanaro tarfile: dirsize is not zero (2004-09-20) CLOSED http://python.org/sf/1031148 opened by Bertram Scharpf decimal module inconsistent with integers and floats (2004-09-20) CLOSED http://python.org/sf/1031480 opened by Anthony Tuininga Fold tuples of constants into a single constant (2004-09-20) http://python.org/sf/1031667 opened by Raymond Hettinger Conflicting descriptions of application order of decorators (2004-09-21) http://python.org/sf/1031897 opened by Hamish Lawson Bugs Closed ___________ help() does not check for chm file (2004-09-09) http://python.org/sf/1025392 closed by loewis socket is not garbage-collected under specific circumstances (2004-09-18) http://python.org/sf/1030249 closed by loewis configure not able to find ncurses/curses in Solaris (2004-04-12) http://python.org/sf/933795 closed by loewis tkMessageBox.askyesno wrong result (2003-09-17) http://python.org/sf/807871 closed by loewis Trivial fix for obscure bug in os.urandom() (2004-09-03) http://python.org/sf/1021596 closed by loewis os.system exhausts file descriptors (2004-09-18) http://python.org/sf/1030388 closed by loewis PyMapping_Check crashes when argument is NULL (2004-09-18) http://python.org/sf/1030557 closed by rhettinger tarfile: dirsize is not zero (2004-09-20) http://python.org/sf/1031148 closed by loewis decimal module inconsistent with integers and floats (2004-09-20) http://python.org/sf/1031480 closed by rhettinger get_installer_filename (2004-09-15) http://python.org/sf/1028334 closed by theller New / Reopened RFE __________________ Update unicodedata to version 4.0.1 (2004-09-20) http://python.org/sf/1031288 opened by Oliver Horn

1 0

[Patch 1032206] Add API to logging package to allow intercooperation.
by David Wilson Sept. 21, 2004

Sept. 21, 2004

Hi there, There are two alternative patches provided to add a single extra API item for this package, which would allow developers the ability to extend the logging package to a certain extent without clobbering each other's work. At present, it isn't possible for a package to customise the logging.Logger class, without running the risk of having it's changes clobbered by an application using the package, or another package. This small change allows each customiser to inherit changes from the last customiser. Any chance of getting one of these solutions in for 2.4? the "loggerClass" option provides more respectable declaration syntax, but the "getLoggerclass" option provides symmetry. http://sourceforge.net/tracker/index.php?func=detail&aid=1032206&group_id=5… Thanks, David. -- The next great adventure of mankind is not for people who ask, "What exactly is the point?" They will never get it. -- http://news.bbc.co.uk/1/hi/sci/tech/3302375.stm

1 0

Planning to drop gzip compression for future releases.
by Fred L. Drake, Jr. Sept. 21, 2004

Sept. 21, 2004

At this point, I'm planning to drop the gzip-compressed archives for all future Python releases. The bzip2 archives are much smaller (saving bandwidth, disk space, and download time), and supporting software seems to have become widely available in both free and commercial tools. I'm still planning to make ZIP archives available. If anyone would like to argue that I should drop that as well, feel free. ;-) -Fred -- Fred L. Drake, Jr. <fdrake at acm.org>

20 45

built on beer?
by Tommy Burnette Sept. 21, 2004

Sept. 21, 2004

hey team, in a completely un-python-related thread about mobile phones last week, a friend (who I did not know knew anything about python), when asked what made a certain nokia phone stand out above one from another company, replied: "... nokia runs python, the language built on beer." does the PSF have any t-shirts that advertise this fact? :)

4 4

Decimal, copyright and license
by Batista, Facundo Sept. 20, 2004

Sept. 20, 2004

People: I'm creating a decimal installer (for Py2.3 users), making tarball, .rpm and .exe versions available. What I don't know is what to put about license and copyright. Regarding copyright, my first draft says: Copyright (c) 2004 Python Software Foundation. All rights reserved. Regarding license, didn't put nothing yet, should I write something like the following and include the file? See the file "LICENSE" for information on the history of this software, terms & conditions for usage, and a DISCLAIMER OF ALL WARRANTIES. Remember that the "decimal installer" will be available for download not in a Python location. Thanks! Facundo Batista Desarrollo de Red fbatista(a)unifon.com.ar (54 11) 5130-4643 Cel: 15 5097 5024

4 3

Copyright and license texts for distributing Decimal
by Batista, Facundo Sept. 20, 2004

Sept. 20, 2004

I'll reformulate my question. I've got a proyect, SiGeFi, which needs the decimal module, so for being used with Py2.3 it's a must for the project to let the user to install the decimal module "easily". Also, Alex Martelli asked me to create a "decimal module" installer, for reasons related to a recipe for his new book. So I get into distutils and prepared tarball, .rpm and .exe packages for install the decimal module in your system if you have Py2.3. What I didn't solve is the license and copyright to put in the package. Regarding copyright, my first draft says: Copyright (c) 2004 Python Software Foundation. All rights reserved. Regarding license, didn't put nothing yet, should I write something like the following and include the file? See the file "LICENSE" for information on the history of this software, terms & conditions for usage, and a DISCLAIMER OF ALL WARRANTIES. What license should I include in the packages? And the copyright text? Thank you! Facundo Batista Desarrollo de Red fbatista(a)unifon.com.ar (54 11) 5130-4643 Cel: 15 5097 5024 -----Mensaje original----- De: Batista, Facundo Enviado el: Viernes, 17 de Septiembre de 2004 11:10 Para: Python Dev (E-mail) Asunto: [Python-Dev] Decimal, copyright and license People: I'm creating a decimal installer (for Py2.3 users), making tarball, .rpm and .exe versions available. What I don't know is what to put about license and copyright. Regarding copyright, my first draft says: Copyright (c) 2004 Python Software Foundation. All rights reserved. Regarding license, didn't put nothing yet, should I write something like the following and include the file? See the file "LICENSE" for information on the history of this software, terms & conditions for usage, and a DISCLAIMER OF ALL WARRANTIES. Remember that the "decimal installer" will be available for download not in a Python location. Thanks! Facundo Batista Desarrollo de Red fbatista(a)unifon.com.ar (54 11) 5130-4643 Cel: 15 5097 5024

1 0

[TARGETDIR]lib-tk added to PythonPath in MSI
by Trent Mick Sept. 19, 2004

Sept. 19, 2004

Round about line 1088 of Tools/msi/msi.py, lib-tk is added to the PythonPath: ("PythonPath", -1, prefix+r"\PythonPath", "", "[TARGETDIR]Lib;[TARGETDIR]DLLs;[TARGETDIR]lib-tk", "REGISTRY"), Shouldn't that be this instead? ("PythonPath", -1, prefix+r"\PythonPath", "", "[TARGETDIR]Lib;[TARGETDIR]DLLs;[TARGETDIR]Lib\\lib-tk", "REGISTRY"), Trent -- Trent Mick TrentM(a)ActiveState.com

2 1

Re: URL processing conformance and principles (was Re: urllib.urlopen...)
by "Martin v. Löwis" Sept. 19, 2004

Sept. 19, 2004

{I hit sent too early, here is the rest } Mike Brown wrote: > Right. This part of the thread was just about how the argument to > urllib.urlopen() should be handled when given as unicode vs str. You seemed to > be saying it should be str because a URI is fundamentally bytes and should be > analyzed as such, whereas I'm saying no, a URI is fundamentally characters and > should be analyzed as such. I mentioned %-encoding and the quirk of the BNF > just because those are aspects of the syntax that are byte-oriented and are the > source of much confusion, and because they may have influenced your assertion. > > Are we in agreement on these points? I think I have to answer "no". The % notation is not a quirk of the BNF. I.e. when the BNF states that an URI contains %AC (say), this does *not* mean that the actual URI in-memory-or-on-the-wire contains the byte \xAC. The spec actually says that the URI, in memory, on the wire, or on paper, actually contains the three character '%', 'A', and 'C'. So usage of that escape mechanism is *not* a result of the BNF notation; it is the inherent desire that URIs contain only characters in ASCII. URIs that contain non-ASCII characters have to escape them "somehow", typically using the % notation. > - A URL/URI consists of a finite sequence of Unicode characters; No. An URI contains of a finite sequence of characters. Whether they are Unicode or not is not specified. The assumption certainly is that if the characters are coded (i.e. assigned to numbers), those numbers don't have to match Unicode code points at all. An URI that consists of KOI-8R characters would very well be possible. > - urlopen(), and anything else that takes a URL/URI argument, > must accept both str and unicode; Certainly. > - If given unicode, each character in the string directly represents > a character in the URL/URI and needs no interpretation; No. Only ASCII characters in the string need no interpretation. For non-ASCII characters, urllib needs to assume some escaping mechanism. > - If given str, each byte in the string represents a character in > the URL/URI according to US-ASCII interpretation; Yes, if the bytes are meaningful in ASCII. > - Characters or bytes outside the ASCII range, and even certain > characters in the ASCII range, are not permitted in a URL/URI, > and thus the interpretation of a string containing them may > result in an exception or other unpredictable results. Yes. > - The urllib, urllib2, and urlparse modules currently do not > claim to conform to any particular standards governing the > interpretation of URLs; they merely acknowledge that some > standards may be applicable. However, the intent is to provide > standards-conformant behavior where possible, to the extent > that the module APIs overlap with functionality mandated by > current standards. Yes. For input that is out of scope of existing standards, backwards compatibility is desirable, unless there is a strong indication that Python should have raised an exception for this input all along. > When the relevant standards become obsolete due to publication > of updated standards (e.g. RFC 1630 -> 1738 -> 1808 -> 2396), > the implementations *may* be updated accordingly, and users > should expect behavior that conforms to either the current or > obsoleted standards. Which standards are applicable to a > particular implementation should be documented in the module > and in its functions & classes where necessary. Yes. > - urlopen() is documented as accepting a 'url' argument that is > the URL of 'a network object' that can be read; a file-like > object, based on either a local file or a socket, is normally > returned. This 'network object' may be a local file if the > 'file' scheme is used or if the URL's scheme component is omitted. Yes. > If RFC 1808 applies (the current implementation is based largely > on this spec, which did not clearly distinguish between a reference > and a URI), it is what is defined in the grammar as a URL, and > if it is relative (relativeURL in the grammar), it is considered > to be relative to a default base URL. This is troublesome. What is a meaningful base URL? This should be mentioned prominently. > - In urlopen() and the URLOpener classes it depends on, the default > base URI is the result of resolving the result of os.getcwd(), > converted to a URL by some undocumented means, against the base > 'file:///'. > > (I don't think this would require a change to the implementation, > but it is a principle that should be agreed upon and documented, > and perhaps the nuances of getcwd vs getcwdu should be addressed). Sounds good. > - The resolution of URIs having the 'file' scheme is undertaken on > the local filesystem according to conventions that should be, but > presently aren't, documented. A preferred mapping of filesystem > paths to URIs and back should be documented for each platform. Ok. > - In urlopen(), the processing of a 'url' argument that is > syntactically absolute may be nonconformant on platforms > that use ":" in their filesystem paths. On such platforms, if the > first ":" in what is syntactically an absolute URL/URI appears to > be intended for use other than as a scheme component delimiter, > the path will assumed to be relative. Furthermore, on Windows, > '\', which is not allowed in a URL, or its equivalent percent- > encoded sequence '%5C' (case-insensitive), will be interpreted as > a '/' in the URL. Ok. > (This mostly describes current behavior, assuming we can reach > agreement that the "C:" in the example above should be treated > no differently than "C|"). I have no problem with that. There are no one-letter URL schemata, are there? > I must attend to other things right now; will comment on the other issues > later. Take your time. This has been sitting around for many releases - one more or less doesn't matter much in the global flow of things :-) Regards, Martin

3 2