Python-Dev February 2010

python-dev@python.org

105 participants
88 discussions

by Barry Warsaw

Hello everybody! I hope you all had as great a time at Pycon 2010 as I did. No time to begin recovering though, we're on to Python 2.6.5 rc 1, which I would like to release on Monday. We have one showstopper still open, and I'll try to respond to that asap. http://bugs.python.org/issue7250 If there is anything else that absolutely should go into 2.6.5, now's the time to let me know. If there are no patches ready to be reviewed and landed though, you're probably running out of time. I will be very conservative about landing patches after rc1. Cheers, -Barry

11 years

Add UTC to 2.7 (PyCon sprint idea)

by anatoly techtonik

Hello, So far, Python timezone handling is far from "pythonic". There is no function to get current UTC offset, intuitive API to get DST of current time zone and whenever it is active, no functions to work with internet timestamps (RFC 3339). In my case [1] it took about one month and five people to get the right solution for a valid RFC 3339 timestamp. One of the reasons I see is that date/time functions are implemented in C, they expose C API, and there are not many people who can help and patch them. I am sure many current Python users will appreciate UTC functions and improved date/time API more than any new language features. That's why I would like to propose this enhancements for a coding spring on forthcoming PyCon. I am located in Europe and can't attend PyCon, but I summarized date/time issues related to UTC below. More open UTC-related Python issues: http://bugs.python.org/issue1647654 No obvious and correct way to get the time zone offset http://bugs.python.org/issue1667546 Time zone-capable variant of time.localtime http://bugs.python.org/issue7662 time.utcoffset() http://bugs.python.org/issue7229 [PATCH] Manual entry for time.daylight can be misleading http://bugs.python.org/issue5094 datetime lacks concrete tzinfo impl. for UTC http://bugs.python.org/issue7584 datetime.rfcformat() for Date and Time on the Internet (support RFC 3339, ISO 8601 datetime format) http://bugs.python.org/issue665194 datetime-RFC2822 roundtripping http://bugs.python.org/issue6280 calendar.timegm() belongs in time module, next to time.gmtime() All solutions require C expertise. If it will be impossible to find experts able to modify current implementation, then perhaps it could be real to create Python stub for coding solution in Python later? FWIW, this proposal is from my other issue about problems with Python date/time in separate tracker on Google Code [2]. [1] http://bugs.python.org/issue7582 [patch] diff.py to use iso timestamp [2] http://code.google.com/p/rainforce/issues/detail?id=10 python: date/time is a mess -- anatoly t.

11 years

Pickling named tuples on IronPython

by Michael Foord

Hello Raymond, Named tuples have compatibility code to enable them to work on IronPython without frame support, but unfortunately this doesn't allow pickling / unpickling of named tuples. One fix is to manually set __module__ on the named tuples once created, but I wonder if it would be possible to change the API to better support this - perhaps a default __module__ or providing an optional argument to specify it at creation time? Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.

11 years

contributor to committer

by Florent Xicluna

