Re: [Python-Dev] Benchmarking Python 3.3 against Python 2.7 (wide build)
On Mon, Oct 1, 2012 at 2:35 PM, Steven D'Aprano wrote: > On Sun, Sep 30, 2012 at 07:12:47PM -0400, Brett Cannon wrote: > >> > python3 perf.py -T --basedir ../benchmarks -f -b py3k >> ../cpython/builds/2.7-wide/bin/python ../cpython/builds/3.3/bin/python3.3 > >> ### call_method ### >> Min: 0.491433 -> 0.414841: 1.18x faster >> Avg: 0.493640 -> 0.416564: 1.19x faster >> Significant (t=127.21) >> Stddev: 0.00170 -> 0.00162: 1.0513x smaller > > I'm not sure if this is the right place to discuss this, but what is the > justification for recording the average and std deviation of the > benchmarks? > > If the benchmarks are based on timeit, the timeit docs warn against > taking any statistic other than the minimum. Also because timeit is wrong to give that recommendation. There are factors - such as garbage collection - that affect operations on average, even though they may not kick in in every run. If you want to know how something will perform as part of a larger system, taking the best possible and extrapolating from it is a mistake. As a concrete example, consider an algorithm that generates cycles with several hundred MB of memory in them. Best case the RAM is available, nothing swaps, and gc doesn't kick in during the algorithm's execution. However, the larger program has to deal with those several hundred MB of memory sitting around until gc *does* kick in, has to pay the price of a gc run over a large heap, and deal with the impact on disk read cache. When you do enough runs to see those effects *that will affect the whole program* kick in, then you can extrapolate from that basis. e.g. the question timeit optimises itself to answer isn't the question most folk need most of the time. -Rob ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Benchmarking Python 3.3 against Python 2.7 (wide build)
On Sun, Sep 30, 2012 at 8:28 PM, Antoine Pitrou wrote: > On Sun, 30 Sep 2012 19:12:47 -0400 > Brett Cannon wrote: > > > > ### mako_v2 ### > > Min: 0.137584 -> 0.287701: 2.09x slower > > Avg: 0.140620 -> 0.293204: 2.09x slower > > Significant (t=-296.14) > > Stddev: 0.00243 -> 0.00272: 1.1195x larger > > Note that Mako can use the Markupsafe library for faster operation. > This will skew the result if one of your Pythons has Markupsafe > installed and the other does not. > Should probably have the benchmark print out a warning when markupsafe is used. Turns out I have it installed in my user directory for Python 2.7 so that probably came into play. > > Perhaps the benchmark runner should launch its subtests in a controlled > environment to avoid such issues? > If we had venv in Python 2.7 that might be easy to do, but otherwise is there an easy way without having to try to pull in virtualenv or something crazy like a chroot or something? -Brett (shipping a copy of Markupsafe would not be very practical, because it > has a C extension) > > Regards > > Antoine. > > > -- > Software development and contracting: http://pro.pitrou.net > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Benchmarking Python 3.3 against Python 2.7 (wide build)
On Sun, Sep 30, 2012 at 9:35 PM, Steven D'Aprano wrote: > On Sun, Sep 30, 2012 at 07:12:47PM -0400, Brett Cannon wrote: > > > > python3 perf.py -T --basedir ../benchmarks -f -b py3k > > ../cpython/builds/2.7-wide/bin/python ../cpython/builds/3.3/bin/python3.3 > > > ### call_method ### > > Min: 0.491433 -> 0.414841: 1.18x faster > > Avg: 0.493640 -> 0.416564: 1.19x faster > > Significant (t=127.21) > > Stddev: 0.00170 -> 0.00162: 1.0513x smaller > > I'm not sure if this is the right place to discuss this, The speed mailing list would be best. > but what is the > justification for recording the average and std deviation of the > benchmarks? > Because the tests, when run in a more rigorous fashion, run many more iterations so the average is used to even out bumps thanks to executing, e.g. 50 times. And the stddev is there to know how variable the results were in the end. > > If the benchmarks are based on timeit, the timeit docs warn against > taking any statistic other than the minimum. > They don't use timeit. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Benchmarking Python 3.3 against Python 2.7 (wide build)
On Sun, Sep 30, 2012 at 07:12:47PM -0400, Brett Cannon wrote: > > python3 perf.py -T --basedir ../benchmarks -f -b py3k > ../cpython/builds/2.7-wide/bin/python ../cpython/builds/3.3/bin/python3.3 > ### call_method ### > Min: 0.491433 -> 0.414841: 1.18x faster > Avg: 0.493640 -> 0.416564: 1.19x faster > Significant (t=127.21) > Stddev: 0.00170 -> 0.00162: 1.0513x smaller I'm not sure if this is the right place to discuss this, but what is the justification for recording the average and std deviation of the benchmarks? If the benchmarks are based on timeit, the timeit docs warn against taking any statistic other than the minimum. -- Steven ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Benchmarking Python 3.3 against Python 2.7 (wide build)
On Sun, Sep 30, 2012 at 8:14 PM, Gregory P. Smith wrote: > Interesting results! > > Another data point for the benchmarks that would be interesting is memory > consumption of the python process during the runs. > > In 3.3 a reasonable place to gather this would be to add a callback to the > new gc.callbacks and save a snapshot of the process's memory usage before > every collection to gather peak, average and median usage over the life of > the process. 2.7 doesn't have this feature but there is a backport of this > to 2.7 in the bugtracker. > > I guess I should join speed@ :) > > There is already support in perf.py to track memory: -m, --track_memoryTrack memory usage. This only works on Linux. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Benchmarking Python 3.3 against Python 2.7 (wide build)
On Sun, Sep 30, 2012 at 8:07 PM, Alexandre Vassalotti wrote: > > > On Sun, Sep 30, 2012 at 4:50 PM, Brett Cannon wrote: > >> I accidentally left out the telco benchmark, which is bad since cdecimal >> makes it just scream on Python 3.3 (and I verified with Python 3.2 that >> this is an actual speedup and not some silly screw-up like I initially had >> with spectral_norm): > > > You could also make the pickle benchmark use the C accelerator module by > passing the --use_cpickle flag. The Python 3 version should be a lot faster. > perf.py already uses --use_cpickle: Running fastpickle... INFO:root:Running ../cpython/builds/3.3/bin/python3.3 performance/bm_pickle.py -n 5 --use_cpickle pickle INFO:root:Running ../cpython/builds/2.7-wide/bin/python performance/bm_pickle.py -n 5 --use_cpickle pickle One thing that might make a change is using -1 for the protocol instead of 2, but that means losing the perk of perf.py doing all of the calculations, etc. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Benchmarking Python 3.3 against Python 2.7 (wide build)
On Sun, 30 Sep 2012 19:12:47 -0400 Brett Cannon wrote: > > ### mako_v2 ### > Min: 0.137584 -> 0.287701: 2.09x slower > Avg: 0.140620 -> 0.293204: 2.09x slower > Significant (t=-296.14) > Stddev: 0.00243 -> 0.00272: 1.1195x larger Note that Mako can use the Markupsafe library for faster operation. This will skew the result if one of your Pythons has Markupsafe installed and the other does not. Perhaps the benchmark runner should launch its subtests in a controlled environment to avoid such issues? (shipping a copy of Markupsafe would not be very practical, because it has a C extension) Regards Antoine. -- Software development and contracting: http://pro.pitrou.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Benchmarking Python 3.3 against Python 2.7 (wide build)
Interesting results! Another data point for the benchmarks that would be interesting is memory consumption of the python process during the runs. In 3.3 a reasonable place to gather this would be to add a callback to the new gc.callbacks and save a snapshot of the process's memory usage before every collection to gather peak, average and median usage over the life of the process. 2.7 doesn't have this feature but there is a backport of this to 2.7 in the bugtracker. I guess I should join speed@ :) -gps ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Benchmarking Python 3.3 against Python 2.7 (wide build)
On Sun, Sep 30, 2012 at 4:50 PM, Brett Cannon wrote: > I accidentally left out the telco benchmark, which is bad since cdecimal > makes it just scream on Python 3.3 (and I verified with Python 3.2 that > this is an actual speedup and not some silly screw-up like I initially had > with spectral_norm): You could also make the pickle benchmark use the C accelerator module by passing the --use_cpickle flag. The Python 3 version should be a lot faster. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Benchmarking Python 3.3 against Python 2.7 (wide build)
I accidentally left out the telco benchmark, which is bad since cdecimal makes it just scream on Python 3.3 (and I verified with Python 3.2 that this is an actual speedup and not some silly screw-up like I initially had with spectral_norm): ### telco ### Min: 0.897108 -> 0.016880: 53.15x faster Avg: 0.899742 -> 0.017443: 51.58x faster Significant (t=692.55) Stddev: 0.00283 -> 0.00032: 8.8470x smaller On Sun, Sep 30, 2012 at 7:12 PM, Brett Cannon wrote: > I am presenting the talk "Python 3.3: Trust Me, It's Better Than 2.7" as > PyCon Argentina and Brasil (and US if they accept the talk). As part of > that talk I need to be able to benchmark Python 3.3 against 2.7 (both from > tip) using the unladen benchmarks (which now include benchmarks from PyPy > that can be relatively easily ported to Python 3). > > To make sure the unladen benchmarks run fine against Python 3.3, I did a > fast run of the benchmarks. I figured people might be interested in the > quick-and-dirty results on my 2 GHz Intel Core i7 MacBook Pro w/ 8 GB RAM > and no attempt to control for performance beyond not actively browsing the > web. As I said, quick-and-dirty and not authoritative; all done just to > make sure all the benchmarks could run to completion (including the django, > html5lib, and genshi benchmarks which are only on my laptop ATM until those > projects cut a release with official Python 3 support). > > One thing to keep in mind is that many benchmarks use a raw str for > things, so the benchmarks often compare Python 2.7 str vs. Python 3.3 str > (i.e. str vs. unicode). While this might seem unfair, this is what > real-world comparisons in performance will be from users so it's an > (somewhat unfair) comparison that we just have to live with. I might take > the time to try to make some tests run under both raw strings and unicode > so both comparisons are available. > > If you care about helping out with the benchmarks (e.g. helping spot where > the iteration counts should be higher, etc.) then head over to the > speed@mailing list. > > > > > python3 perf.py -T --basedir ../benchmarks -f -b py3k > ../cpython/builds/2.7-wide/bin/python ../cpython/builds/3.3/bin/python3.3 > > ... output about the command line for the benchmarks ... > > ### 2to3 ### > 0.785234 -> 0.722169: 1.09x faster > > ### call_method ### > Min: 0.491433 -> 0.414841: 1.18x faster > Avg: 0.493640 -> 0.416564: 1.19x faster > Significant (t=127.21) > Stddev: 0.00170 -> 0.00162: 1.0513x smaller > > ### call_method_slots ### > Min: 0.492749 -> 0.416280: 1.18x faster > Avg: 0.497888 -> 0.419275: 1.19x faster > Significant (t=61.72) > Stddev: 0.00433 -> 0.00237: 1.8304x smaller > > ### call_method_unknown ### > Min: 0.575536 -> 0.427234: 1.35x faster > Avg: 0.577286 -> 0.433428: 1.33x faster > Significant (t=66.09) > Stddev: 0.00117 -> 0.00835: 7.1621x larger > > ### call_simple ### > Min: 0.413011 -> 0.338923: 1.22x faster > Avg: 0.415862 -> 0.340699: 1.22x faster > Significant (t=111.94) > Stddev: 0.00223 -> 0.00134: 1.6616x smaller > > ### chaos ### > Min: 0.375286 -> 0.435456: 1.16x slower > Avg: 0.382798 -> 0.459515: 1.20x slower > Significant (t=-5.01) > Stddev: 0.01116 -> 0.03234: 2.8980x larger > > ### fastpickle ### > Min: 0.853560 -> 0.770580: 1.11x faster > Avg: 0.879498 -> 0.776249: 1.13x faster > Significant (t=8.24) > Stddev: 0.02771 -> 0.00407: 6.7995x smaller > > ### float ### > Min: 0.476596 -> 0.391101: 1.22x faster > Avg: 0.486164 -> 0.411553: 1.18x faster > Significant (t=9.07) > Stddev: 0.01049 -> 0.01511: 1.4411x larger > > ### formatted_logging ### > Min: 0.346703 -> 0.451643: 1.30x slower > Avg: 0.351218 -> 0.454626: 1.29x slower > Significant (t=-51.50) > Stddev: 0.00376 -> 0.00246: 1.5265x smaller > > ### genshi ### > Min: 0.275107 -> 0.294309: 1.07x slower > Avg: 0.287433 -> 0.299026: 1.04x slower > Significant (t=-3.82) > Stddev: 0.01077 -> 0.00467: 2.3044x smaller > > ### go ### > Min: 0.719160 -> 0.781042: 1.09x slower > Avg: 0.729322 -> 0.798135: 1.09x slower > Significant (t=-8.54) > Stddev: 0.01300 -> 0.01248: 1.0415x smaller > > ### hexiom2 ### > 203.842661 -> 187.107363: 1.09x faster > > ### iterative_count ### > Min: 0.145088 -> 0.153285: 1.06x slower > Avg: 0.146369 -> 0.154425: 1.06x slower > Significant (t=-9.21) > Stddev: 0.00134 -> 0.00142: 1.0569x larger > > ### json_dump_v2 ### > Min: 3.512367 -> 4.040813: 1.15x slower > Avg: 3.521879 -> 4.057966: 1.15x slower > Significant (t=-64.29) > Stddev: 0.01071 -> 0.01526: 1.4247x larger > > ### json_load ### > Min: 1.024560 -> 0.642353: 1.60x faster > Avg: 1.025255 -> 0.644000: 1.59x faster > Significant (t=426.59) > Stddev: 0.00049 -> 0.00194: 3.9240x larger > > ### mako_v2 ### > Min: 0.137584 -> 0.287701: 2.09x slower > Avg: 0.140620 -> 0.293204: 2.09x slower > Significant (t=-296.14) > Stddev: 0.00243 -> 0.00272: 1.1195x larger > > ### meteor_contest ### > Min: 0.284739 -> 0.254285: 1.12x faster > Avg: 0.286174 -> 0.255323: 1.12x faster > Significant (t=38.02) > Stddev: 0
Re: [Python-Dev] Stdlib and timezones, again
Am 30.09.2012 20:18, schrieb Gregory P. Smith:
> We never hear anyone complain because the corrections are not for
> English or other "western" languages that the majority of us speak. ;)
>
> Regardless, I think including a version of the database on windows
> releases makes sense. Update it on a best effort basis before each .x
> minor release. The documentation can make it clear that it is a
> changing database how to use an updated version with your application.
>
> One additional thing I'd like to see: Don't let the successful importing
> of a 'pytzdata' module be the only way to get an updated tz database.
> Create an API for someone to supply one themselves at runtime that is
> cleaner than shoving something into sys.modules['pytzdata']. And define
> in which order they'll be used:
>
> priority:
> 1) api call supplying tz data to the process.
> 2) pytzdata module if it exists
> 3) tz data from the underlying operating system
> 4) error.
I like your basic approach but I'm suggesting a slightly different
approach. Before I explain my proposal I like to get a naming convention
straight.
integrated tz database
--
A copy of the Olson database that is shipped with every version of
Python (not just Windows). The integrated database is updated with every
feature release of Python.
system tz database
--
That's an interface to the operating system's or platform's tz database.
We probably have to provide multiple backends for different OSes, Java etc.
update tz database
--
A PyPI package that contains a current version of the Olson database. A
new version of the update tz should be provided by the Python core
developer team every time a new Olson database is available. The
updatetz must never be distributed with the Python source code and shall
not be installed by a distributor.
Optionally we can include the code that creates an update tz package
from a Olson database.
By default Python tries to load the updatetz first, then systemtz (if
available) and finally the integratedtz. A user can query the status and
version of the databases, set and get the currently used database with
three functions. The used database can also be set with an environment
variable:
datetime.gettzdatabase() -> "integrated" or "system" or "update"
datetime.settzdatabase(name)
datetime.listtzdatabases() ->
{"integrated": "version",
"system": "???"
"update": "version", # only if an update tz db is installed
}
PYTHON_TZDB = "integrated" or "system" or "update"
With this setup users get the full benefit of system updates but can use
the integrated or update database if they don't like the operating
system's data.
Christian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] benchmarks: Force map to a list to guarantee the calculations are performed under
On Sun, Sep 30, 2012 at 7:11 PM, Antoine Pitrou wrote: > On Mon, 1 Oct 2012 01:00:42 +0200 (CEST) > brett.cannon wrote: > > http://hg.python.org/benchmarks/rev/e9f911fd9bd3 > > changeset: 184:e9f911fd9bd3 > > user:Brett Cannon > > date:Sun Sep 30 19:00:32 2012 -0400 > > summary: > > Force map to a list to guarantee the calculations are performed under > > Python 3. > [...] > > def eval_times_u(func, u): > > -return map(func, ((i,u) for i in xrange(len(list(u) > > +return list(imap(func, ((i,u) for i in xrange(len(list(u)) > > Ugh, can't you use a list comprehension instead? The code would be much > more idiomatic. > Done. Just went with the fastest fix without thinking. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Benchmarking Python 3.3 against Python 2.7 (wide build)
I am presenting the talk "Python 3.3: Trust Me, It's Better Than 2.7" as PyCon Argentina and Brasil (and US if they accept the talk). As part of that talk I need to be able to benchmark Python 3.3 against 2.7 (both from tip) using the unladen benchmarks (which now include benchmarks from PyPy that can be relatively easily ported to Python 3). To make sure the unladen benchmarks run fine against Python 3.3, I did a fast run of the benchmarks. I figured people might be interested in the quick-and-dirty results on my 2 GHz Intel Core i7 MacBook Pro w/ 8 GB RAM and no attempt to control for performance beyond not actively browsing the web. As I said, quick-and-dirty and not authoritative; all done just to make sure all the benchmarks could run to completion (including the django, html5lib, and genshi benchmarks which are only on my laptop ATM until those projects cut a release with official Python 3 support). One thing to keep in mind is that many benchmarks use a raw str for things, so the benchmarks often compare Python 2.7 str vs. Python 3.3 str (i.e. str vs. unicode). While this might seem unfair, this is what real-world comparisons in performance will be from users so it's an (somewhat unfair) comparison that we just have to live with. I might take the time to try to make some tests run under both raw strings and unicode so both comparisons are available. If you care about helping out with the benchmarks (e.g. helping spot where the iteration counts should be higher, etc.) then head over to the speed@mailing list. > python3 perf.py -T --basedir ../benchmarks -f -b py3k ../cpython/builds/2.7-wide/bin/python ../cpython/builds/3.3/bin/python3.3 ... output about the command line for the benchmarks ... ### 2to3 ### 0.785234 -> 0.722169: 1.09x faster ### call_method ### Min: 0.491433 -> 0.414841: 1.18x faster Avg: 0.493640 -> 0.416564: 1.19x faster Significant (t=127.21) Stddev: 0.00170 -> 0.00162: 1.0513x smaller ### call_method_slots ### Min: 0.492749 -> 0.416280: 1.18x faster Avg: 0.497888 -> 0.419275: 1.19x faster Significant (t=61.72) Stddev: 0.00433 -> 0.00237: 1.8304x smaller ### call_method_unknown ### Min: 0.575536 -> 0.427234: 1.35x faster Avg: 0.577286 -> 0.433428: 1.33x faster Significant (t=66.09) Stddev: 0.00117 -> 0.00835: 7.1621x larger ### call_simple ### Min: 0.413011 -> 0.338923: 1.22x faster Avg: 0.415862 -> 0.340699: 1.22x faster Significant (t=111.94) Stddev: 0.00223 -> 0.00134: 1.6616x smaller ### chaos ### Min: 0.375286 -> 0.435456: 1.16x slower Avg: 0.382798 -> 0.459515: 1.20x slower Significant (t=-5.01) Stddev: 0.01116 -> 0.03234: 2.8980x larger ### fastpickle ### Min: 0.853560 -> 0.770580: 1.11x faster Avg: 0.879498 -> 0.776249: 1.13x faster Significant (t=8.24) Stddev: 0.02771 -> 0.00407: 6.7995x smaller ### float ### Min: 0.476596 -> 0.391101: 1.22x faster Avg: 0.486164 -> 0.411553: 1.18x faster Significant (t=9.07) Stddev: 0.01049 -> 0.01511: 1.4411x larger ### formatted_logging ### Min: 0.346703 -> 0.451643: 1.30x slower Avg: 0.351218 -> 0.454626: 1.29x slower Significant (t=-51.50) Stddev: 0.00376 -> 0.00246: 1.5265x smaller ### genshi ### Min: 0.275107 -> 0.294309: 1.07x slower Avg: 0.287433 -> 0.299026: 1.04x slower Significant (t=-3.82) Stddev: 0.01077 -> 0.00467: 2.3044x smaller ### go ### Min: 0.719160 -> 0.781042: 1.09x slower Avg: 0.729322 -> 0.798135: 1.09x slower Significant (t=-8.54) Stddev: 0.01300 -> 0.01248: 1.0415x smaller ### hexiom2 ### 203.842661 -> 187.107363: 1.09x faster ### iterative_count ### Min: 0.145088 -> 0.153285: 1.06x slower Avg: 0.146369 -> 0.154425: 1.06x slower Significant (t=-9.21) Stddev: 0.00134 -> 0.00142: 1.0569x larger ### json_dump_v2 ### Min: 3.512367 -> 4.040813: 1.15x slower Avg: 3.521879 -> 4.057966: 1.15x slower Significant (t=-64.29) Stddev: 0.01071 -> 0.01526: 1.4247x larger ### json_load ### Min: 1.024560 -> 0.642353: 1.60x faster Avg: 1.025255 -> 0.644000: 1.59x faster Significant (t=426.59) Stddev: 0.00049 -> 0.00194: 3.9240x larger ### mako_v2 ### Min: 0.137584 -> 0.287701: 2.09x slower Avg: 0.140620 -> 0.293204: 2.09x slower Significant (t=-296.14) Stddev: 0.00243 -> 0.00272: 1.1195x larger ### meteor_contest ### Min: 0.284739 -> 0.254285: 1.12x faster Avg: 0.286174 -> 0.255323: 1.12x faster Significant (t=38.02) Stddev: 0.00124 -> 0.00133: 1.0725x larger ### nbody ### Min: 0.491416 -> 0.336127: 1.46x faster Avg: 0.493339 -> 0.337467: 1.46x faster Significant (t=185.50) Stddev: 0.00164 -> 0.00092: 1.7927x smaller ### normal_startup ### Min: 0.639285 -> 0.898157: 1.40x slower Avg: 0.645513 -> 0.901586: 1.40x slower Significant (t=-90.10) Stddev: 0.00575 -> 0.00270: 2.1309x smaller ### nqueens ### Min: 0.399351 -> 0.429575: 1.08x slower Avg: 0.403643 -> 0.430284: 1.07x slower Significant (t=-9.83) Stddev: 0.00603 -> 0.00053: 11.3092x smaller ### pathlib ### Min: 0.137462 -> 0.170506: 1.24x slower Avg: 0.145370 -> 0.172849: 1.19x slower Significant (t=-11.09) Stddev: 0.01232 -> 0.00128: 9.6403x smaller
Re: [Python-Dev] Stdlib and timezones, again
On 01.10.2012 01:07, Chris Angelico wrote: > On Mon, Oct 1, 2012 at 8:17 AM, Matthias Klose wrote: >> On 30.09.2012 20:18, Gregory P. Smith wrote: >>> priority: >>> 1) api call supplying tz data to the process. >>> 2) pytzdata module if it exists >>> 3) tz data from the underlying operating system >>> 4) error. >> >> I disagree on this order, at least for Linux systems. the tzdata database is >> well managed on major Linux distributions and should be used for this reason. > > There's no guarantee that an individual sysadmin will have OS updates > up-to-date. If, on Linux, the pytzdata module is not installed unless > explicitly called for, that would define pytzdata as high specificity, > ergo it should override the lower specificity of the OS-provided data. > > The normal case on Linux will happily use the well-managed and > frequently-updated tzdata. I don't care as long as pytzdata is a third party module. I do care if it belongs to the standard library. I don't want to see a python and perl/java/foo application seeing different local times. Matthias ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] benchmarks: Force map to a list to guarantee the calculations are performed under
On Mon, 1 Oct 2012 01:00:42 +0200 (CEST) brett.cannon wrote: > http://hg.python.org/benchmarks/rev/e9f911fd9bd3 > changeset: 184:e9f911fd9bd3 > user:Brett Cannon > date:Sun Sep 30 19:00:32 2012 -0400 > summary: > Force map to a list to guarantee the calculations are performed under > Python 3. [...] > def eval_times_u(func, u): > -return map(func, ((i,u) for i in xrange(len(list(u) > +return list(imap(func, ((i,u) for i in xrange(len(list(u)) Ugh, can't you use a list comprehension instead? The code would be much more idiomatic. Regards Antoine. -- Software development and contracting: http://pro.pitrou.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stdlib and timezones, again
On Mon, Oct 1, 2012 at 8:17 AM, Matthias Klose wrote: > On 30.09.2012 20:18, Gregory P. Smith wrote: >> priority: >> 1) api call supplying tz data to the process. >> 2) pytzdata module if it exists >> 3) tz data from the underlying operating system >> 4) error. > > I disagree on this order, at least for Linux systems. the tzdata database is > well managed on major Linux distributions and should be used for this reason. There's no guarantee that an individual sysadmin will have OS updates up-to-date. If, on Linux, the pytzdata module is not installed unless explicitly called for, that would define pytzdata as high specificity, ergo it should override the lower specificity of the OS-provided data. The normal case on Linux will happily use the well-managed and frequently-updated tzdata. ChrisA ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stdlib and timezones, again
On 01.10.2012 00:51, Lennart Regebro wrote: > On Mon, Oct 1, 2012 at 12:17 AM, Matthias Klose wrote: > >>> priority: >>> 1) api call supplying tz data to the process. >>> 2) pytzdata module if it exists >>> 3) tz data from the underlying operating system >>> 4) error. >> >> I disagree on this order, at least for Linux systems. the tzdata database >> is >> well managed on major Linux distributions and should be used for this >> reason. >> > > Sure, but in the cases where it is not, overriding should be possible. The > OS tz data is last because it is the default. but not overriding with an outdated database. the new venv stuff makes the distinction to just use the core python environment, or use the core and site/dist-packages. I don't want to see an exception to not use something which is not in the core. Matthias ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stdlib and timezones, again
On 01.10.2012 00:50, Gregory P. Smith wrote: > On Sun, Sep 30, 2012 at 3:17 PM, Matthias Klose wrote: > >> On 30.09.2012 20:18, Gregory P. Smith wrote: >>> On Sun, Sep 30, 2012 at 8:33 AM, Benjamin Peterson >> wrote: >>> 2012/9/30 Xavier Morel : > But at worst, an outdated unicode database will be missing data right? > > Doesn't an outdated timezone db have the risk of returning *incorrect* data? Unicode updates also include corrections; however, it seems there are not significant enough or about obscure enough scripts that not many notice. :) >>> >>> We never hear anyone complain because the corrections are not for English >>> or other "western" languages that the majority of us speak. ;) >>> >>> Regardless, I think including a version of the database on windows >> releases >>> makes sense. Update it on a best effort basis before each .x minor >>> release. The documentation can make it clear that it is a changing >>> database how to use an updated version with your application. >>> >>> One additional thing I'd like to see: Don't let the successful importing >> of >>> a 'pytzdata' module be the only way to get an updated tz database. >> Create >>> an API for someone to supply one themselves at runtime that is cleaner >> than >>> shoving something into sys.modules['pytzdata']. And define in which >> order >>> they'll be used: >>> >>> priority: >>> 1) api call supplying tz data to the process. >>> 2) pytzdata module if it exists >>> 3) tz data from the underlying operating system >>> 4) error. >> >> I disagree on this order, at least for Linux systems. the tzdata database >> is >> well managed on major Linux distributions and should be used for this >> reason. >> > > Agreed, but that is why anyone writing code for Linux will simply never use > 1) or 2). Those exist primarily to handle the Windows and people with > software running on non well managed systems. > > I'd add a 3.5) to the above list: tz data bundled with the Python > distribution. Bundled tz data would likely simply not even be included in > a Python package on a Linux system. I would add - a 2.5) if pytzdata does exist and uses the tz data from the underlying operating system. - a 3.5) if pytzdata does exist and doesn't use the tz data from the underlying operating system. however I see our patch to pytzdata to use the os data is a local patch, and not found upstream. Matthias ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stdlib and timezones, again
On Mon, Oct 1, 2012 at 12:17 AM, Matthias Klose wrote: > > priority: > > 1) api call supplying tz data to the process. > > 2) pytzdata module if it exists > > 3) tz data from the underlying operating system > > 4) error. > > I disagree on this order, at least for Linux systems. the tzdata database > is > well managed on major Linux distributions and should be used for this > reason. > Sure, but in the cases where it is not, overriding should be possible. The OS tz data is last because it is the default. //Lennart ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stdlib and timezones, again
On Sun, Sep 30, 2012 at 3:17 PM, Matthias Klose wrote: > On 30.09.2012 20:18, Gregory P. Smith wrote: > > On Sun, Sep 30, 2012 at 8:33 AM, Benjamin Peterson >wrote: > > > >> 2012/9/30 Xavier Morel : > >>> But at worst, an outdated unicode database will be missing data right? > >>> > >>> Doesn't an outdated timezone db have the risk of returning *incorrect* > >> data? > >> > >> Unicode updates also include corrections; however, it seems there are > >> not significant enough or about obscure enough scripts that not many > >> notice. :) > >> > > > > We never hear anyone complain because the corrections are not for English > > or other "western" languages that the majority of us speak. ;) > > > > Regardless, I think including a version of the database on windows > releases > > makes sense. Update it on a best effort basis before each .x minor > > release. The documentation can make it clear that it is a changing > > database how to use an updated version with your application. > > > > One additional thing I'd like to see: Don't let the successful importing > of > > a 'pytzdata' module be the only way to get an updated tz database. > Create > > an API for someone to supply one themselves at runtime that is cleaner > than > > shoving something into sys.modules['pytzdata']. And define in which > order > > they'll be used: > > > > priority: > > 1) api call supplying tz data to the process. > > 2) pytzdata module if it exists > > 3) tz data from the underlying operating system > > 4) error. > > I disagree on this order, at least for Linux systems. the tzdata database > is > well managed on major Linux distributions and should be used for this > reason. > Agreed, but that is why anyone writing code for Linux will simply never use 1) or 2). Those exist primarily to handle the Windows and people with software running on non well managed systems. I'd add a 3.5) to the above list: tz data bundled with the Python distribution. Bundled tz data would likely simply not even be included in a Python package on a Linux system. -gps ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stdlib and timezones, again
On 30.09.2012 20:18, Gregory P. Smith wrote: > On Sun, Sep 30, 2012 at 8:33 AM, Benjamin Peterson wrote: > >> 2012/9/30 Xavier Morel : >>> But at worst, an outdated unicode database will be missing data right? >>> >>> Doesn't an outdated timezone db have the risk of returning *incorrect* >> data? >> >> Unicode updates also include corrections; however, it seems there are >> not significant enough or about obscure enough scripts that not many >> notice. :) >> > > We never hear anyone complain because the corrections are not for English > or other "western" languages that the majority of us speak. ;) > > Regardless, I think including a version of the database on windows releases > makes sense. Update it on a best effort basis before each .x minor > release. The documentation can make it clear that it is a changing > database how to use an updated version with your application. > > One additional thing I'd like to see: Don't let the successful importing of > a 'pytzdata' module be the only way to get an updated tz database. Create > an API for someone to supply one themselves at runtime that is cleaner than > shoving something into sys.modules['pytzdata']. And define in which order > they'll be used: > > priority: > 1) api call supplying tz data to the process. > 2) pytzdata module if it exists > 3) tz data from the underlying operating system > 4) error. I disagree on this order, at least for Linux systems. the tzdata database is well managed on major Linux distributions and should be used for this reason. Matthias ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Failed issue tracker submission
The node specified by the designator in the subject of your message
("16304") does not exist.
Subject was: "[issue16304]"
Mail Gateway Help
=
Incoming messages are examined for multiple parts:
. In a multipart/mixed message or part, each subpart is extracted and
examined. The text/plain subparts are assembled to form the textual
body of the message, to be stored in the file associated with a "msg"
class node. Any parts of other types are each stored in separate files
and given "file" class nodes that are linked to the "msg" node.
. In a multipart/alternative message or part, we look for a text/plain
subpart and ignore the other parts.
. A message/rfc822 is treated similar tomultipart/mixed (except for
special handling of the first text part) if unpack_rfc822 is set in
the mailgw config section.
Summary
---
The "summary" property on message nodes is taken from the first non-quoting
section in the message body. The message body is divided into sections by
blank lines. Sections where the second and all subsequent lines begin with
a ">" or "|" character are considered "quoting sections". The first line of
the first non-quoting section becomes the summary of the message.
Addresses
-
All of the addresses in the To: and Cc: headers of the incoming message are
looked up among the user nodes, and the corresponding users are placed in
the "recipients" property on the new "msg" node. The address in the From:
header similarly determines the "author" property of the new "msg"
node. The default handling for addresses that don't have corresponding
users is to create new users with no passwords and a username equal to the
address. (The web interface does not permit logins for users with no
passwords.) If we prefer to reject mail from outside sources, we can simply
register an auditor on the "user" class that prevents the creation of user
nodes with no passwords.
Actions
---
The subject line of the incoming message is examined to determine whether
the message is an attempt to create a new item or to discuss an existing
item. A designator enclosed in square brackets is sought as the first thing
on the subject line (after skipping any "Fwd:" or "Re:" prefixes).
If an item designator (class name and id number) is found there, the newly
created "msg" node is added to the "messages" property for that item, and
any new "file" nodes are added to the "files" property for the item.
If just an item class name is found there, we attempt to create a new item
of that class with its "messages" property initialized to contain the new
"msg" node and its "files" property initialized to contain any new "file"
nodes.
Triggers
Both cases may trigger detectors (in the first case we are calling the
set() method to add the message to the item's spool; in the second case we
are calling the create() method to create a new node). If an auditor raises
an exception, the original message is bounced back to the sender with the
explanatory message given in the exception.
Return-Path:
X-Original-To: rep...@bugs.python.org
Delivered-To: roundup+trac...@psf.upfronthosting.co.za
Received: from mail.python.org (mail.python.org [82.94.164.166])
by psf.upfronthosting.co.za (Postfix) with ESMTPS id C96C81CA8C
for ; Mon, 1 Oct 2012 00:05:31 +0200 (CEST)
Received: from albatross.python.org (localhost [127.0.0.1])
by mail.python.org (Postfix) with ESMTP id 3XVLKR40JNzNYF
for ; Mon, 1 Oct 2012 00:05:31 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901;
t=1349042731; bh=VvsXcY86pi/c+BeJIZc+70zwVxaiJ7YyKuEt7uYQ3Tc=;
h=MIME-Version:Content-Type:Content-Transfer-Encoding:From:To:
Subject:Message-Id:Date;
b=JIb9A8mKbs/8mEf6lMLk3yCyEqivXstaCqDmc1Bx/B8VveRxdmlBnXCIdktlJpDXA
e+ffB/whCObLiza0eN0IM8SVH012oUCUHsjGyE/9KMYXzgDLjqGhVQl65OD7lZ0did
Go+K7962YIYqsKcJFoEDsTBu0OKNroH9FqedZq1M=
Received: from localhost (HELO mail.python.org) (127.0.0.1)
by albatross.python.org with SMTP; 01 Oct 2012 00:05:31 +0200
Received: from virt-7yvsjn.psf.osuosl.org (virt-7yvsjn.psf.osuosl.org
[140.211.10.72])
by mail.python.org (Postfix) with ESMTP
for ; Mon, 1 Oct 2012 00:05:30 +0200 (CEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
From: python-dev@python.org
To: rep...@bugs.python.org
Subject: [issue16304]
Message-Id: <3xvlkr40jnz...@mail.python.org>
Date: Mon, 1 Oct 2012 00:05:31 +0200 (CEST)
TmV3IGNoYW5nZXNldCA0MjU4MjQ4YTQ0YzcgYnkgTmFkZWVtIFZhd2RhIGluIGJyYW5jaCAnMy4z
JzoKSXNzdWUgIzE2MzA0OiBGdXJ0aGVyIHBlcmZvcm1hbmNlIGltcHJvdmVtZW50cyBmb3IgQloy
RmlsZS4KaHR0cDovL2hnLnB5dGhvbi5vcmcvY3B5dGhvbi9yZXYvNDI1ODI0OGE0NGM3CgoKTmV3
IGNoYW5nZXNldCBhYmI1YzViZGU4NzIgYnkgTmFkZWVtIFZhd2RhIGluIGJyYW5jaCAnZGVmYXVs
dCc6Ck1lcmdlOiAjMTYzMDQ6IEZ1cnRoZXIgcGVyZm9ybWFuY2UgaW1wcm92ZW1lbnRzIGZvciBC
WjJGaWxlLgpodHRwOi8vaGcucHl0aG9uLm9yZy9jcHl0aG9uL3Jl
Re: [Python-Dev] Stdlib and timezones, again
On Mon, 01 Oct 2012 00:28:41 +0300 Serhiy Storchaka wrote: > On 30.09.12 22:51, Antoine Pitrou wrote: > > Well, no, this isn't similar. Choosing one's timezone policies is a > > contemporary political decision, while choosing a language and its > > alphabet is not really a decision people ever make (it's just an aspect > > of a society's long-term evolution) - except Atatürk, perhaps :-) > > Oh, no. Choosing of alphabet (and sometimes language) is also a > contemporary political decision. For the last 25 years new letter Ґ has > been added to the Ukrainian alphabet, and the letter Ь changed its place > in the alphabet. Well, yeah, but it's not like you can do it on a whim either, and you can't change the large body of existing text. > Who will update the database? The developer which distributes the > application with embedded Python can forget about the tz updates, as > well as about non-ascii encodings. Native Unicode support in Python > makes the second error less likely. > > Why not use the system data which are updated by the OS? I know that > Windows also changes the clock for local DST. If that's possible, then it sounds the ideal solution indeed. Regards Antoine. -- Software development and contracting: http://pro.pitrou.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stdlib and timezones, again
On Sun, Sep 30, 2012 at 11:28 PM, Serhiy Storchaka wrote: > Why not use the system data which are updated by the OS? I know that > Windows also changes the clock for local DST. > The Windows timezone information does not include any historical information, as it's designed primarily to keep your computers clock correctly, not to convert date times between different timezones. As a result using to to convert data in the past can give incorrect information. We therefore want to consistently use the tz database. //Lennart ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stdlib and timezones, again
On 30.09.12 22:51, Antoine Pitrou wrote: Well, no, this isn't similar. Choosing one's timezone policies is a contemporary political decision, while choosing a language and its alphabet is not really a decision people ever make (it's just an aspect of a society's long-term evolution) - except Atatürk, perhaps :-) Oh, no. Choosing of alphabet (and sometimes language) is also a contemporary political decision. For the last 25 years new letter Ґ has been added to the Ukrainian alphabet, and the letter Ь changed its place in the alphabet. There were at least 4 family of absolutely different character sets for Ukrainian (not counting the Unicode), some of them contains several incompatible variants. In several neighboring countries the alphabet was changed completely (from Cyrillic-based to Latin). Why ASCII is not enough for all? Furthermore, the proposal I'm making does *not* disadvantage residents of Russia and Ukraine: whether our Windows installer provides a database or not, they have to download a new database if they want up-to-date information. And they have to download it afresh every few months, if I'm following you. Who will update the database? The developer which distributes the application with embedded Python can forget about the tz updates, as well as about non-ascii encodings. Native Unicode support in Python makes the second error less likely. Why not use the system data which are updated by the OS? I know that Windows also changes the clock for local DST. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stdlib and timezones, again
On Sep 30, 2012 10:34 PM, "Guido van Rossum" wrote: >> >> When people use pytz they have to reinstall pytz too if thet want to benefit from the updates. (Or depend on automated updates via some vendor package management system.) If we can ensure that with pytz in the stdlib, updates to the Olson database can be installed just as easily as before (probably through some new custom mechanism, as a new Python bugfix release is too heavy-handed), I see no problem with adopting pytz into the stdlib. The mechanism would be exactly the same, but a different modulename. I´ll go forward and make a PEP on this soonish. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] experimental: Misc/NEWS included in docs
On Sun, 30 Sep 2012 12:14:37 -0700 Chris Jerdonek wrote: > On Sun, Sep 30, 2012 at 6:17 AM, Georg Brandl wrote: > > at http://docs.python.org/3.3/whatsnew/news.html, there is now > > a rendering of Misc/NEWS with tracker links and a crude filtering > > capability. I thought that this will complement the "whatsnew" > > documents nicely for people looking for more detail. > > > > Please let me know if it's useful, or what could be done to make > > it *more* useful. > > Good idea. Some suggestions: > > * A note at the top explaining what this page is and how it differs > from the other What's New page (including perhaps a link to the other > What's New page). It might also be good if the two had more > distinctive titles. They are currently "What’s New in Python" and > "Python News." Agreed. I think the titles are currently very confusing. The page you've just added should be called something like "Changelog", to stress its more bare'n'technical natural compared to our official "What's New" pages. Also it would be extra nice if the "What's new in Python X.Y" section headers could be renamed to "Python X.Y changelog", or similar. Regards Antoine. -- Software development and contracting: http://pro.pitrou.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stdlib and timezones, again
> > When people use pytz they have to reinstall pytz too if thet want to > benefit from the updates. (Or depend on automated updates via some vendor > package management system.) If we can ensure that with pytz in the stdlib, > updates to the Olson database can be installed just as easily as before > (probably through some new custom mechanism, as a new Python bugfix release > is too heavy-handed), I see no problem with adopting pytz into the stdlib. --Guido -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stdlib and timezones, again
On 30/09/2012 20:53, MRAB wrote: That's what UTC is for! :-) I think that it would be a good idea to provide a database with the release plus a tool for updating it, the updates being announced by email or RSS, and the ability to use the system's database if there's one. Very naive extremely simple approach reference it on pypi?!?! -- Cheers. Mark Lawrence. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] experimental: Misc/NEWS included in docs
On Sun, Sep 30, 2012 at 3:14 PM, Chris Jerdonek wrote: > On Sun, Sep 30, 2012 at 6:17 AM, Georg Brandl wrote: > > at http://docs.python.org/3.3/whatsnew/news.html, there is now > > a rendering of Misc/NEWS with tracker links and a crude filtering > > capability. I thought that this will complement the "whatsnew" > > documents nicely for people looking for more detail. > > > > Please let me know if it's useful, or what could be done to make > > it *more* useful. > > Good idea. Some suggestions: > > * A note at the top explaining what this page is and how it differs > from the other What's New page (including perhaps a link to the other > What's New page). It might also be good if the two had more > distinctive titles. They are currently "What’s New in Python" and > "Python News." > > * It would be good if the section links could somehow be > "perma-links." They will currently vary over time, e.g. > http://docs.python.org/py3k/whatsnew/news.html#id3 > > * Lastly, I think skimming this list would be more informative to me > at least if each bullet began with the name of the affected module or > area (at least in the case where just one module is affected). The > issue number is less meaningful as a descriptive header. Changing > this would likely require changes in how we prepare Misc/NEWS though. > > On a separate but related note, I never know where to put the various > subsections in relation to one another in Misc/NEWS (Core and > Builtins, Library, Extension Modules, etc). It would be good if there > was guidance on that -- even if to say it completely doesn't matter. > It doesn't matter. When I've done it I have either copied the empty sections previously or not even bothered with the empty sections and just let others add as necessary. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stdlib and timezones, again
On 2012-09-30 19:55, Serhiy Storchaka wrote: On 30.09.12 16:15, Antoine Pitrou wrote: Probably, but for most purposes I would guess a 2-year old database is still good enough? After all, you don't see many people complaining about the outdated Unicode database that is hard-wired in past Pythons. In 2011 Ukrainian timezone data was changed twice for year. And perhaps even change in 2013. Russian timezones were changed over the last few years and most likely will change in the near future. Correct time is critical for many applications. That's what UTC is for! :-) I think that it would be a good idea to provide a database with the release plus a tool for updating it, the updates being announced by email or RSS, and the ability to use the system's database if there's one. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stdlib and timezones, again
On Sun, 30 Sep 2012 22:35:54 +0300 Serhiy Storchaka wrote: > On 30.09.12 22:24, Antoine Pitrou wrote: > > Just because some governments have erratic policies shouldn't be a > > reason for residents of other countries not to enjoy the benefits of > > their stable timezones. > > This is similar to ascii-chauvinism. ;-) Well, no, this isn't similar. Choosing one's timezone policies is a contemporary political decision, while choosing a language and its alphabet is not really a decision people ever make (it's just an aspect of a society's long-term evolution) - except Atatürk, perhaps :-) Furthermore, the proposal I'm making does *not* disadvantage residents of Russia and Ukraine: whether our Windows installer provides a database or not, they have to download a new database if they want up-to-date information. And they have to download it afresh every few months, if I'm following you. Regards Antoine. -- Software development and contracting: http://pro.pitrou.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stdlib and timezones, again
On 30.09.12 22:24, Antoine Pitrou wrote: Just because some governments have erratic policies shouldn't be a reason for residents of other countries not to enjoy the benefits of their stable timezones. This is similar to ascii-chauvinism. ;-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stdlib and timezones, again
On Sun, 30 Sep 2012 21:55:34 +0300 Serhiy Storchaka wrote: > On 30.09.12 16:15, Antoine Pitrou wrote: > > Probably, but for most purposes I would guess a 2-year old database is > > still good enough? After all, you don't see many people complaining > > about the outdated Unicode database that is hard-wired in past Pythons. > > In 2011 Ukrainian timezone data was changed twice for year. And perhaps > even change in 2013. Russian timezones were changed over the last few > years and most likely will change in the near future. Correct time is > critical for many applications. Perhaps, but that's the responsibility of governements. Just because some governments have erratic policies shouldn't be a reason for residents of other countries not to enjoy the benefits of their stable timezones. Regards Antoine. -- Software development and contracting: http://pro.pitrou.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] experimental: Misc/NEWS included in docs
On Sun, Sep 30, 2012 at 6:17 AM, Georg Brandl wrote: > at http://docs.python.org/3.3/whatsnew/news.html, there is now > a rendering of Misc/NEWS with tracker links and a crude filtering > capability. I thought that this will complement the "whatsnew" > documents nicely for people looking for more detail. > > Please let me know if it's useful, or what could be done to make > it *more* useful. Good idea. Some suggestions: * A note at the top explaining what this page is and how it differs from the other What's New page (including perhaps a link to the other What's New page). It might also be good if the two had more distinctive titles. They are currently "What’s New in Python" and "Python News." * It would be good if the section links could somehow be "perma-links." They will currently vary over time, e.g. http://docs.python.org/py3k/whatsnew/news.html#id3 * Lastly, I think skimming this list would be more informative to me at least if each bullet began with the name of the affected module or area (at least in the case where just one module is affected). The issue number is less meaningful as a descriptive header. Changing this would likely require changes in how we prepare Misc/NEWS though. On a separate but related note, I never know where to put the various subsections in relation to one another in Misc/NEWS (Core and Builtins, Library, Extension Modules, etc). It would be good if there was guidance on that -- even if to say it completely doesn't matter. --Chris ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stdlib and timezones, again
On 30.09.12 16:15, Antoine Pitrou wrote: Probably, but for most purposes I would guess a 2-year old database is still good enough? After all, you don't see many people complaining about the outdated Unicode database that is hard-wired in past Pythons. In 2011 Ukrainian timezone data was changed twice for year. And perhaps even change in 2013. Russian timezones were changed over the last few years and most likely will change in the near future. Correct time is critical for many applications. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stdlib and timezones, again
On Sun, Sep 30, 2012 at 8:33 AM, Benjamin Peterson wrote: > 2012/9/30 Xavier Morel : > > But at worst, an outdated unicode database will be missing data right? > > > > Doesn't an outdated timezone db have the risk of returning *incorrect* > data? > > Unicode updates also include corrections; however, it seems there are > not significant enough or about obscure enough scripts that not many > notice. :) > We never hear anyone complain because the corrections are not for English or other "western" languages that the majority of us speak. ;) Regardless, I think including a version of the database on windows releases makes sense. Update it on a best effort basis before each .x minor release. The documentation can make it clear that it is a changing database how to use an updated version with your application. One additional thing I'd like to see: Don't let the successful importing of a 'pytzdata' module be the only way to get an updated tz database. Create an API for someone to supply one themselves at runtime that is cleaner than shoving something into sys.modules['pytzdata']. And define in which order they'll be used: priority: 1) api call supplying tz data to the process. 2) pytzdata module if it exists 3) tz data from the underlying operating system 4) error. -gps PS Unicode data is political as well, just less politically active than stupid time zones and "savings" times. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] experimental: Misc/NEWS included in docs
Georg Brandl wrote: > at http://docs.python.org/3.3/whatsnew/news.html, there is now > a rendering of Misc/NEWS with tracker links and a crude filtering > capability. I thought that this will complement the "whatsnew" > documents nicely for people looking for more detail. > > Please let me know if it's useful, or what could be done to make > it *more* useful. Maybe you could supress those sections that become empty when a filter is applied. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.3): Change libmpdec to use ANSI code in strict ansi mode as inline asm isn't
If anyone wants to force either an ANSI build or a specific libmpdec configuration, setup.py recognizes this environment variable (example): export PYTHON_DECIMAL_WITH_MACHINE=ansi64 The supported configurations listed here: http://hg.python.org/cpython/file/07d9d2901adb/Modules/_decimal/README.txt Stefan Krah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stdlib and timezones, again
2012/9/30 Xavier Morel : > But at worst, an outdated unicode database will be missing data right? > > Doesn't an outdated timezone db have the risk of returning *incorrect* data? Unicode updates also include corrections; however, it seems there are not significant enough or about obscure enough scripts that not many notice. :) -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.3): Change libmpdec to use ANSI code in strict ansi mode as inline asm isn't
christian.heimes wrote: > +/* ASM isn't available in strict ansi C mode */ > +#if defined(ASM) && defined(__STRICT_ANSI__) > + #undef ASM > + #define ANSI > +#endif I'm not too fond of this solution: the libmpdec build output should always be accurate. Now you have ... -ansi -DCONFIG_64=1 -DASM=1 ... but the build is silently non-asm. Like for pymath.c, __asm__ is tested for and selected in ./configure. So I'll replace asm with __asm__, same as in pymath.c and ceval.c. Stefan Krah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stdlib and timezones, again
On Sun, 30 Sep 2012 15:30:04 +0200, Xavier Morel wrote: > On 2012-09-30, at 15:15 , Antoine Pitrou wrote: > > > On Sun, 30 Sep 2012 15:10:06 +0200 > > Dirkjan Ochtman wrote: > >> On Sun, Sep 30, 2012 at 3:03 PM, Antoine Pitrou > >> wrote: > >>> Can't we simply include the Olson database in Windows installers? > >> > >> We probably can, but the problem is that it's updated quite often (for > >> example, in 2011, there were about 14 releases; in 2009, there were > >> 21). So you'd want to have a mechanism to override the data that is > >> included in the stdlib. > > > > Probably, but for most purposes I would guess a 2-year old database is > > still good enough? After all, you don't see many people complaining > > about the outdated Unicode database that is hard-wired in past Pythons. > > But at worst, an outdated unicode database will be missing data right? > > Doesn't an outdated timezone db have the risk of returning *incorrect* data? Yes. And the timezeone database is much more volatile than the unicode database. The changes are, after all, driven almost entirely by politics. --David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] buildbot with -O
Just as an FYI, we set up a new "optimized" Snakebite slave yesterday on the Mac OS X Mountain Lion box. I also set up remote access to that box in the process -- you can connect to it via the ~/.snakebite/sb 'x8' alias. (That box happens to be the fastest (and most contemporary) Snakebite machine; Mac Pro circa late 2009, dual quad core 3.2GHz Xenons (12MB L2 cache on each CPU!), 32GB RAM. See, it's not just a network of old esoteric junk, honest ;-).) Regards, Trent. On Wed, Sep 26, 2012 at 04:00:53PM -0700, Benjamin Peterson wrote: > In light of issue #16046, I think it would be helpful to have a > buildbot running the testsuite with -O enabled. > > -- > Regards, > Benjamin > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/trent%40snakebite.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stdlib and timezones, again
On 2012-09-30, at 15:15 , Antoine Pitrou wrote: > On Sun, 30 Sep 2012 15:10:06 +0200 > Dirkjan Ochtman wrote: >> On Sun, Sep 30, 2012 at 3:03 PM, Antoine Pitrou wrote: >>> Can't we simply include the Olson database in Windows installers? >> >> We probably can, but the problem is that it's updated quite often (for >> example, in 2011, there were about 14 releases; in 2009, there were >> 21). So you'd want to have a mechanism to override the data that is >> included in the stdlib. > > Probably, but for most purposes I would guess a 2-year old database is > still good enough? After all, you don't see many people complaining > about the outdated Unicode database that is hard-wired in past Pythons. But at worst, an outdated unicode database will be missing data right? Doesn't an outdated timezone db have the risk of returning *incorrect* data? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stdlib and timezones, again
On Sun, Sep 30, 2012 at 11:15 PM, Antoine Pitrou wrote: > On Sun, 30 Sep 2012 15:10:06 +0200 > Dirkjan Ochtman wrote: >> On Sun, Sep 30, 2012 at 3:03 PM, Antoine Pitrou wrote: >> > Can't we simply include the Olson database in Windows installers? >> >> We probably can, but the problem is that it's updated quite often (for >> example, in 2011, there were about 14 releases; in 2009, there were >> 21). So you'd want to have a mechanism to override the data that is >> included in the stdlib. > > Probably, but for most purposes I would guess a 2-year old database is > still good enough? After all, you don't see many people complaining > about the outdated Unicode database that is hard-wired in past Pythons. An out-of-date timezone database will bite someone at some point. They'll be running code that expects some locality to be on/off DST when it isn't, and some customer will be confused or annoyed. I suspect most people won't much care, though. It's only a few who'd explicitly upgrade their tz database. ChrisA ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 3.3.0
On 09/29/2012 06:53 PM, Antoine Pitrou wrote: Hello, I've created a 3.3 category on the buildbots: http://buildbot.python.org/3.3/ http://buildbot.python.org/3.3.stable/ Someone will have to update the following HTML page: http://python.org/dev/buildbot/ Should be done now. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Bug Day in October
On 9/27/2012 6:30 PM, Éric Araujo wrote: Hi all, The Montreal-Python user group would like to host a bug day on October 27 (to be confirmed) at a partner university in Montreal. It would be cool to do a bug day on IRC like we used to (and in other physical locations if people want to!) to get new contributors and close bugs. What do you think? Boston Python might get a physical location and join in. Keep us posted! --Ned. Cheers ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ned%40nedbatchelder.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] experimental: Misc/NEWS included in docs
Hi, at http://docs.python.org/3.3/whatsnew/news.html, there is now a rendering of Misc/NEWS with tracker links and a crude filtering capability. I thought that this will complement the "whatsnew" documents nicely for people looking for more detail. Please let me know if it's useful, or what could be done to make it *more* useful. cheers, Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stdlib and timezones, again
On Sun, 30 Sep 2012 15:10:06 +0200 Dirkjan Ochtman wrote: > On Sun, Sep 30, 2012 at 3:03 PM, Antoine Pitrou wrote: > > Can't we simply include the Olson database in Windows installers? > > We probably can, but the problem is that it's updated quite often (for > example, in 2011, there were about 14 releases; in 2009, there were > 21). So you'd want to have a mechanism to override the data that is > included in the stdlib. Probably, but for most purposes I would guess a 2-year old database is still good enough? After all, you don't see many people complaining about the outdated Unicode database that is hard-wired in past Pythons. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stdlib and timezones, again
On Sun, Sep 30, 2012 at 3:03 PM, Antoine Pitrou wrote: > Can't we simply include the Olson database in Windows installers? We probably can, but the problem is that it's updated quite often (for example, in 2011, there were about 14 releases; in 2009, there were 21). So you'd want to have a mechanism to override the data that is included in the stdlib. Cheers, Dirkjan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] what´s new 3.3
On Sun, 30 Sep 2012 10:55:54 + Kristján Valur Jónsson wrote: > Hi there. > > Not having kept up, I realized I failed to contribute to the What's new > thingie. [...] > DiSome of this should probably be mentioned in the What's new document, even > if only in its online version. Well, it's not too late for you to fix that oversight. Regards Antoine. -- Software development and contracting: http://pro.pitrou.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stdlib and timezones, again
On Sun, 30 Sep 2012 14:47:28 +0200 Lennart Regebro wrote: > With 3.3 out, it's time to bring up something for 3.4. And it's about pytz > and stdlib, basically. And we have been over that again, but I have a > proposal anyway. > > The problem with including pytz in the stdlib is that it contains the > tz/zoneinfo/Olson database, and it updates much more often than Python > does. I propose to solve this problem in the following way: > > 1. Merge the functionality of pytz into the stdlib datetime module. That > means extending datetime.tzinfo with the localize() function and and adding > a top-level datetime.timezone() function. any other extra functionality > pytz has. > > 2. The datetime.timezone() function will work as the pytz.timezone() > function, ie return a tzinfo object from the tz database. > > 3. However, Python will not include the database. Instead it will use the > one that the OS provides, if it provides one (ie Unices, including OS X if > I remember correctly). > > 4. On any other OS, datetime.timezone() will return an error explaining > that no tz database can be found, but that it is available in the module > 'pytzdata' which then will need to be created. If this module is installed, > the datetime.timezone() function will prefer that database before the OS > database. Can't we simply include the Olson database in Windows installers? Regards Antoine. -- Software development and contracting: http://pro.pitrou.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stdlib and timezones, again
Am 30.09.2012 14:47, schrieb Lennart Regebro: > What do you say? Is this a path worth pursuing? +1 I'm eager to read your PEP! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Stdlib and timezones, again
On Sun, Sep 30, 2012 at 2:47 PM, Lennart Regebro wrote: > What do you say? Is this a path worth pursuing? +1. It's the kind of low-level thing that should be solved in the stdlib as far as possible, and the pytz interface is as stable as the stdlib's. Cheers, Dirkjan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Stdlib and timezones, again
With 3.3 out, it's time to bring up something for 3.4. And it's about pytz and stdlib, basically. And we have been over that again, but I have a proposal anyway. The problem with including pytz in the stdlib is that it contains the tz/zoneinfo/Olson database, and it updates much more often than Python does. I propose to solve this problem in the following way: 1. Merge the functionality of pytz into the stdlib datetime module. That means extending datetime.tzinfo with the localize() function and and adding a top-level datetime.timezone() function. any other extra functionality pytz has. 2. The datetime.timezone() function will work as the pytz.timezone() function, ie return a tzinfo object from the tz database. 3. However, Python will not include the database. Instead it will use the one that the OS provides, if it provides one (ie Unices, including OS X if I remember correctly). 4. On any other OS, datetime.timezone() will return an error explaining that no tz database can be found, but that it is available in the module 'pytzdata' which then will need to be created. If this module is installed, the datetime.timezone() function will prefer that database before the OS database. 5. We can also consider implementing something like the get_localzone() function of my module tzlocal. This solves two problems. i. We have real, useful timezone support in Python. For Unix, it's included, for all other systems, it's just an extra module. The extra module can also be installed to give Python up to date tz information even when the operating system is outdated and unsupported and no longer receiving updates. ii. pytz is_dst flag becomes included in stdlib, solving one of the few imperfections in the current library. What do you say? Is this a path worth pursuing? //Lennart ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 3.3.0
On Sun, Sep 30, 2012 at 01:26:28PM +0200, Georg Brandl wrote: > Thanks. It's really a team effort: a little digging in the hg history says > that: > > * 86 people have committed during the 3.3 development > * 70 during 3.2 development and > * 55 during 3.1 development > > No surprise the feature list is so long... Many kudos to the team and to all contributors! Linux Weekly News regularly publishes tables "Who done what in Linux Kernel": http://lwn.net/Articles/507986/ http://lwn.net/SubscriberLink/517564/bec11e6ace6ad699/ It would be interesting to see tables like these for Python. Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 3.3.0
Thanks. It's really a team effort: a little digging in the hg history says
that:
* 86 people have committed during the 3.3 development
* 70 during 3.2 development and
* 55 during 3.1 development
No surprise the feature list is so long...
cheers,
Georg
On 09/29/2012 05:52 PM, Guido van Rossum wrote:
Congrats Georg and team! I am incredibly proud of you all for
producing such a great release. As the marketeers would say, "Python
3.3 is the best Python ever!" The feature list is amazing.
--Guido
On Sat, Sep 29, 2012 at 5:18 AM, Georg Brandl wrote:
On behalf of the Python development team, I'm delighted to announce the
Python 3.3.0 final release.
Python 3.3 includes a range of improvements of the 3.x series, as well
as easier porting between 2.x and 3.x. Major new features and changes
in the 3.3 release series are:
* PEP 380, syntax for delegating to a subgenerator ("yield from")
* PEP 393, flexible string representation (doing away with the
distinction between "wide" and "narrow" Unicode builds)
* A C implementation of the "decimal" module, with up to 120x speedup
for decimal-heavy applications
* The import system (__import__) now based on importlib by default
* The new "lzma" module with LZMA/XZ support
* PEP 397, a Python launcher for Windows
* PEP 405, virtual environment support in core
* PEP 420, namespace package support
* PEP 3151, reworking the OS and IO exception hierarchy
* PEP 3155, qualified name for classes and functions
* PEP 409, suppressing exception context
* PEP 414, explicit Unicode literals to help with porting
* PEP 418, extended platform-independent clocks in the "time" module
* PEP 412, a new key-sharing dictionary implementation that
significantly saves memory for object-oriented code
* PEP 362, the function-signature object
* The new "faulthandler" module that helps diagnosing crashes
* The new "unittest.mock" module
* The new "ipaddress" module
* The "sys.implementation" attribute
* A policy framework for the email package, with a provisional (see
PEP 411) policy that adds much improved unicode support for email
header parsing
* A "collections.ChainMap" class for linking mappings to a single unit
* Wrappers for many more POSIX functions in the "os" and "signal"
modules, as well as other useful functions such as "sendfile()"
* Hash randomization, introduced in earlier bugfix releases, is now
switched on by default
In total, almost 500 API items are new or improved in Python 3.3.
For a more extensive list of changes in 3.3.0, see
http://docs.python.org/3.3/whatsnew/3.3.html
To download Python 3.3.0 visit:
http://www.python.org/download/releases/3.3.0/
This is a production release, please report any bugs to
http://bugs.python.org/
Enjoy!
--
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] what´s new 3.3
Hi there. Not having kept up, I realized I failed to contribute to the What's new thingie. Here's stuff I remember working on and putting in: 1. pickling support for built in iterators (#14288) 2. inter process socket duplication for windows (#14310) 3. Progress callback for gc module (#10576) 4. Faster locking on windows (#15038) DiSome of this should probably be mentioned in the What's new document, even if only in its online version. K ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Bug Day in October
Wiadomość napisana przez Maciej Szulik w dniu 28 wrz 2012, o godz. 22:52: > On 09/28/2012 12:30 AM, Éric Araujo wrote: >> Hi all, >> >> The Montreal-Python user group would like to host a bug day on October >> 27 (to be confirmed) at a partner university in Montreal. It would be >> cool to do a bug day on IRC like we used to (and in other physical >> locations if people want to!) to get new contributors and close bugs. >> What do you think? >> > > Great idea, I'll talk to Łukasz Langa about possibilities to gather > a group of Poles interested in this topic. Why not, why not :) -- Best regards, Łukasz Langa Senior Systems Architecture Engineer IT Infrastructure Department Grupa Allegro Sp. z o.o. http://lukasz.langa.pl/ +48 791 080 144 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 3.3.0 release candidate 3
Stefan Krah wrote: > Precision: 19 decimal digits > > float: > result: 3.1415926535897927 > time: 0.112874s > > cdecimal: > result: 3.141592653589793236 > time: 0.348100s > > decimal: > result: 3.141592653589793236 > time: 43.241220s Apparently there were concerns about the correctness of the result on some message board. To be clear: This is a *benchmark* designed to execute the same code for float, cdecimal and decimal. The *original* algorithm from the decimal docs uses a higher intermediate context precision. Since floats do not have such a context, this step was deliberately dropped from the benchmark. Stefan Krah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
