On Sat, Dec 29, 2012 at 6:23 AM, Lennart Regebro wrote:
> Happy Holidays! Here is the update of PEP 431 with the changes that emerged
> after the earlier discussion.
>
> A raw download is here:
> https://raw.github.com/regebro/tz-pep/master/pep-04tz.txt
For UI purposes, "pytz" has some helpers to
2012/12/28 Lennart Regebro :
> It will make the datetime.py twice as long though, and the second longest
> module in the stdlib, beaten only by decimal.py. Perhaps this is not a
> problem.
No one ever accused datetime manipulation of being simple.
--
Regards,
Benjamin
__
On Fri, Dec 28, 2012 at 10:12 PM, Ronald Oussoren wrote:
>
> On 28 Dec, 2012, at 21:23, Lennart Regebro wrote:
>
> > Happy Holidays! Here is the update of PEP 431 with the changes that
> emerged after the earlier discussion.
>
> Why is the new timezone support added in a submodule of datetime?
On Sat, Dec 29, 2012 at 2:23 AM, Steven D'Aprano wrote:
> The PEP says:
>
> * New function :``timezone(name=None, db_path=None)``
>
>
> This function takes a name string that must be a string specifying a
> valid zoneinfo timezone, ie "US/Eastern", "Europe/Warsaw" or
> "Etc/GMT+11".
>
>
> It i
On 29/12/12 05:02, Lennart Regebro wrote:
On Thu, Dec 20, 2012 at 5:43 PM, Barry Warsaw wrote:
That would be `class UnknownTimeZoneError(ValueError, TimeZoneError)`.
As of today, in Pytz, UnknownTimeZoneError in fact subclasses KeyError.
Any opinions against that?
The PEP says:
* New
In article <9e6e3321-b0e7-4e77-afcb-9c7855649...@barrys-emacs.org>,
Barry Scott wrote:
> You did not set PYTHONHOME that effects the code in calculate_path a lot.
> Also there is platform specific code in tht code.
> On 28 Dec 2012, at 22:30, Antoine Pitrou wrote:
> > On Fri, 28 Dec 2012 21:39:5
There's the distutil mailing list:
http://mail.python.org/mailman/listinfo/distutils-sig
Doug Hellmann wrote:
A couple of us from the OpenStack project are interested in getting involved in
the packaging rewrite/update project. I was following that work for a while,
but have lost track of i
You did not set PYTHONHOME that effects the code in calculate_path a lot.
Also there is platform specific code in tht code.
Barry
On 28 Dec 2012, at 22:30, Antoine Pitrou wrote:
> On Fri, 28 Dec 2012 21:39:56 +
> Barry Scott wrote:
>> I'm trying to track down why bundlebuilder no longer w
A couple of us from the OpenStack project are interested in getting involved in
the packaging rewrite/update project. I was following that work for a while,
but have lost track of its current state. Can someone point me to the right
mailing list, and maybe a status page or something so I can sta
On Fri, 28 Dec 2012 21:39:56 +
Barry Scott wrote:
> I'm trying to track down why bundlebuilder no longer works with python 2.7
> to create runnable Mac OS X apps.
>
> I have got as far as seeing that imports of modules are failing.
>
> What I see is that sys.path does not contain all the ele
I'm trying to track down why bundlebuilder no longer works with python 2.7
to create runnable Mac OS X apps.
I have got as far as seeing that imports of modules are failing.
What I see is that sys.path does not contain all the elements from the
PYTHONPATH variable.
No matter what I put in PYTHON
On Fri, 28 Dec 2012 14:54:55 -0500
Terry Reedy wrote:
>
> 4. Running ./python_d from within a PCBuild/python_d interactive window
> and on a regular disk averages .10 seconds. The slowdown is probably a
> mixture of disk access and extra debug code, but is not bad. There is no
> flashing (prob
On 28 Dec, 2012, at 21:23, Lennart Regebro wrote:
> Happy Holidays! Here is the update of PEP 431 with the changes that emerged
> after the earlier discussion.
Why is the new timezone support added in a submodule of datetime? Adding the
new
function and exception to datetime itself wouldn't
Happy Holidays! Here is the update of PEP 431 with the changes that emerged
after the earlier discussion.
A raw download is here:
https://raw.github.com/regebro/tz-pep/master/pep-04tz.txt
PEP: 431
Title: Time zone support improvements
Version: $Revision$
Last-Modified: $Date$
Author: Lennart Rege
On 12/28/2012 1:02 PM, Lennart Regebro wrote:
On Thu, Dec 20, 2012 at 5:43 PM, Barry Warsaw mailto:ba...@python.org>> wrote:
That would be `class UnknownTimeZoneError(ValueError, TimeZoneError)`.
As of today, in Pytz, UnknownTimeZoneError in fact subclasses KeyError.
Any opinions against
On Dec 28, 2012, at 07:02 PM, Lennart Regebro wrote:
>On Thu, Dec 20, 2012 at 5:43 PM, Barry Warsaw wrote:
>
>>
>> That would be `class UnknownTimeZoneError(ValueError, TimeZoneError)`.
>>
>
>As of today, in Pytz, UnknownTimeZoneError in fact subclasses KeyError. Any
>opinions against that? The
On Thu, Dec 20, 2012 at 5:43 PM, Barry Warsaw wrote:
>
> That would be `class UnknownTimeZoneError(ValueError, TimeZoneError)`.
>
As of today, in Pytz, UnknownTimeZoneError in fact subclasses KeyError.
Any opinions against that?
There is no TimeZoneError today, and it would only be used for thi
ACTIVITY SUMMARY (2012-12-21 - 2012-12-28)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open3834 (-10)
closed 24745 (+68)
total 28579 (+58)
Open issues wit
18 matches
Mail list logo