Hello, I am a semi-regular contributor for Python: I have contributed many patches since end of last year, some of them were reviewed by Antoine. Lately, he suggested that I should apply for commit rights. Some of the accepted patches: - Fix refleaks in py3k branch (#5596) - Extend stringlib fastsearch for various methods of bytes, bytearray and unicode objects (#7462 and #7622) - Various documentation patches, including FAQ Recently, I worked with Ezio to fix some tests and to silence py3k warnings in the test suite (#7092). And I am in touch with Fredrik to release ElementTree 1.3 and port it to Python 2.7 (#6472). As a final note, I would like to highlight a small script in the same spirit as Pyflakes: pep8.py I've contributed few patches for the version 0.5, released a week ago: http://pypi.python.org/pypi/pep8/ -- Florent Xicluna

11 years

Re: [Python-Dev] __file__

by Barry Warsaw

On Feb 03, 2010, at 01:07 PM, Antoine Pitrou wrote: >Well, I don't think we need another transition... Just keep __file__ for the >source file, and add a __cache__ or __compiled__ attribute for the compiled >file(s). >Since there might be several compiled files for a single source file (for >example, a .pyc along with a JITted native .so), __cache__ should probably be >a tuple rather than a string. I'm going to call the attribute __cached__ and leave its contents implementation defined. For CPython it will be the path to the pyc file if it exists (or was written), or the path to where the pyc file /would/ exist if the source lives on a read-only file system or -B/$PYTHONDONTWRITEBYTECODE is set. For alternative implementations of Python that compose modules from multiple sources, __cached__ can be a tuple. -Barry

11 years

status of issue #7242

by Doug Hellmann

We've recently run into an issue with subprocess on Solaris, as described (by an earlier reporter) in issue #7242. The patch there solves our problem, and has been verified to work by other users as well. What's the status of the ticket? Is there anything I can do to help move it forward to be included in a patch release for 2.6? Thanks, Doug

11 years

Platform extension for distutils on other interpreters than CPython

by Maciej Fijalkowski

Hello. I would like to have a feature on platform module (or sys or somewhere) that can tell distutils or distutils2 that this platform (be it PyPy or Jython) is not able to compile any C module. The purpose of this is to make distutils bail out in more reasonable manner than a compilation error in case this module is not going to work on anything but CPython. What do you think? Cheers, fijal

11 years

Re: [Python-Dev] Mercurial repository for Python benchmarks

by Dave Fugate

Would there be any interest in accepting IronPython's in-house benchmarks into this repository as well? Internally we run the usual suspects (PyStone, PyBench, etc), but we also have a plethora of custom benchmarks we've written that also happen to run under CPython. My best, Dave ------------------------------ Message: 2 Date: Mon, 22 Feb 2010 15:17:09 -0500 From: Collin Winter <collinwinter(a)google.com> To: Daniel Stutzbach <daniel(a)stutzbachenterprises.com> Cc: Dirkjan Ochtman <djc.ochtman(a)gmail.com>, Python Dev <python-dev(a)python.org> Subject: Re: [Python-Dev] Mercurial repository for Python benchmarks Message-ID: <3c8293b61002221217v4b7f3b91y76b78763d69fb99d(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Sun, Feb 21, 2010 at 9:43 PM, Collin Winter <collinwinter(a)google.com> wrote: > Hey Daniel, > > On Sun, Feb 21, 2010 at 4:51 PM, Daniel Stutzbach > <daniel(a)stutzbachenterprises.com> wrote: >> On Sun, Feb 21, 2010 at 2:28 PM, Collin Winter <collinwinter(a)google.com> >> wrote: >>> >>> Would it be possible for us to get a Mercurial repository on >>> python.org for the Unladen Swallow benchmarks? Maciej and I would like >>> to move the benchmark suite out of Unladen Swallow and into >>> python.org, where all implementations can share it and contribute to >>> it. PyPy has been adding some benchmarks to their copy of the Unladen >>> benchmarks, and we'd like to have as well, and Mercurial seems to be >>> an ideal solution to this. >> >> If and when you have a benchmark repository set up, could you announce it >> via a reply to this thread?? I'd like to check it out. > > Will do. The benchmarks repository is now available at http://hg.python.org/benchmarks/. It contains all the benchmarks that the Unladen Swallow svn repository contains, including the beginnings of a README.txt that describes the available benchmarks and a quick-start guide for running perf.py (the main interface to the benchmarks). This will eventually contain all the information from http://code.google.com/p/unladen-swallow/wiki/Benchmarks, as well as guidelines on how to write good benchmarks. If you have svn commit access, you should be able to run `hg clone ssh://hg@hg.python.org/repos/benchmarks`. I'm not sure how to get read-only access; Dirkjan can comment on that. Still todo: - Replace the static snapshots of 2to3, Mercurial and other hg-based projects with clones of the respective repositories. - Fix the 2to3 and nbody benchmarks to work with Python 2.5 for Jython and PyPy. - Import some of the benchmarks PyPy has been using. Any access problems with the hg repo should be directed to Dirkjan. Thanks so much for getting the repo set up so fast! Thanks, Collin Winter

11 years

Add alternate float formatting styles to new-style formatting: allowed under moratorium?

by Eric Smith

http://bugs.python.org/issue7094 proposes adding "alternate" formatting [1] to floating point new-style formatting (float.__format__ and probably Decimal.__format__). I'd like to add this to make automated translation from %-formatting strings to str.format strings easier. Would this be allowed under the moratorium? I think it falls under the Case-by-Case Exemptions section, but let me know what you think. Eric. [1] Alternate formatting for floats modifies how trailing zeros and decimal points are treated. See http://docs.python.org/dev/library/stdtypes.html#string-formatting-operatio…

11 years

Using git to checkout Python

by Neil Schemenauer

For those interested, I updated my instructions for using the git repositories on svn.python.org. They are now on the Python wiki: http://wiki.python.org/moin/Git Regards, Neil

11 years

← Newer
1
2
3
4
5
6
7
8
9
Older →

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev February 2010