Mailman 3 April 2009 - Python-Dev

Re: [Python-Dev] [Python-ideas] Proposed addtion to urllib.parse in 3.1 (and urlparse in 2.7)
by Mart Sõmermaa April 20, 2009

April 20, 2009

The general consensus in python-ideas is that the following is needed, so I bring it to python-dev to final discussions before I file a feature request in bugs.python.org. Proposal: add add_query_params() for appending query parameters to an URL to urllib.parse and urlparse. Implementation: http://github.com/mrts/qparams/blob/83d1ec287ec10934b5e637455819cf796b1b421… free to fork and comment). Behaviour (longish, guided by "simple things are simiple, complex things possible"): In the … [View More]

10 29

Something like PEP-0304 - suppress *.pyc generation
by christian.doll＠basf.com April 20, 2009

April 20, 2009

Hello, im looking for something like PEP-0304 ( http://www.python.org/dev/peps/pep-0304/) I need something to suppress the generation of *.pyc files because i have very much different machines which call a python program at same time. the python program crashes at different places and on different machines - i think the problem are the *.pyc files of different machines which are generated at the same time. is pep-0304 implemented in a newer python version ( we use 2.4.4 ) or is there a … [View More]

3 2

#!/usr/bin/env python --> python3 where applicable
by Mitchell L Model April 18, 2009

April 18, 2009

Some library files, such as pdb.py, begin with #!/usr/bin/env python In various discussions regarding some issues I submitted I was told that the decision had been made to call Python 3.x release executables python3. (One of the conflicts I ran into when I made 'python' a link to python3.1 was that some tools used in making the HTML documentation haven't been upgraded to run with 3.) Shouldn't all library files that begin with the above line be changed so that they read 'python3' instead … [View More]

2 1

RELEASED Python 2.6.2
by Barry Warsaw April 17, 2009

April 17, 2009

On behalf of the Python community, I'm happy to announce the availability of Python 2.6.2. This is the latest production-ready version in the Python 2.6 series. Dozens of issues have been fixed since Python 2.6.1 was released back in December. Please see the NEWS file for all the gory details. http://www.python.org/download/releases/2.6.2/NEWS.txt For more information on Python 2.6 in general, please see http://docs.python.org/dev/whatsnew/2.6.html Source tarballs, … [View More]

6 12

Re: [Python-Dev] Issue5434: datetime.monthdelta
by Jess Austin April 17, 2009

April 17, 2009

Jon Ribbens <jon+python-dev(a)unequivocal.co.uk> wrote: > On Thu, Apr 16, 2009 at 12:10:36PM +0400, Oleg Broytmann wrote: >> > This patch adds a "monthdelta" class and a "monthmod" function to the >> > datetime module. The monthdelta class is much like the existing >> > timedelta class, except that it represents months offset from a date, >> > rather than an exact period offset from a date. >> >> I'd rather see the code … [View More]

10 12

Experimental and Test Tracker instances live
by Daniel (ajax) Diniz April 17, 2009

April 17, 2009

Hi, As discussed before, I have put two mock Python Tracker instances online. The Test[1] instance follows bugs.python.org code, so we can test bugfixes and procedures without breaking the real tracker. The Experimental[2] one, aka the cool instance, is where new features are showcased. Currently no emails are being sent and the dbs can be reset at any time. If you'd like to play as a registered user, please email me and I'll create a user (or activate the one you've started to register). So … [View More]

1 0

Summary of Python tracker Issues
by Python tracker April 17, 2009

April 17, 2009

ACTIVITY SUMMARY (04/10/09 - 04/17/09) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2222 open (+37) / 15383 closed (+12) / 17605 total (+49) Open issues with patches: 852 Average duration of open issues: 642 days. Median duration of open issues: 393 days. Open Issues Breakdown open 2168 (+37) pending 54 ( +0) Issues Created Or Reopened (50) … [View More]

1 0

Re: [Python-Dev] Python-Dev Digest, Vol 69, Issue 143
by Jess Austin April 17, 2009

April 17, 2009

Jared Grubb <jared.grubb(a)gmail.com> wrote: > On 16 Apr 2009, at 11:42, Paul Moore wrote: >> The key thing missing (I believe) from dateutil is any equivalent of >> monthmod. > > > I agree with that. It's well-defined and it makes a lot of sense. +1 > > But, I dont think monthdelta can be made to work... what should the > following be? >>> print(date(2008,1,30) + monthdelta(1)) 2008-02-29 >>> print(date(2008,1,30) + monthdelta(2)) 2008-… [View More]

7 7

Re: [Python-Dev] Issue5434: datetime.monthdelta
by Jess Austin April 17, 2009

April 17, 2009

Antoine Pitrou <solipsis(a)pitrou.net> wrote: > Jess Austin <jess.austin <at> gmail.com> writes: >> >> What other behavior options besides "last-valid-day-of-the-month" >> would you like to see? > > IMHO, the question is rather what the use case is for the behaviour you are > proposing. In which kind of situation is it acceptable to turn 31/2 silently > into 29/2? I have worked in utility/telecom billing, and needed to examine large numbers of … [View More]

2 1

Re: [Python-Dev] PEP 382: Namespace Packages
by P.J. Eby April 17, 2009

April 17, 2009

At 03:58 AM 4/17/2009 +0000, glyph(a)divmod.com wrote: >Just as a use-case: would the Java "com.*" namespace be an example >of a "pure package with no base"? i.e. lots of projects are in it, >but no project owns it? Er, I suppose. I was thinking more of the various 'com.foo' and 'org.bar' packages as being the pure namespaces in question. For Python, a "flat is better than nested" approach seems fine at the moment. >Just to clarify things on my end: "namespace package" to *… [View More]me* means >"package with modules provided from multiple distributions (the >distutils term)". The definition provided by the PEP, that a >package is spread over multiple directories on disk, seems like an >implementation detail. Agreed. >Entries on __path__ slow down import, so my understanding of the >platonic ideal of a system python installation is one which has a >single directory where all packages reside, and a set of metadata >off to the side explaining which files belong to which distributions >so they can be uninstalled by a package manager. True... except that part of the function of the PEP is to ensure that if you install those separately-distributed modules to the same directory, it still needs to work as a package and not have any inter-package file conflicts. >Of course, for a development installation, easy uninstallation and >quick swapping between different versions of relevant dependencies >is more important than good import performance. So in that case, >you would want to optimize differently by having all of your >distributions installed into separate directories, with a long >PYTHONPATH or lots of .pth files to point at them. > >And of course you may want a hybrid of the two. Yep. >So another clarification I'd like in the PEP is an explanation of >motivation. For example, it comes as a complete surprise to me that >the expectation of namespace packages was to provide only >single-source namespaces like zope.*, peak.*, twisted.*. As I >mentioned above, I implicitly thought this was more for com.*, >twisted.plugins.*. Well, aside from twisted.plugins, I wasn't aware of anybody in Python doing that... and as I described, I never really interpreted that through the lens of "namespace package" vs. "plugin finding". >Right now it just says that it's a package which resides in multiple >directories, and it's not made clear why that's a desirable feature. Good point; perhaps you can suggest some wording on these matters to Martin? >Okay. So what I'm hearing is that Twisted should happily continue >using our own wacky __path__-calculation logic for twisted.plugins, >but that *twisted* should be a namespace package so that our >separate distributions (TwistedCore, TwistedWeb, TwistedConch, et. >al.) can be installed into separate directories. Yes. Thanks for taking the time to participate in this and add another viewpoint to the mix, not to mention clarifying some areas where the PEP could be clearer. [View Less]

2 1