Mailman 3 July 2010 - Python-Dev

Include datetime.py in stdlib or not?
by Alexander Belopolsky July 24, 2010

July 24, 2010

This idea has been discussed extensively in this and other forums and I believe it is time to make a decision. The proposal is to add pure python implementation of datetime module to stdlib. The current C implementation will transparently override pure python definitions in CPython. Other python implementations will have an option of supplying their own fast implementation. This approach has already been adopted by several modules including pickle, heapq and warnings. It has even been … [View More]suggested [1] that this is the direction in which the majority of CPython extension modules should be heading. This proposal has brought mostly positive feedback on the tracker [2] with only a few objections being raised. 1. Since this does not bring any new functionality and datetime module is not expected to evolve, there is no need for pure python version. 2. There are other areas of stdlib that can benefit more from pure python equivalents. 3. Reference implementations should be written by a senior CPython developer and not scraped from external projects like PyPy. Let me briefly address these objections: 1. Availability of pure python equivalents of standard library modules is very helpful for debugging python applications. This is particularly true when the stdlib module is designed to be extendable by and calls into user-supplied code. This is true in the case of datetime module which relies on 3rd-party or user-supplied code for any timezone support. The datetime module indeed saw very little development in the last 6 years. However this lack of development may itself be the result of pure python version not being available. For example, the idea to supply a concrete tzinfo object representing UTC has been brought up back in 2002. [3] An RFE [4] was created in the tracker in January, 2009 and took more than 1.5 years to implement. If you look at the history of issue5094, you will see that development slowed down considerably when C coding started. Note that for this particular feature, there was probably no need to have it implemented in C to begin with. (Most common operations involve datetime objects in the same timezone and those don't need to call timezone methods.) 2. Unlike other areas of stdlib, datetime module was originally prototyped in python and it turns out that it hardly changed between python 2.3 and 2.6 with a couple of features added in 2.7. A port to 3.x was uneventful as well. 3. The version of datetime.py [5] that I propose for inclusion is substantially the pure python prototype written by Tim Peters and others back in 2003. The PyPy changes are very few [6]. I believe the code is substantially ready for inclusion. There are a few items that need to be fixed related to how floating point arguments to timedelta are handled, as well as some clean-up of docstrings and error messages (both C and python implementations can see some improvement in this area). The biggest item in terms of development effort would be to refactor test_datetime to test both implementations. A simple solution [7] of importing test_datetime twice with and without _datetime will probably not be accepted because it is not compatible with alternative unittest runners. What do you think? Please reply here or add a comment at http://bugs.python.org/issue7989. [1] http://bugs.python.org/issue5094#msg106498 [2] http://bugs.python.org/issue7989 [3] http://www.zope.org/Members/fdrake/DateTimeWiki/SuggestedRequirements [4] http://bugs.python.org/issue5094 [5] http://svn.python.org/view/*checkout*/sandbox/branches/py3k-datetime/dateti… [6] http://bugs.python.org/file17701/datetime-sandbox-pypy.diff [7] http://bugs.python.org/file17848/issue7989.diff [View Less]

5 12

http://bugs.python.org/issue231540
by geremy condra July 24, 2010

July 24, 2010

On Fri, Jul 23, 2010 at 5:18 PM, Simon de Vlieger <simon(a)ikanobori.jp> wrote: > On 24 July 2010 01:39, Mark Lawrence <breamoreboy(a)yahoo.co.uk> wrote: >> On 24/07/2010 00:09, Paul Moore wrote: >>> >>> On 23 July 2010 23:26, Mark Lawrence<breamoreboy(a)yahoo.co.uk> wrote: >>>> >>>> Is there any money to pay for the forthcoming 10th birthday party for >>>> this >>>> issue? Is the OP still … [View More]alive? >>> >>> I'm not sure the sarcasm helps much. What do you suggest should be >>> done with the request? Nobody has provided a patch, so there's nothing >>> to commit. Closing it as "won't fix" seems unreasonable, as I imagine >>> that should a suitable patch be supplied, it would be accepted. >>> >>> There's no magical means by which such a patch would appear, though. >>> The OP clearly[1] is either not interested enough or doesn't have the >>> skills to provide a patch, and no-one else has stepped up to do so. >>> >>> Note that it's been classified as a feature request, not a bug. So >>> there's nothing wrong, as such, with it remaining unresolved. >>> >>> Paul. >>> >>> [1] I say "clearly" - it may be that he could provide a patch if >>> asked. Maybe it would be worth you contacting him to ask if the issue >>> is still a problem for him, and whether he can assist in resolving it. >> >> Paul, >> >> I'm on the verge of giving up my time because the whole system is a complete >> and utter waste of my time. I feel quite happy that in my brief tenure I've >> closed 46 issues, but there's so many more that could have been closed, but >> yet again you don't even get the courtesy of a response when there's more in >> the pipeline that could be closed. I'd quote the issue numbers here and >> now, but I'm just too flaming tired to do so, though a quick count indicates >> I've got 23 ongoing that I'm attempting to sort. >> >> As it happens, I have been having discussions offline in an attempt to shift >> the culture of Python development but I don't believe that anything will >> come out of it. Let's face it, development is much more interesting than >> bug fixes. And once again, if some stupid idiot volunteer bothers to put in >> a patch to the code and/or the unit test, and it sits and rots for five >> years, is that person likely to come back to Python? Strangely, some do. >> >> Sorry, I'm off to bed. >> >> Yours feeling most disillusioned with python-dev. >> >> Mark Lawrence. > > Mark, > > when I read your emails it seems to me as if you have the greatest > concern with improving Python, the language and improving the state of > the bug tracker. > > This is a great thing, people like you are much needed. However, I do > seem to notice you try to take a business-like approach here on this > mailinglist. Most people on python-dev are volunteers who (like you) > spend their free time helping and working on Python. > > People who work in their free time are less likely to feel obliged to > respond immediately to an issue. They are also less likely to keep > paying attention to the bugs they were assigned. > > I think a person like you is needed, someone who weeds through the > rotting bug reports (not the feature requests) and tries to follow up > on them. Is the issue persistent for the user, has it been fixed as > collateral on another fix, etcetera. > > However, I think you would get more done if you switched from a > business philosophy to accepting that most people here are volunteers, > don't try to pressure volunteers. Try to do the best *you* can within > the community and let that help the project further. > > Oh, and with business philosophy I mean: mails like the one you start > this thread with are interpreted by me as being very pushy, overly > sarcastic and if my project manager at the office sends me an email > like that I know I have to do it right now. I would dislike to be > spoken to like this in an voluntary environment. Do note that I do > understand where your feelings come from. > > Regards, > > Simon de Vlieger > > P.S. a feature day sounds like a great idea! I don't care if he yells and rants and raves, he's a volunteer too, he does a ton of work that nobody else has stepped up to do, and IMO we're very lucky to have him doing it. Geremy Condra [View Less]

1 0

Python 3 optimizations...
by stefan brunthaler July 23, 2010

July 23, 2010

Hello, during the last year, I have developed a couple of quickening-based optimizations for the Python 3.1 interpreter. As part of my PhD programme, I have published a first technique that combines quickening with inline caching at this year's ECOOP, and subsequently extended this technique to optimize several load instructions as well as eliminate redundant reference counting operations from instructions, which has been accepted for publication for an upcoming conference. I have a working … [View More]

9 18

Re: [Python-Dev] PEP 3148 ready for pronouncement [ACCEPTED]
by Jesse Noller July 23, 2010

July 23, 2010

On Sat, May 22, 2010 at 11:38 AM, Guido van Rossum <guido(a)python.org> wrote: [snip] > Great points Jesse! Since I really don't have the time or expertise to > make a judgment on this PEP, I hereby appoint you chair of the > approval process for this PEP. That basically means that when you > think it's ready to be approved, you say so, and it's a done deal. The > remaining feedback cycle is up to you now -- it sounds like you're > ready for closure, which sounds good to … [View More]

3 4

Summary of Python tracker Issues
by Python tracker July 23, 2010

July 23, 2010

ACTIVITY SUMMARY (2010-07-16 - 2010-07-23) 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. 2826 open (+62) / 18349 closed (+21) / 21175 total (+83) Open issues with patches: 1151 Average duration of open issues: 692 days. Median duration of open issues: 480 days. Open Issues Breakdown open 2780 (+60) languishing 16 ( +0) pending 29 ( +2) Issues Created Or … [View More]

1 0

PEP 382 progress: import hooks
by "Martin v. Löwis" July 23, 2010

July 23, 2010

At EuroPython, I sat down with Brett and we propose an approach how namespace packages get along with import hooks. I reshuffled the order in which things get done a little bit, and added a section that elaborates on the hooks. Basically, a finder will need to support a find_path method, return all .pth files, and a loader will need to support a load_module_with_path method, to initialize __path__. Please comment if you think that this needs further changes; I'll hope to start implementing it soon. Regards, Martin

4 3

PEP 360 has outdated contents
by Antoine Pitrou July 23, 2010

July 23, 2010

Hello all, PEP 360 - “Externally Maintained Packages” seems to have outdated contents. First of all, I don't think Optik and wsgiref are externally maintained anymore (both seem unmaintained by their original authors). Second, the version numbers mentioned there could be out of date too (especially for ElementTree whose stdlib copy has recently been bumped by Florent). Third, it seems json should be added to the list, despite the prominent warning at the beginning that: “No new modules are to … [View More]

2 1

Distutils reverted in py3k
by Tarek Ziadé July 23, 2010

July 23, 2010

Hello As decided during the summit, I've reverted Distutils in the py3k branch, to its release3.1-maint state. This was already done in 2.7. I will only work on bugfixes for now on for distutils. Everything new is done in distutils2. So if you have a feature request, use the distutils2 component in the tracker. Let me know if you have/see any problem this revert created. Regards Tarek -- Tarek Ziadé | http://ziade.org

2 5

Inline caching for method calls
by Stefan Behnel July 23, 2010

July 23, 2010

Hi, Stefan Brunthaler started a thread on python-dev about a couple of patches he has written for CPython as part of his PhD. It seems that he has implemented inline caching for CPython. http://comments.gmane.org/gmane.comp.python.devel/115362 http://en.wikipedia.org/wiki/Inline_caching Something like this might be interesting for Cython, too. He hasn't published the patches yet, but they might well be worth a look when he does. Stefan

1 1

Python signal processing question
by Scott McCarty July 23, 2010

July 23, 2010

All, I have searched everywhere (mostly the code and a little google) and I cannot understand where the SIGKILL signal gets checked when it is set as a handler. I have scoured the Modules/signalmodule.c only to find two instances of the RuntimeError exception, but I cannot understand how python knows when a handler is set for SIGKILL. I understand that this changed in 2.4 and I am not trying to change it, I just really want to understand where this happens. I used grep to find SIGKILL and … [View More]

18 34