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...
>
>
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.o
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 complain
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
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
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
>
>
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
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
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
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 inter
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/htt
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
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.
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 p
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
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
> s
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 a
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
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
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
-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
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 f
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 download
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 like
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 automati
-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
>
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)
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,
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 .i
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 over
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
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
_
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 up
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
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
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
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 no
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
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
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'v
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
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 librarie
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, ju
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
___
Py
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 st
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'
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
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 al
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/
__
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 li
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
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 (whic
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 wi
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
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 t
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 th
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.
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 ab
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 w
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, stil
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 rememb
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.
Ri
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
websi
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
man
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 unl
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/build
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 t
67 matches
Mail list logo
