Re: [Python-Dev] Bad python 2.5 build on OSX 10.8 mountain lion
Forgot the link... http://code.google.com/p/googleappengine/issues/detail?id=7885 On Monday, October 1, 2012, Guido van Rossum wrote: > As discussed here, the python 2.5 binary distributed by Apple on mountain > lion is broken. Could someone file an official complaint? This is really > bad... > > --Guido > > > -- > --Guido van Rossum (python.org/~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
[Python-Dev] Bad python 2.5 build on OSX 10.8 mountain lion
As discussed here, the python 2.5 binary distributed by Apple on mountain lion is broken. Could someone file an official complaint? This is really bad... --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] Daily DMG builds
Ned Deily writes: > In article <20121001211812.4c40a...@pitrou.net>, > Antoine Pitrou wrote: > >> Hello, >> >> It seems that the daily DMG builds have been failing for some time on >> the default branch: >> http://buildbot.python.org/daily-dmg/ >> >> Since there has been no report or complaint about that, should we just >> stop producing those builds? > > It's failing on a checksum error of the cached download ncurses tarball > which is kind of odd. I've pinged David about it. Ned's email got to me before I got to the list today - the initial issue does appear to be a bad ncurses external download from a while back. The download was Aug 6 so that seems to match when the 3.x dmg stopped being produced. I flushed that and let it grab a new copy. The 3.3 branch then had a separate issue since it was brand new and the Python-ast.[ch] rebuild process doesn't work right under 10.4, but touching the files included in hg resolves that. (If I recall it's because it uses the system python which is ancient - I had done the same fix a while back for the 3.x builder). So I believe things should be ok at this point, or at least back to the way they were previously. > I must admit I don't pay attention to the dmg buildbot but I probably > should. I know I try to catch slave-related failures, but staying on top of all of the builders can be a little tough. I don't think there's a good summary page for the slaves I want to follow, so it's tricky to stay current (plus the trunk stuff tends to have more transient failures). Not sure if there's a way to have per-owner summary pages or anything on the build master. I do use the main build slaves summary page for overall status, but scanning the individual builders is 30+ other pages (the per-slave pages don't often have enough history to cover all the builders), or trying to find each of my builders in the overall waterfall page. Neither approach tends to survive very long in terms of my regularly doing it :-) Anyway, I always welcome (and appreciate) any head's up for failures that seem to be slave-related... > I know at least one person (Raymond) has reported using the dmg > builds regularly and the 2.7 builds are still going. There is a bit of > an issue now for 3.3 and default: the buildbot-slave is apparently > running OS X 10.4 so it is no longer capable of building either of the > two installer variants that we release on python.org (one now requires > at least 10.5 and the other at least 10.6). However, we don't want to > break anything on 10.4, if possible, and the installers still work on > later systems so there is some value in producing them - as long as > someone is paying attention when they break and, hopefully, someone uses > them. It's been a few years since setting this up, but at least at one point I think it was safer to build an installer on the older platform in terms of compatibility, but it wouldn't surprise me if that process has become dated, or no longer necessary. In fact, if I recall correctly, I think Ronald was already using a later platform for his own building when the daily buildbot was set up. At the time I needed a 10.4 platform for local application building (I had an app supporting 10.4 clients and couldn't build it on a later OSX and still have it install on older systems), but it was otherwise idle so available as a buildbot. The physical machine is unlikely to get upgraded beyond 10.4 though. It's never been entirely clear how useful the daily build slaves are. We used to do daily Windows builds too but when they ran into some problems the demand (or lack thereof) didn't seem to justify the time to troubleshoot so they were discontinued. My guess is the same will probably happen to the OSX daily build slave once it hits something difficult to troubleshoot/fix. Although until it does I suppose there's no need to explicitly turn it off. It would still be interesting to know who may still be making use of the images being produced. -- 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] Python Bug Day in October
Le 01/10/2012 18:38, R. David Murray a écrit : > Yes. I think there are people already trying to to (or perhaps > even succeeding) in arranging spaces for that date, so changing > it would be a disruption to those plans. Yes, it’s always a bit painful to go through another round of email, calls or meetings to reschedule. Also it’s fun to kick off the idea and see it take place, great for motivation! Ned: I’m confident we’ll have a place for the planned date, you can make arrangements and we’ll confirm as soon as possible (this week). Maciej: If you don’t think you can let people know in time, by all means lead another bug day some time after, and I’m sure there will be participants on IRC. 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/archive%40mail-archive.com
Re: [Python-Dev] Python Bug Day in October
On 10/02/2012 12:18 AM, Maciej Szulik wrote: 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? Cheers Eric, How do you and Montreal-Pythoon user group see possibility to move this event a little bit in time, to have enough time to organize everything what's needed. In most cases peoples here in Poland. How about doing this event whole month later, meaning end of November? If we all get enough time to prepare and advertise it properly, we might attract bigger group of people, which in long term means more hands to work on bugs :) There's no reason there couldn't be another bug day in November... 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] cpython: utilize yield from
On Oct 1, 2012, at 2:32 PM, Serhiy Storchaka wrote: > On 01.10.12 22:54, philip.jenvey wrote: >> http://hg.python.org/cpython/rev/fb90e2ff95b7 >> changeset: 79378:fb90e2ff95b7 >> user:Philip Jenvey >> date:Mon Oct 01 12:53:43 2012 -0700 >> summary: >> utilize yield from > > This is not all. Applied, thanks Serhiy! -- Philip Jenvey ___ 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 Mon, 01 Oct 2012 17:28:01 -0500, Brian Curtin wrote: > On Mon, Oct 1, 2012 at 5:18 PM, Maciej Szulik wrote: > > 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? > >> > >> Cheers > > > > > > > > Eric, > > How do you and Montreal-Pythoon user group see possibility to move this > > event a little bit in time, to have enough time to organize everything > > what's needed. In most cases peoples here in Poland. How about doing > > this event whole month later, meaning end of November? If we all get > > enough time to prepare and advertise it properly, we might attract > > bigger group of people, which in long term means more hands to > > work on bugs :) > > > > Regards, > > Maciej > > You could also wait three months and get even more people, or wait 6 > months and maybe get even *more* people. You could also lose everyone > else's interest during that time. > > I think if people want to join up on the chosen date, it'd be > excellent. If they want to meet up on another date, this is also > excellent. It doesn't need to be a one time thing :) Yes. I think there are people already trying to to (or perhaps even succeeding) in arranging spaces for that date, so changing it would be a disruption to those plans. On the other hand we could also let those people speak up... Having another one at the end of November would be great. --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] Python Bug Day in October
On Mon, Oct 1, 2012 at 5:18 PM, Maciej Szulik wrote: > 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? >> >> Cheers > > > > Eric, > How do you and Montreal-Pythoon user group see possibility to move this > event a little bit in time, to have enough time to organize everything > what's needed. In most cases peoples here in Poland. How about doing > this event whole month later, meaning end of November? If we all get > enough time to prepare and advertise it properly, we might attract > bigger group of people, which in long term means more hands to > work on bugs :) > > Regards, > Maciej You could also wait three months and get even more people, or wait 6 months and maybe get even *more* people. You could also lose everyone else's interest during that time. I think if people want to join up on the chosen date, it'd be excellent. If they want to meet up on another date, this is also excellent. It doesn't need to be a one time thing :) ___ 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 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? Cheers Eric, How do you and Montreal-Pythoon user group see possibility to move this event a little bit in time, to have enough time to organize everything what's needed. In most cases peoples here in Poland. How about doing this event whole month later, meaning end of November? If we all get enough time to prepare and advertise it properly, we might attract bigger group of people, which in long term means more hands to work on bugs :) Regards, Maciej ___ 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
Am 30.09.2012 14:01, schrieb Oleg Broytman: >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. Ohloh has lots of statistics and graphics: https://www.ohloh.net/p/python ___ 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] cpython: utilize yield from
On 01.10.12 22:54, philip.jenvey wrote:
http://hg.python.org/cpython/rev/fb90e2ff95b7
changeset: 79378:fb90e2ff95b7
user:Philip Jenvey
date:Mon Oct 01 12:53:43 2012 -0700
summary:
utilize yield from
This is not all.
diff -r fb90e2ff95b7 Lib/http/cookiejar.py
--- a/Lib/http/cookiejar.py Mon Oct 01 12:53:43 2012 -0700
+++ b/Lib/http/cookiejar.py Tue Oct 02 00:28:41 2012 +0300
@@ -1193,8 +1193,7 @@
pass
else:
mapping = True
-for subobj in deepvalues(obj):
-yield subobj
+yield from deepvalues(obj)
if not mapping:
yield obj
diff -r fb90e2ff95b7 Lib/json/encoder.py
--- a/Lib/json/encoder.py Mon Oct 01 12:53:43 2012 -0700
+++ b/Lib/json/encoder.py Tue Oct 02 00:28:41 2012 +0300
@@ -305,8 +305,7 @@
chunks = _iterencode_dict(value, _current_indent_level)
else:
chunks = _iterencode(value, _current_indent_level)
-for chunk in chunks:
-yield chunk
+yield from chunks
if newline_indent is not None:
_current_indent_level -= 1
yield '\n' + _indent * _current_indent_level
@@ -381,8 +380,7 @@
chunks = _iterencode_dict(value, _current_indent_level)
else:
chunks = _iterencode(value, _current_indent_level)
-for chunk in chunks:
-yield chunk
+yield from chunks
if newline_indent is not None:
_current_indent_level -= 1
yield '\n' + _indent * _current_indent_level
@@ -404,11 +402,9 @@
elif isinstance(o, float):
yield _floatstr(o)
elif isinstance(o, (list, tuple)):
-for chunk in _iterencode_list(o, _current_indent_level):
-yield chunk
+yield from _iterencode_list(o, _current_indent_level)
elif isinstance(o, dict):
-for chunk in _iterencode_dict(o, _current_indent_level):
-yield chunk
+yield from _iterencode_dict(o, _current_indent_level)
else:
if markers is not None:
markerid = id(o)
@@ -416,8 +412,7 @@
raise ValueError("Circular reference detected")
markers[markerid] = o
o = _default(o)
-for chunk in _iterencode(o, _current_indent_level):
-yield chunk
+yield from _iterencode(o, _current_indent_level)
if markers is not None:
del markers[markerid]
return _iterencode
diff -r fb90e2ff95b7 Lib/xml/etree/ElementPath.py
--- a/Lib/xml/etree/ElementPath.py Mon Oct 01 12:53:43 2012 -0700
+++ b/Lib/xml/etree/ElementPath.py Tue Oct 02 00:28:41 2012 +0300
@@ -105,14 +105,12 @@
def prepare_star(next, token):
def select(context, result):
for elem in result:
-for e in elem:
-yield e
+yield from elem
return select
def prepare_self(next, token):
def select(context, result):
-for elem in result:
-yield elem
+yield from result
return select
def prepare_descendant(next, token):
diff -r fb90e2ff95b7 Lib/xml/etree/ElementTree.py
--- a/Lib/xml/etree/ElementTree.py Mon Oct 01 12:53:43 2012 -0700
+++ b/Lib/xml/etree/ElementTree.py Tue Oct 02 00:28:41 2012 +0300
@@ -459,8 +459,7 @@
if tag is None or self.tag == tag:
yield self
for e in self._children:
-for e in e.iter(tag):
-yield e
+yield from e.iter(tag)
# compatibility
def getiterator(self, tag=None):
@@ -487,8 +486,7 @@
if self.text:
yield self.text
for e in self:
-for s in e.itertext():
-yield s
+yield from e.itertext()
if e.tail:
yield e.tail
diff -r fb90e2ff95b7 Tools/importbench/importbench.py
--- a/Tools/importbench/importbench.py Mon Oct 01 12:53:43 2012 -0700
+++ b/Tools/importbench/importbench.py Tue Oct 02 00:28:41 2012 +0300
@@ -46,8 +46,7 @@
module.__package__ = ''
with util.uncache(name):
sys.modules[name] = module
-for result in bench(name, repeat=repeat, seconds=seconds):
-yield result
+yield from bench(name, repeat=repeat, seconds=seconds)
def builtin_mod(seconds, repeat):
@@ -56,9 +55,8 @@
if name in sys.modules:
del sys.modules[name]
# Relying on built-in importer being implicit.
-for result in bench(name, lambda: sys.modules.pop(name), repeat=repeat,
-seconds=seconds):
-yield result
+yield from bench(name, lambda: sys.modules.pop(name), repeat=repeat,
+ seconds=seconds)
def source_wo_bytecode(seconds, repeat):
@@ -73,9 +71,8 @@
loader = (importlib.machinery.SourceFi
Re: [Python-Dev] [Python-checkins] cpython (merge 3.3 -> default): Merge: #16304: Optimizations for BZ2File, and minor bugfix.
On Mon, Oct 1, 2012 at 11:11 PM, nadeem.vawda wrote: > http://hg.python.org/cpython/rev/a19f47d380d2 > changeset: 79382:a19f47d380d2 > parent: 79378:fb90e2ff95b7 > parent: 79381:6d7bf512e0c3 > user:Nadeem Vawda > date:Mon Oct 01 23:11:35 2012 +0200 > summary: > Merge: #16304: Optimizations for BZ2File, and minor bugfix. Correction: this is actually for issue *#16034*, as are all of my other recent changesets referring to issue #16304. ___ 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 [IPv6:2001:888:2000:d::a6])
by psf.upfronthosting.co.za (Postfix) with ESMTPS id 1F76E1C876
for ; Mon, 1 Oct 2012 23:11:54 +0200 (CEST)
Received: from albatross.python.org (localhost [127.0.0.1])
by mail.python.org (Postfix) with ESMTP id 3XVx5569b6zQsL
for ; Mon, 1 Oct 2012 23:11:53 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=python.org; s=200901;
t=1349125913; bh=bvONg+T9Lsep8hEPCu2kUnhY3MftIhWNUuY1WjZ7F58=;
h=MIME-Version:Content-Type:Content-Transfer-Encoding:From:To:
Subject:Message-Id:Date;
b=xmALJn1wwY3MQWnHpkjiY2RETSwhJQlyfvfzhqimSE5MnyqvmO9/FgTXdveEFWZWo
bryTanG+BI84fdYsRn37TuXNbUkcs/A7DjE1vWbpDUNdBkw3jdxQveGc8PWX/P/Ui2
aKOfPopoJgIywncnGIsrcycGG/hSfkkk/9tcb5YM=
Received: from localhost (HELO mail.python.org) (127.0.0.1)
by albatross.python.org with SMTP; 01 Oct 2012 23:11:53 +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 23:11:53 +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: <3xvx5569b6z...@mail.python.org>
Date: Mon, 1 Oct 2012 23:11:53 +0200 (CEST)
TmV3IGNoYW5nZXNldCBlNmQ4NzJiNjFjNTcgYnkgTmFkZWVtIFZhd2RhIGluIGJyYW5jaCAnMy4z
JzoKSXNzdWUgIzE2MzA0OiBBbm90aGVyIHBlcmZvcm1hbmNlIG9wdGltaXphdGlvbiBmb3IgQloy
RmlsZS4KaHR0cDovL2hnLnB5dGhvbi5vcmcvY3B5dGhvbi9yZXYvZTZkODcyYjYxYzU3CgoKTmV3
IGNoYW5nZXNldCA2ZDdiZjUxMmUwYzMgYnkgTmFkZWVtIFZhd2RhIGluIGJyYW5jaCAnMy4zJzoK
SXNzdWUgIzE2MzA0OiBGdXJ0aGVyIG9wdGltaXplIEJaMkZpbGUucmVhZGxpbmVzPygpLgpodHRw
Oi8vaGcucHl0aG9uLm9yZy9jcHl0aG9uL3Jldi82Z
Re: [Python-Dev] Stdlib and timezones, again
On Mon, 01 Oct 2012 21:59:03 +0200, Lennart Regebro wrote: > On Mon, Oct 1, 2012 at 9:02 PM, R. David Murray wrote: > > On Tue, 02 Oct 2012 00:18:10 +0530, Nick Coghlan wrote: > >> Reminder to everyone: the current state of the art for getting up to > >> date tz info for Python is "pip install pytz". > >> > >> If any proposal is more complicated than that, there's absolutely no > >> point in changing anything. The version I liked best so far is for > >> Python to just install a copy of pytz automatically (shipping it in > >> the installer rather than downloading it). OS packagers would then > >> take it out (replacing it with a dependency on a pytz emulator that > >> used the system database instead). > > > > Emulator? That makes no sense, I'm afraid. > > It wouldn't emulate anything, though. Ubuntu already does this, they > ship a version of pytz that includes no database, and just point it to > /usr/share/zoneinfo instead. That's what I meant. It's not an emulator. --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] Stdlib and timezones, again
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. The order exists this way to allow for customization. If I have 1) downloaded the most recent, or 2) made customizations (for whatever reason) then Python needs to use it. Can I break stuff this way? Sure. Is it Python's responsibility to stop me? Nope. Consenting adults, and all that. ~Ethan~ ___ 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] Daily DMG builds
In article <20121001211812.4c40a...@pitrou.net>, Antoine Pitrou wrote: > Hello, > > It seems that the daily DMG builds have been failing for some time on > the default branch: > http://buildbot.python.org/daily-dmg/ > > Since there has been no report or complaint about that, should we just > stop producing those builds? It's failing on a checksum error of the cached download ncurses tarball which is kind of odd. I've pinged David about it. I must admit I don't pay attention to the dmg buildbot but I probably should. I know at least one person (Raymond) has reported using the dmg builds regularly and the 2.7 builds are still going. There is a bit of an issue now for 3.3 and default: the buildbot-slave is apparently running OS X 10.4 so it is no longer capable of building either of the two installer variants that we release on python.org (one now requires at least 10.5 and the other at least 10.6). However, we don't want to break anything on 10.4, if possible, and the installers still work on later systems so there is some value in producing them - as long as someone is paying attention when they break and, hopefully, someone uses them. -- Ned Deily, n...@acm.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 Mon, Oct 1, 2012 at 9:02 PM, R. David Murray wrote: > On Tue, 02 Oct 2012 00:18:10 +0530, Nick Coghlan wrote: >> Reminder to everyone: the current state of the art for getting up to >> date tz info for Python is "pip install pytz". >> >> If any proposal is more complicated than that, there's absolutely no >> point in changing anything. The version I liked best so far is for >> Python to just install a copy of pytz automatically (shipping it in >> the installer rather than downloading it). OS packagers would then >> take it out (replacing it with a dependency on a pytz emulator that >> used the system database instead). > > Emulator? That makes no sense, I'm afraid. It wouldn't emulate anything, though. Ubuntu already does this, they ship a version of pytz that includes no database, and just point it to /usr/share/zoneinfo instead. //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
[Python-Dev] Daily DMG builds
Hello, It seems that the daily DMG builds have been failing for some time on the default branch: http://buildbot.python.org/daily-dmg/ Since there has been no report or complaint about that, should we just stop producing those builds? 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 12:02 PM, Barry Warsaw wrote: > On Oct 02, 2012, at 12:18 AM, Nick Coghlan wrote: > >>Reminder to everyone: the current state of the art for getting up to >>date tz info for Python is "pip install pytz". >> >>If any proposal is more complicated than that, there's absolutely no >>point in changing anything. The version I liked best so far is for >>Python to just install a copy of pytz automatically (shipping it in >>the installer rather than downloading it). OS packagers would then >>take it out (replacing it with a dependency on a pytz emulator that >>used the system database instead). > > Why wouldn't the stdlib just ship with that emulator by default then? If your > OS doesn't have a system database, then you `pip install pytz` ftw. I think those are all suggestions included in Nick's intention. The main points are that (a) pytz and some not-too-ancient Olson database are included by default, (b) vendor distributions can tweak the packaging so that the platform's copy of the Olson database is used automatically; (c) users not benefitting from such vendor support can update the database as easily as "pip install pytz" (though not necessarily with that specific command). -- --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
Gah, ignore half of that last post. I think Lennart is talking about incorporating the missing pytz *functionality* into the stdlib. --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] Stdlib and timezones, again
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/01/2012 02:48 PM, Nick Coghlan wrote: > Reminder to everyone: the current state of the art for getting up to > date tz info for Python is "pip install pytz". > > If any proposal is more complicated than that, there's absolutely no > point in changing anything. The version I liked best so far is for > Python to just install a copy of pytz automatically (shipping it in > the installer rather than downloading it). OS packagers would then > take it out (replacing it with a dependency on a pytz emulator that > used the system database instead). Lennart's original proposal was to land the machinery from the current pytz package into the stdlib, leaving the data part as a separately-installable package. Lennart also proposed some kind of (maybe configurable) policy for looking up the Olson-based timezonedb. I'm fine with Lennart's proposal, but want to argue against including any copy of the Olson db in Python itself: I don't believe the set of folks who need it but can't do the equivalent of 'pip / easy_install ' is big enough to outweigh the downside of bundling immediately-stale data, and hoping that everybody else remembers to configure it out. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBp6OkACgkQ+gerLs4ltQ4fZwCfUtz9lnkjxM6rdTaO0io1yzIP f2cAn0YfQt+n09Znuh6BZ/Culixpf7eE =ecDk -END PGP SIGNATURE- ___ 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 Oct 02, 2012, at 12:18 AM, Nick Coghlan wrote: >Reminder to everyone: the current state of the art for getting up to >date tz info for Python is "pip install pytz". > >If any proposal is more complicated than that, there's absolutely no >point in changing anything. The version I liked best so far is for >Python to just install a copy of pytz automatically (shipping it in >the installer rather than downloading it). OS packagers would then >take it out (replacing it with a dependency on a pytz emulator that >used the system database instead). Why wouldn't the stdlib just ship with that emulator by default then? If your OS doesn't have a system database, then you `pip install pytz` ftw. Cheers, -Barry ___ 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:48 PM, Nick Coghlan wrote: > If any proposal is more complicated than that, there's absolutely no > point in changing anything. The version I liked best so far is for > Python to just install a copy of pytz automatically (shipping it in > the installer rather than downloading it). OS packagers would then > take it out (replacing it with a dependency on a pytz emulator that > used the system database instead). But that would then mean that when you install from source, as I typically do to avoid depending on Python, it would use another database than the OS version. I don't want that, i want Python on Unix to use the OS supplied database, unless another one is explicitly installed/configured. //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 Tue, 02 Oct 2012 00:18:10 +0530, Nick Coghlan wrote: > Reminder to everyone: the current state of the art for getting up to > date tz info for Python is "pip install pytz". > > If any proposal is more complicated than that, there's absolutely no > point in changing anything. The version I liked best so far is for > Python to just install a copy of pytz automatically (shipping it in > the installer rather than downloading it). OS packagers would then > take it out (replacing it with a dependency on a pytz emulator that > used the system database instead). Emulator? That makes no sense, I'm afraid. I think we are talking here about incorporating pytz into the stdlib. The only question is how to manage the Olson database on Windows, which has *always* been the question. --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] Stdlib and timezones, again
Reminder to everyone: the current state of the art for getting up to date tz info for Python is "pip install pytz". If any proposal is more complicated than that, there's absolutely no point in changing anything. The version I liked best so far is for Python to just install a copy of pytz automatically (shipping it in the installer rather than downloading it). OS packagers would then take it out (replacing it with a dependency on a pytz emulator that used the system database instead). Cheers, Nick. ___ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/01/2012 10:12 AM, Antoine Pitrou wrote: > On Mon, 1 Oct 2012 16:06:18 +0200 Lennart Regebro > wrote: >> Actually, that's not a bad idea. My original idea was to warn if it >> *was* outdated, but since there is no way to check that, I scratched >> that idea. But as I have pointed out several times, a database that >> is shipped with Python is almost guaranteed to be outdated, so yeah, >> we could just warn *all the time*. :-) >> >> I like this idea. It gives an incentive to update: Get rid of the >> annoying warning. > > Well, no, it is just silly. If we ship a database, that's because we > think it is good enough. A warning is just a nuisance here. We don't > display warnings when the installed Python version is too old. Using a bundled version would be the Wrong Thing (TM) for almost any non-toy application (one where non-programmers actually care about the timezones in which dates / times are entered / displayed): the fact that the errors would infrequent / subtle / hard to diagnose is an argument *against* inclusion. - -1 for including a copy in Python at all: if your app needs it, and the OS on which you deploy doesn't provide it, you have a straightforward way of installing it. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEUEARECAAYFAlBp36IACgkQ+gerLs4ltQ4mbACY60cQ1SbUgRh0hNtUmxScRM68 ZwCg125QzeMmhFV0VYYZGmNVmEqpajo= =ehg8 -END PGP SIGNATURE- ___ 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 10/1/2012 12:39 PM, Lennart Regebro wrote: On Mon, Oct 1, 2012 at 6:21 PM, Larry Hastings mailto:la...@hastings.org>> wrote: On 10/01/2012 04:29 PM, Barry Warsaw wrote: Using the script I mentioned in an different response, if someone installed the database to some location (TBD), then there would probably be a config file sitting next to it. A simple .ini file with an 'enable' flag would be needed to turn on the override. Perhaps said config file could also contain the timestamp of the tz database? Then we could intelligently choose the most currentest one. The most current one is likely to be the one provided by the operating system, which does not contain any .ini file, nor, as far as I can tell, any information about the database version or any timestamps. But Windows does not provide one, or at least, the proposal seems to be not use whatever it does have. I think your PEP should propose one api but conditional tz db access code for systems with and without the tz db already provided. -- Terry Jan Reedy ___ 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] peps: describe the current policy
On 10/01/2012 07:38 PM, benjamin.peterson wrote: http://hg.python.org/peps/rev/641add9f9542 changeset: 4530:641add9f9542 user:Benjamin Peterson date:Mon Oct 01 13:38:31 2012 -0400 summary: describe the current policy files: pep-0373.txt | 8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/pep-0373.txt b/pep-0373.txt --- a/pep-0373.txt +++ b/pep-0373.txt @@ -49,6 +49,14 @@ Maintenance releases +Being the last of the 2.x series, 2.7 will have an extended period of +maintenance. The current plan is to support it for at least 5 years +from the initial 2.7 release. This means there will be bugfix releases +until 2015. Depending on Python 3 adoption, this may be modified up or +down. TBH, I would guarantee it for at least 5 years: the current wording is not an improvement over the current situation as it basically does not tell anything definite. 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 Mon, Oct 1, 2012 at 6:21 PM, Larry Hastings wrote: > On 10/01/2012 04:29 PM, Barry Warsaw wrote: > > Using the script I mentioned in an different response, if someone installed > the database to some location (TBD), then there would probably be a config > file sitting next to it. A simple .ini file with an 'enable' flag would be > needed to turn on the override. > > > Perhaps said config file could also contain the timestamp of the tz > database? Then we could intelligently choose the most currentest one. > The most current one is likely to be the one provided by the operating system, which does not contain any .ini file, nor, as far as I can tell, any information about the database version or any timestamps. //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 10/01/2012 04:29 PM, Barry Warsaw wrote: Using the script I mentioned in an different response, if someone installed the database to some location (TBD), then there would probably be a config file sitting next to it. A simple .ini file with an 'enable' flag would be needed to turn on the override. Perhaps said config file could also contain the timestamp of the tz database? Then we could intelligently choose the most currentest one. //arry/ ___ 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 5:32 PM, Terry Reedy wrote: > On 10/1/2012 10:06 AM, Lennart Regebro wrote: > > Actually, that's not a bad idea. My original idea was to warn if it >> *was* outdated, but since there is no way to check that, I scratched >> that idea. >> > > Is there really no way to get a 'last updated' time from the site where > the database is kept? Sure, but there is no way to get a last updated time from the database that's installed. And making an HTTP request when you call localize() to check if the database is outdated or not doesn't seem to be a great idea. //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 Mon, Oct 1, 2012 at 5:38 PM, Barry Warsaw wrote: > On Oct 01, 2012, at 05:29 PM, Lennart Regebro wrote: > > >We seem to be on the same page here. > > Well, that was easy! Maybe I should be your PEP Czar :) > That sounds great! What's a PEP Czar? //My First 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 2012-10-01, at 17:32 , Terry Reedy wrote: > On 10/1/2012 10:06 AM, Lennart Regebro wrote: > >> Actually, that's not a bad idea. My original idea was to warn if it >> *was* outdated, but since there is no way to check that, I scratched >> that idea. > > Is there really no way to get a 'last updated' time from the site where the > database is kept? If not, perhaps we should provide one with a daily job (on > pypi?) that downloads and compares. There are several: there's a message on a dedicated mailing list and there are HTTP, FTP and rsync repositories with both all releases and a "latest" archive for both tzdata and tzcode. The HTTP repositories seems to handle time-based conditional requests correctly (an If-Modified-Since with the date of the latest release or later will result in a 304 response, earlier will result in a 200) The HTTP URIs are https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz and https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz For some reason, IANA does not seem to publish a feed. ___ 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, 1 Oct 2012 11:25:08 -0400 Barry Warsaw wrote: > > If you have an OS that keeps the system tz data up-to-date, I can't think of > any reason why you wouldn't want to use it. > > If you don't have the data, why not include information in the documentation > for how to download and install the database in a location that Python will > search for, along with information on how to enable that? Well, for one, that doesn't really fit in the "batteries included" approach. Having to download separate data files is an annoyance. > You could even > provide a nice script that would download, install, and optionally enable that > tz data's use. This doesn't solve the update problem at all, since that tz data would still be outdated after a couple of months. In other words, it has no benefit for the user, but is more complicated to use. Besides, that script would have to care about security issues. For example you'd use a HTTPS-enabled source, and then bundle the required CA certificates with Python. But wait, now Python has to ship some data that will possibly become outdated in a year or two :-) 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 Oct 01, 2012, at 05:29 PM, Lennart Regebro wrote: >We seem to be on the same page here. Well, that was easy! Maybe I should be your PEP Czar :) -Barry signature.asc Description: PGP signature ___ 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 5:29 PM, Barry Warsaw wrote: > On Oct 01, 2012, at 05:15 PM, Lennart Regebro wrote: > > >On Mon, Oct 1, 2012 at 5:11 PM, Barry Warsaw wrote: > > > >> I completely agree that just installing the Cheeseshop tz package should > >> *not* be enough to prefer it over the system tz data. > > > >Do you have another potential mechanism in mind? > > Yes. > > Using the script I mentioned in an different response, if someone installed > the database to some location (TBD), then there would probably be a config > file sitting next to it. A simple .ini file with an 'enable' flag would be > needed to turn on the override. > OK, I'll have that in mind. ___ 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 10/1/2012 10:06 AM, Lennart Regebro wrote: Actually, that's not a bad idea. My original idea was to warn if it *was* outdated, but since there is no way to check that, I scratched that idea. Is there really no way to get a 'last updated' time from the site where the database is kept? If not, perhaps we should provide one with a daily job (on pypi?) that downloads and compares. -- Terry Jan Reedy ___ 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 Oct 01, 2012, at 05:15 PM, Lennart Regebro wrote: >On Mon, Oct 1, 2012 at 5:11 PM, Barry Warsaw wrote: > >> I completely agree that just installing the Cheeseshop tz package should >> *not* be enough to prefer it over the system tz data. > >Do you have another potential mechanism in mind? Yes. Using the script I mentioned in an different response, if someone installed the database to some location (TBD), then there would probably be a config file sitting next to it. A simple .ini file with an 'enable' flag would be needed to turn on the override. Cheers, -Barry signature.asc Description: PGP signature ___ 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 5:25 PM, Barry Warsaw wrote: > On Sep 30, 2012, at 02:47 PM, Lennart Regebro wrote: > > >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. > > Why include the database in Python at all? > Exactly my point. > If you have an OS that keeps the system tz data up-to-date, I can't think > of > any reason why you wouldn't want to use it. > > If you don't have the data, why not include information in the > documentation > for how to download and install the database in a location that Python will > search for, along with information on how to enable that? You could even > provide a nice script that would download, install, and optionally enable > that > tz data's use. > Right, I was going to do that by bundling the files in a package, tentatively called pytzdata, available on PyPI, so it can be easy_installed/pip installed, etc. > I think that would cover all the bases: > > * My OS keeps the tz data up-to-date. I don't have to do nuthin', and > Python > gives me a nice API for using all the world's timezones on my superb OS. > > * My OS keeps the tz data up-to-date, but I'm skeptical. I run the update > script whenever is appropriate, adding the --enable flag, and the tz > data is > grabbed from the intarwebs, installed, and Python starts using it > instead of > the system data. > > * I am sad because I use an OS that has no tz data. I run the update > script > once in a while, adding the --enable flag, and my Python is timezonally > happy. > > * I'm sad and lazy. Oh well, Python throws an exception when I try to use > a > timezone that isn't UTC. > We seem to be on the same page here. //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 Mon, 1 Oct 2012 10:16:16 -0500 Zachary Ware wrote: > > > > But I don't think a warning is warranted, anymore than for other known > > issues (there are many of them at http://bugs.python.org/ :-)). > > > > Just curious (and a bit off topic), what exactly does warrant a warning in > Python? I've been messing around with it for a couple years (since shortly > before 3.1, and always on 3.x) and I'm pretty sure I have yet to see a > warning for anything. Which I suppose could be counted as a good thing... We don't really have a well-defined policy, except for one warning category: DeprecationWarnings, whose purpose are quite clear. But they are now silenced by default :-) Generally, warnings are not easy to deal with for the end-user, so we are reluctant to add any. We'd rather document annoyances and pitfalls; and, moreover, we try to design our APIs so that they don't have unexpected effects. 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 Sep 30, 2012, at 02:47 PM, Lennart Regebro wrote: >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. Why include the database in Python at all? If you have an OS that keeps the system tz data up-to-date, I can't think of any reason why you wouldn't want to use it. If you don't have the data, why not include information in the documentation for how to download and install the database in a location that Python will search for, along with information on how to enable that? You could even provide a nice script that would download, install, and optionally enable that tz data's use. I think that would cover all the bases: * My OS keeps the tz data up-to-date. I don't have to do nuthin', and Python gives me a nice API for using all the world's timezones on my superb OS. * My OS keeps the tz data up-to-date, but I'm skeptical. I run the update script whenever is appropriate, adding the --enable flag, and the tz data is grabbed from the intarwebs, installed, and Python starts using it instead of the system data. * I am sad because I use an OS that has no tz data. I run the update script once in a while, adding the --enable flag, and my Python is timezonally happy. * I'm sad and lazy. Oh well, Python throws an exception when I try to use a timezone that isn't UTC. Cheers, -Barry ___ 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, 1 Oct 2012 11:11:46 -0400 Barry Warsaw wrote: > > I agree. I don't think the Python RM should have to worry about tz updates, > given how frequent or unpredictable they can be. I don't understand what makes them specifically "unpredictable". We statically link OpenSSL and other libraries in the Windows builds. I don't think they have very predictable updates either (especially OpenSSL, actually). 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 Oct 1, 2012 10:06 AM, "Antoine Pitrou" wrote: > > On Mon, 1 Oct 2012 09:52:09 -0500 > Zachary Ware wrote: > > > > My thought was that it's better to have *something* always available, > > that has a decent chance of being "good enough" in a lot of cases (and > > if it's good enough for you, just silence the warning), than to > > noisily fail because we can't provide a perfect solution due to > > political idiocy. Or worse, to *silently* be wrong because someone > > assumed we had provided a perfect solution without looking too hard. > > We can, and should, mention potential pitfalls in the documentation. With large red text and blink tags :-P > > But I don't think a warning is warranted, anymore than for other known > issues (there are many of them at http://bugs.python.org/ :-)). > Just curious (and a bit off topic), what exactly does warrant a warning in Python? I've been messing around with it for a couple years (since shortly before 3.1, and always on 3.x) and I'm pretty sure I have yet to see a warning for anything. Which I suppose could be counted as a good thing... ___ 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 5:11 PM, Barry Warsaw wrote: > I completely agree that just installing the Cheeseshop tz package should > *not* > be enough to prefer it over the system tz data. Do you have another potential mechanism in mind? //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 Oct 01, 2012, at 03:34 PM, Lennart Regebro wrote: >On Mon, Oct 1, 2012 at 3:22 PM, Nick Coghlan wrote: > >> 1. Consider TZ database updates to be bug fixes, and thus include them >> in maintenance releases. This will keep the provided version >> reasonably fresh for Python versions that are still in maintenance >> mode. >> 2. Provide a mechanism to prefer the database from PyPI. >> 3. Provide a mechanism to prefer the OS database for platforms that >> provide an Olson compatible interface (I briefly looked into that for >> Windows a while back - it doesn't seem like a practical idea, since >> Microsoft went off and did their own thing. It works for Linux and >> other platforms that use the Olson database natively, though) > >I proposed 2 and 3, and I don't really see much magical side-effects with >those. As mentioned we can also include a database in the standardlib, but >since that will almost always be out of date, I don't really see the point. >It is of course only an issue on Windows, but still. I agree. I don't think the Python RM should have to worry about tz updates, given how frequent or unpredictable they can be. For OSes that provide the database, I can't think of any reason not to prefer that, except if your OS version is no longer being maintained, and then it seems like updating your tz database is the least of your worries. However, if someone wants to maintain a Cheeseshop package with updates, I can't stop them. My biggest concern there is that eventually the maintainers will lose interest and this package will bitrot, and then we'll have obsolete tz info out there that people will still rely on. Oh well, I guess. I completely agree that just installing the Cheeseshop tz package should *not* be enough to prefer it over the system tz data. Cheers, -Barry ___ 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, 1 Oct 2012 09:52:09 -0500 Zachary Ware wrote: > > My thought was that it's better to have *something* always available, > that has a decent chance of being "good enough" in a lot of cases (and > if it's good enough for you, just silence the warning), than to > noisily fail because we can't provide a perfect solution due to > political idiocy. Or worse, to *silently* be wrong because someone > assumed we had provided a perfect solution without looking too hard. We can, and should, mention potential pitfalls in the documentation. But I don't think a warning is warranted, anymore than for other known issues (there are many of them at http://bugs.python.org/ :-)). 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 9:12 AM, Antoine Pitrou wrote: > On Mon, 1 Oct 2012 16:06:18 +0200 > Lennart Regebro wrote: >> Actually, that's not a bad idea. My original idea was to warn if it *was* >> outdated, but since there is no way to check that, I scratched that idea. >> But as I have pointed out several times, a database that is shipped with >> Python is almost guaranteed to be outdated, so yeah, we could just warn >> *all the time*. :-) >> >> I like this idea. It gives an incentive to update: Get rid of the annoying >> warning. > > Well, no, it is just silly. If we ship a database, that's because we > think it is good enough. A warning is just a nuisance here. We don't > display warnings when the installed Python version is too old. > My thought was that it's better to have *something* always available, that has a decent chance of being "good enough" in a lot of cases (and if it's good enough for you, just silence the warning), than to noisily fail because we can't provide a perfect solution due to political idiocy. Or worse, to *silently* be wrong because someone assumed we had provided a perfect solution without looking too hard. I had no idea the Olson database was updated so often until Dirkjan posted about there being 21 updates in 2009 alone. For most of my uses, I would probably be a warning-silencer. And that wouldn't bother me; I would actually appreciate being reminded now and then that things may have changed since the last time I did something with timezones, and that I need to be careful of such changes. But, of course, that's just me, and it was my idea anyway ;) ___ 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, 1 Oct 2012 16:06:18 +0200 Lennart Regebro wrote: > Actually, that's not a bad idea. My original idea was to warn if it *was* > outdated, but since there is no way to check that, I scratched that idea. > But as I have pointed out several times, a database that is shipped with > Python is almost guaranteed to be outdated, so yeah, we could just warn > *all the time*. :-) > > I like this idea. It gives an incentive to update: Get rid of the annoying > warning. Well, no, it is just silly. If we ship a database, that's because we think it is good enough. A warning is just a nuisance here. We don't display warnings when the installed Python version is too old. 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 10/01/2012 12:07 AM, Chris Angelico wrote: There's no guarantee that an individual sysadmin will have OS updates up-to-date. Is there a way of asking the database its revision / date? If so we could simply use the freshest data we can lay our hands on. //arry/ ___ 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 3:57 PM, Zachary Ware wrote: > Re: to bundle or not to bundle > > What about having an included database that issues a (silence-able) > warning any time it is used/imported/etc.? Have it say something to the > effect of "Warning, the Olson database included with Python is likely to be > outdated, please see for information" where (which may > just be the doc page for the module) spells out why it's outdated, why it's > not possible for it to be kept up to date, that this version may still work > for you depending on application and how to silence the warning, and how to > get the latest version via pypi or otherwise. > > As far as preference of database, I would think the best route would be to > provide the ability to set the order you want to look in, with the default > being: > 1) user specified source (usually not one of the below) > 2) updated tzdb from pypi > 3) OS's tzdb > 4) included tzdb (with warning) > > My $0.02USD, for what they're worth :) > Actually, that's not a bad idea. My original idea was to warn if it *was* outdated, but since there is no way to check that, I scratched that idea. But as I have pointed out several times, a database that is shipped with Python is almost guaranteed to be outdated, so yeah, we could just warn *all the time*. :-) I like this idea. It gives an incentive to update: Get rid of the annoying warning. It also will be silent on Unix, as we'll use the OS database, so this will only happen on Windows or if you embed Python or similar. //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] [Python-checkins] peps: 3.2 and 3.3 release schedules: add information on bugfix releases and release
On Oct 01, 2012, at 06:57 PM, Nick Coghlan wrote: >On Mon, Oct 1, 2012 at 5:51 PM, georg.brandl >wrote: >> +3.3.1 schedule >> +-- >> + >> +- 3.3.1 beta 1: planned for Oct/Nov 2012 > >Copy and paste error from the 3.2 PEP? > >And thanks for adding these - very handy. Agreed. Perhaps the 2.7 RM would like to add something similar for that release? Cheers, -Barry ___ 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
Re: to bundle or not to bundle What about having an included database that issues a (silence-able) warning any time it is used/imported/etc.? Have it say something to the effect of "Warning, the Olson database included with Python is likely to be outdated, please see for information" where (which may just be the doc page for the module) spells out why it's outdated, why it's not possible for it to be kept up to date, that this version may still work for you depending on application and how to silence the warning, and how to get the latest version via pypi or otherwise. As far as preference of database, I would think the best route would be to provide the ability to set the order you want to look in, with the default being: 1) user specified source (usually not one of the below) 2) updated tzdb from pypi 3) OS's tzdb 4) included tzdb (with warning) My $0.02USD, for what they're worth :) ___ 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 3:22 PM, Nick Coghlan wrote: > If a timezone database is bundled into the standard library, there are > 3 clear mechanisms for encouraging the use of fresh TZ data: > > 1. Consider TZ database updates to be bug fixes, and thus include them > in maintenance releases. This will keep the provided version > reasonably fresh for Python versions that are still in maintenance > mode. > 2. Provide a mechanism to prefer the database from PyPI. > 3. Provide a mechanism to prefer the OS database for platforms that > provide an Olson compatible interface (I briefly looked into that for > Windows a while back - it doesn't seem like a practical idea, since > Microsoft went off and did their own thing. It works for Linux and > other platforms that use the Olson database natively, though) > > Since explicit is better than implicit, I *wouldn't* want to see > magical side affects where merely installing the database from PyPI, > or switching from Windows to Linux caused different behaviour. > However, it should be very easy for an application or environment to > *explicitly request* the use of the pytz database or the OS database > in preference to the bundled database. > I proposed 2 and 3, and I don't really see much magical side-effects with those. As mentioned we can also include a database in the standardlib, but since that will almost always be out of date, I don't really see the point. It is of course only an issue on Windows, but still. //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 Mon, Oct 1, 2012 at 3:22 PM, Nick Coghlan wrote: > Since explicit is better than implicit, I *wouldn't* want to see > magical side affects where merely installing the database from PyPI, > or switching from Windows to Linux caused different behaviour. I think that would be a pain. What you're proposing means that Linux installations have to use the Python-installed copy by default (because you want them to do the same thing as on Windows), even though they have a perfectly good copy, often newer, of the database installed on the system. 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] Stdlib and timezones, again
On Mon, Oct 1, 2012 at 1:53 PM, Antoine Pitrou wrote: > Python 2.3 has been EOL'ed for years. It definitely is not up-to-date, > for any reasonable definition of the term. For example, it will have > many unplugged security holes. So will that user's version of OpenSSL > and other libraries. If they don't want to apply security fixes, why > should we even care about their timezones' freshness? > "Want to"? //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 Mon, Oct 1, 2012 at 5:23 PM, Antoine Pitrou wrote: > Python 2.3 has been EOL'ed for years. It definitely is not up-to-date, > for any reasonable definition of the term. For example, it will have > many unplugged security holes. So will that user's version of OpenSSL > and other libraries. If they don't want to apply security fixes, why > should we even care about their timezones' freshness? Exactly. If a service provider has a bug in their application because they're using an old timezone database, that is their problem, so long as *we* ensure there is a clear and obvious mechanism for upgrading *just* the TZ database, without upgrading Python itself. There's nothing forcing people to keep their installed version of pytz up to date, either. If a timezone database is bundled into the standard library, there are 3 clear mechanisms for encouraging the use of fresh TZ data: 1. Consider TZ database updates to be bug fixes, and thus include them in maintenance releases. This will keep the provided version reasonably fresh for Python versions that are still in maintenance mode. 2. Provide a mechanism to prefer the database from PyPI. 3. Provide a mechanism to prefer the OS database for platforms that provide an Olson compatible interface (I briefly looked into that for Windows a while back - it doesn't seem like a practical idea, since Microsoft went off and did their own thing. It works for Linux and other platforms that use the Olson database natively, though) Since explicit is better than implicit, I *wouldn't* want to see magical side affects where merely installing the database from PyPI, or switching from Windows to Linux caused different behaviour. However, it should be very easy for an application or environment to *explicitly request* the use of the pytz database or the OS database in preference to the bundled database. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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 Mon, Oct 1, 2012 at 7:54 AM, Antoine Pitrou wrote: > On Sun, 30 Sep 2012 21:49:20 -0400 > Brett Cannon wrote: > > > 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? > > The mako benchmark could manually exclude markupsafe from sys.modules. > That only addresses that specific benchmark, though) > Good point. Might be a good short term fix but it would be nice to have a solution to prevent similar issues in the future. ___ 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 Mon, Oct 1, 2012 at 3:44 AM, Maciej Fijalkowski wrote: > On Mon, Oct 1, 2012 at 1:12 AM, 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). > > > > Hi Brett. > > *If* you're talking about benchmarks, would be cool if you mention > that pypy is actually much faster on most of them. I will definitely mention that PyPy is actively working on Python 3 support and people should help out where they can (whether it be technical or financial) since PyPy will be faster than CPython in this regard and if you needed a good chance to switch interpreters this would be it. BTW, now that 3.3 is out is Antonio going to aim for 3.3 compatibility for the initial release or stay back on 3.2? > Also a very sad > fact is that a lot of actually interesting benchmarks don't work on > py3k (although a growing number). Twisted and sympy are very > informative for example > As soon as those projects are ported we can obviously add those benchmarks. ___ 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 21:49:20 -0400 Brett Cannon wrote: > > 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? The mako benchmark could manually exclude markupsafe from sys.modules. That only addresses that specific benchmark, though. 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 Mon, 1 Oct 2012 12:11:41 +0200 Lennart Regebro wrote: > On Mon, Oct 1, 2012 at 11:16 AM, Dirkjan Ochtman wrote: > > > On Mon, Oct 1, 2012 at 10:47 AM, Lennart Regebro > > wrote: > > > A year is no age for a Python installation. A customer of mine has one > > > website developed in 2003, still running on the same server. It runs > > Python > > > 2.3, I don't remember which version, but I'd be surprised if it is 2.3.7 > > > from 2008. > > > > Right. If they don't keep their Python up-to-date, why would they > > bother with their tzupdate? > > I'm sorry, is there a new releases of Python 2.3 made last year I don't > know about? Python 2.3 has been EOL'ed for years. It definitely is not up-to-date, for any reasonable definition of the term. For example, it will have many unplugged security holes. So will that user's version of OpenSSL and other libraries. If they don't want to apply security fixes, why should we even care about their timezones' freshness? 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 11:16 AM, Dirkjan Ochtman wrote: > On Mon, Oct 1, 2012 at 10:47 AM, Lennart Regebro > wrote: > > A year is no age for a Python installation. A customer of mine has one > > website developed in 2003, still running on the same server. It runs > Python > > 2.3, I don't remember which version, but I'd be surprised if it is 2.3.7 > > from 2008. > > Right. If they don't keep their Python up-to-date, why would they > bother with their tzupdate? > I'm sorry, is there a new releases of Python 2.3 made last year I don't know about? My point is that there is not much of a difference in the incentive > for upgrading your timezone data whether an initial version of it came > with Python or not. Incentive, no. But there is a difference in awareness and likelyhood. > Having to manually install it might make you > slightly more aware that it helps if you upgrade it once in a while, > but it seems more likely to be a fire and forget type of operation, in > which case it's basically the same as shipping a version of the > timezone data with Python (which is much easier, of course). > Well, me at least would include that package in the buildout or the instructions, etc. It is therefore much more likely to be updated if it is not included with Python. To put it crudely, you seem to think that most developers keep careful > track of what packages they need for their apps and actively assess > the risk for upgrading each of the packages involved. On the other > hand, I would assume more developers just get something working and > then fix any bugs that come up. > No, I assume there are developers of both types, and in between. If somebody just installed pytzdata and then doesn't upgrade it, fine, that's his problem. He doesn't become *more* likely to upgrade it because it's included in the standard library. But many developers are more likely to keep it updated and upgrade it if it is *not* included, at least once in a while. For example, if it's included in a buildout it could get updated when the buildout is re-run because some of the custom modules have been updated. While if it's included, it will never end up in the buildout and never get updated. //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 Mon, Oct 1, 2012 at 10:47 AM, Lennart Regebro wrote: > A year is no age for a Python installation. A customer of mine has one > website developed in 2003, still running on the same server. It runs Python > 2.3, I don't remember which version, but I'd be surprised if it is 2.3.7 > from 2008. Right. If they don't keep their Python up-to-date, why would they bother with their tzupdate? My point is that there is not much of a difference in the incentive for upgrading your timezone data whether an initial version of it came with Python or not. Having to manually install it might make you slightly more aware that it helps if you upgrade it once in a while, but it seems more likely to be a fire and forget type of operation, in which case it's basically the same as shipping a version of the timezone data with Python (which is much easier, of course). To put it crudely, you seem to think that most developers keep careful track of what packages they need for their apps and actively assess the risk for upgrading each of the packages involved. On the other hand, I would assume more developers just get something working and then fix any bugs that come up. 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] Stdlib and timezones, again
On Mon, Oct 1, 2012 at 10:28 AM, Dirkjan Ochtman wrote: > I think that would be a little too pure to be practical. There are > many practical usages of tz data that would work fine with a year-old > timezone database. > A year is no age for a Python installation. A customer of mine has one website developed in 2003, still running on the same server. It runs Python 2.3, I don't remember which version, but I'd be surprised if it is 2.3.7 from 2008. > Also, I > wonder if it would be possible to select the copy of the data that is > the most recent (e.g. on Unix, pick the OS version if tzupdate is > installed but older than the OS version). I don't think so. As far as I can tell, the data files contain no version information (only information on the version of the file format, which currently is 2). It also contains no information on what the name of the timezone is. This lack of information is unfortunate, but we'll have to live with it. The format hasn't changed since 1989, it is unlikely that we'll get anyone to change it anytime soon. //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 Mon, Oct 1, 2012 at 9:02 AM, Lennart Regebro wrote: > I don't want to default to a database that is guaranteed to be out of date. > I don't see the purpose. This is also why I'm skeptical at including the > data on Windows. I think that would be a little too pure to be practical. There are many practical usages of tz data that would work fine with a year-old timezone database. Personally, I'd want to not ship any tzdata with non-Windows Python packages on the assumption that they have good up-to-date OS tzdata (or it should be easy to disable it in the configure phase). Also, I wonder if it would be possible to select the copy of the data that is the most recent (e.g. on Unix, pick the OS version if tzupdate is installed but older than the OS version). 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] Benchmarking Python 3.3 against Python 2.7 (wide build)
On Mon, Oct 1, 2012 at 1:12 AM, 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). > Hi Brett. *If* you're talking about benchmarks, would be cool if you mention that pypy is actually much faster on most of them. Also a very sad fact is that a lot of actually interesting benchmarks don't work on py3k (although a growing number). Twisted and sympy are very informative for example ___ 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 Mon, Oct 1, 2012 at 7:07 AM, Robert Collins wrote: > 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/fijall%40gmail.com Timeit disables the GC for good measure (which is very bad IMO, but it was already discussed) ___ 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 1:24 AM, Christian Heimes wrote:
> 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.
>
I don't want to default to a database that is guaranteed to be out of date.
I don't see the purpose. This is also why I'm skeptical at including the
data on Windows.
//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
