On Thu, Sep 19, 2013 at 10:54 PM, Ben Gift wrote:
> I think the lambda keyword is difficult to understand for many people. It
> would be more pythonic to use an empty def call instead.
I agree, but that ship has sailed, at least until the time when Python
2 is dead. I don't want these kinds of sy
Hi all!
If you wonder about the lack of progress reports on pep-431, this is
because of a lack of progress. I simply haven't had any time to work
on this. I considered make a kickstarter so I could take time off from
working, but to be honest, even with that, I still have no time to
realistically
On Wed, Oct 2, 2013 at 3:05 PM, Dirkjan Ochtman wrote:
> On Wed, Oct 2, 2013 at 2:17 PM, Lennart Regebro wrote:
>> If you wonder about the lack of progress reports on pep-431, this is
>> because of a lack of progress. I simply haven't had any time to work
>> on
That could be a possibility as well.
On Wed, Oct 2, 2013 at 6:14 PM, Stuart Bishop wrote:
> On Wed, Oct 2, 2013 at 9:42 PM, Lennart Regebro wrote:
>> On Wed, Oct 2, 2013 at 3:05 PM, Dirkjan Ochtman wrote:
>>> On Wed, Oct 2, 2013 at 2:17 PM, Lennart Regebro wrote:
>>&g
#x27;' prefix is the easiest, most
obvious/intuitive/pythong/whatever way of getting that support, that
requires the least amount of code change, and the least ugly code.
--
Lennart Regebro: http://regebro.wordpress.com/
Porting to Python 3:
On Tue, Feb 28, 2012 at 08:51, Vinay Sajip wrote:
> Lennart Regebro gmail.com> writes:
>
>> I'm +1 on the PEP, for reasons already repeated here.
>> We need three types of strings when supporting both Python 2 and
>> Python 3. A binary string, a unicode string
On Tue, Feb 28, 2012 at 13:10, Vinay Sajip wrote:
> We might be at cross purposes here. I don't see how Distribute helps, because
> the use case I'm talking about is not about distributing or installing stuff,
> but iteratively changing and testing code which needs to work on 2.6+, 3.2 and
> 3.3+.
All the various strategies for supporting Python 2 and Python 3 as
well as their various drawbacks and ways around this is covered in my
book, chapter 2. :-)
http://python3porting.com/strategies.html
I may be too late to point this out, but it feels like this discussion
could have been shorter if
On Tue, Feb 28, 2012 at 16:30, Giampaolo Rodolà wrote:
> Il 28 febbraio 2012 15:20, Ezio Melotti ha scritto:
>> (Note: there are also other costs -- e.g. releasing -- that I haven't
>> considered because they don't affect me personally, but I'm not sure they
>> are big enough to make the two-bran
On Tue, Feb 28, 2012 at 16:39, Vinay Sajip wrote:
> Serhiy Storchaka gmail.com> writes:
>
>> Another pertinent question: "What are disadvantages of PEP 414 is adopted?"
>
> It's moot, but as I see it: the purpose of PEP 414 is to facilitate a single
> codebase across 2.x and 3.x.
The bytes/nativ
On Tue, Feb 28, 2012 at 21:27, Ethan Furman wrote:
> Here's what I know:
>
> We don't add features to bug-fix releases.
> u'' is considered a feature.
> By not backporting to 3.1 and 3.2 we are not easing the migration pains from
> 2.x.
If this is added to 3.2.3, then some programs will work with
I also don't agree with the claim that a py3 version using 2to3 is a
"second class citizen". You need to adopt the Python 2 code to Python
3 in that case too, and none of the overrules the other.
//Lennart
___
Python-Dev mailing list
Python-Dev@python.or
Just my 2 cents on the PEP rewrite:
u'' support is not just if you want to write code that doesn't use
2to3. Even when you use 2to3 it is useful to be able to flag strings s
binary, unicode or "native".
//Lennart
___
Python-Dev mailing list
Python-Dev@p
On Fri, Mar 2, 2012 at 15:26, Serhiy Storchaka wrote:
> 02.03.12 15:49, Lennart Regebro написав(ла):
>
>> Just my 2 cents on the PEP rewrite:
>>
>> u'' support is not just if you want to write code that doesn't use
>> 2to3. Even when you use 2
On Sat, Mar 3, 2012 at 01:49, wrote:
>
> Zitat von Lennart Regebro :
>
>
>> Just my 2 cents on the PEP rewrite:
>>
>> u'' support is not just if you want to write code that doesn't use
>> 2to3. Even when you use 2to3 it is useful to be a
On Sat, Mar 3, 2012 at 04:22, Vinay Sajip wrote:
> It can also have some downsides, at least according to some points of view.
> For
> example, I regard elevating "native strings" to undue prominence, and the
> continued use of u'xxx' in Python 3 code, as unfortunate consequences. For
> example,
On Sat, Mar 3, 2012 at 10:26, Vinay Sajip wrote:
> Lennart Regebro gmail.com> writes:
>
>> So the question is if you have any proposal that is *less* confusing
>> while still being practical. Because we do need to distinguish between
>> binary, Unicode and "nativ
On Sat, Mar 3, 2012 at 11:39, Vinay Sajip wrote:
> Sorry, I didn't make myself clear. If you import unicode_literals, then in
> both
> 2.x and 3.x code, an unadorned literal string is text, and a b-adorned literal
> string is bytes. My assertion was based on that assumption - the text
> (Unicode
On Thu, Mar 8, 2012 at 08:46, Ethan Furman wrote:
> I think it would be sad to lose that functionality.
>
> If we are going to, though, we may as well check the string to make sure
> it's a valid identifier:
That would break even more code. I have encountered many cases of
attributes that aren't
On Wed, Mar 14, 2012 at 10:16, Antoine Pitrou wrote:
> That's a rather awful name. time.time() is *the* real time.
>
> time.monotonic(fallback=False) would be a better API.
I think calling the function "monotonic" isn't really a good name if
it's not always monotonic.
time.monotonic(fallback=
2012/3/14 Kristján Valur Jónsson :
>> - By default, it should fall back to time.time if a better source is
>> not available, but there should be a flag that can disable this
>> fallback for users who really *need* a monotonic/steady time source.
> As pointed out on a different thread, you don"t n
On Thu, Mar 15, 2012 at 02:58, Matt Joiner wrote:
> Victor, I think that steady can always be monotonic, there are time sources
> enough to ensure this on the platforms I am aware of. Strict in this sense
> refers to not being adjusted forward, i.e. CLOCK_MONOTONIC vs
> CLOCK_MONOTONIC_RAW.
>
> No
On Fri, Mar 16, 2012 at 05:55, Tres Seaver wrote:
> ExtensionClass and Acquisition would fit the bill, except they aren't
> ported to Python3 (Acquisition needs the headers from ExtensionClass).
And there were no plans to port them either, really. :-) Only Zope 2
uses them afaik? Or?
//Lennart
_
On Thu, Mar 22, 2012 at 00:39, Huan Do wrote:
> Tell me what you guys think.
I don't really want to add more things to the language, so I hate to say
this: It makes sense to me. However, the syntax is very close to the syntax
for function annotations. But that's when defining, and this is when
On Sat, Mar 24, 2012 at 00:36, Victor Stinner wrote:
>> This seems like it should have been a PEP, or maybe should become a PEP.
>
> I replaced time.wallclock() by time.steady(strict=False) and
> time.monotonic() by time.steady(strict=True). This change solved the
> naming issue of time.wallclock(
On Fri, Mar 23, 2012 at 10:51, Eli Bendersky wrote:
> The PEP received mostly positive feedback. The only undecided point is
> where to specify that the package is provisional. Currently the PEP
> mandates to specify it in the documentation and in the docstring.
> Other suggestions were to put it
On Mon, Mar 26, 2012 at 05:40, Eli Bendersky wrote:
> On Sat, Mar 24, 2012 at 13:53, Lennart Regebro wrote:
>> On Fri, Mar 23, 2012 at 10:51, Eli Bendersky wrote:
>>> The PEP received mostly positive feedback. The only undecided point is
>>> where to specify that
Reading this discussion, my conclusion is that not only us are
confused, but everyone is. I think therefore, that the way forward is
to only expose underlying API functions, and pretty much have no
intelligence at all.
At a higher level, we have two different "desires" here. You may want
a monoton
On Wed, Mar 28, 2012 at 12:56, Victor Stinner wrote:
> There is time.hires() if you need a monotonic clock with a fallback to
> the system clock.
Does this primarily give a high resolution clock, or primarily a
monotonic clock? That's not clear from either the name, or the PEP.
//Lennart
___
On Wed, Mar 28, 2012 at 23:40, Victor Stinner wrote:
>> Does this primarily give a high resolution clock, or primarily a
>> monotonic clock? That's not clear from either the name, or the PEP.
>
> I expect a better resolution from time.monotonic() than time.time().
Sure. And for me that means that
The overview of the different monotonic clocks was interesting,
because only one of them is adjusted by NTP, and that's the unix
CLOCK_MONOTONIC. Hence we don't need a raw=False flag, which I
previously suggested, we only need to not use CLOCK_MONOTONIC (which
the PEP psuedo-code indeed also does n
On Sat, Mar 31, 2012 at 02:26, Steven D'Aprano wrote:
> Guido van Rossum wrote:
>> If all else fails, I'd go with turnip.
>
> I can't tell if you are being serious or not.
>
> For the record, "turnip" in this sense is archaic slang for a thick pocket
> watch.
If I understand this correctly, the m
On Fri, Mar 30, 2012 at 12:38, Serhiy Storchaka wrote:
> I don't understand why Python may not include the pytz. The Olson tz
> database is not part of pytz.
Yes it is.
> Python can depend on a system tz database
That works on Unix, but not on Windows, where there is no Olsen database.
//Lenna
On Sat, Mar 31, 2012 at 12:28, Michael Foord wrote:
> *However*, doesn't Windows have its own system database?
Yeah, but it sucks.
> The problem is that in order to not include the olsen database, pytz
> would need to be modified to use the system database on Windows.
Quite a lot too, I'd guess
On Sat, Mar 31, 2012 at 21:20, Terry Reedy wrote:
> The Windows installer, by default, installs tcl/tk while Python on other
> systems uses the system install. Why can't we do the same for the Olson
> database?
The problem is that it needs updating.
We could include pytz, but it would be useless
On Sat, Mar 31, 2012 at 11:50, Nadeem Vawda wrote:
> Out of the big synonym list Guido posted, I rather like time.stopwatch() - it
> makes it more explicit that the purpose of the function is to measure
> intervals,
> rather identifying absolute points in time.
I guess it's the least bad.
//Len
I like the aim of letting the user control what clock it get, but I
find this API pretty horrible:
> clock = get_clock(T_MONOTONIC|T_HIRES) or get_clock(T_MONOTONIC)
Just my 2 groszy.
//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
http://
On Tue, Apr 3, 2012 at 08:03, Cameron Simpson wrote:
> clock = get_clock(MONOTONIC|HIRES) or get_clock(MONOTONIC)
>
> If the symbol names are not the horribleness, can you qualify what API
> you would like more?
Well, get_clock(monotonic=True, highres=True) would be a vast
improvement over get_c
On Tue, Apr 3, 2012 at 13:26, Victor Stinner wrote:
> Hi,
>
> I would to rename time.monotonic() to time.steady() in the PEP 418 for
> the following reasons:
>
> - time.steady() may fallback to the system clock which is not
> monotonic, it's strange to have to check for
> time.get_clock_info('mon
On Tue, Apr 3, 2012 at 23:14, Victor Stinner wrote:
>> Wait, what?
>> I already thought we, several days ago, decided that "steady" was a
>> *terrible* name, and that monotonic should *not* fall back to the
>> system clock.
>
> Copy of a more recent Guido's email:
> http://mail.python.org/pipermai
I am fine with the PEP as it is now (2012-04-04 15:34 GMT).
A question:
Since the only monotonic clock that can be adjusted by NTP is Linux'
CLOCK_MONOTONIC, if we avoid it, then time.monotonic() would always
give a clock that isn't adjusted by NTP. That would however mean we
wouldn't support mon
On Wed, Apr 4, 2012 at 13:04, Victor Stinner wrote:
> It depends if the option supports other values. But as I understood,
> the keyword value must always be True.
Or False, obviously. Which would also be default.
//Lennart
___
Python-Dev mailing list
On Tue, Apr 3, 2012 at 18:07, Ethan Furman wrote:
> What's unclear about returning None if no clocks match?
Nothing, but having to check error values on return functions are not
what you typically do in Python. Usually, Python functions that fail
raise an error. Please don't force Python users to
On Thu, Apr 5, 2012 at 00:45, Greg Ewing wrote:
> Lennart Regebro wrote:
>>
>> Since the only monotonic clock that can be adjusted by NTP is Linux'
>> CLOCK_MONOTONIC, if we avoid it, then time.monotonic() would always
>> give a clock that isn't adjusted by N
On Thu, Apr 5, 2012 at 01:10, Victor Stinner wrote:
> 2012/4/4 Lennart Regebro :
>> On Wed, Apr 4, 2012 at 13:04, Victor Stinner
>> wrote:
>>> It depends if the option supports other values. But as I understood,
>>> the keyword value must always be True.
>&
On Thu, Apr 5, 2012 at 12:32, Victor Stinner wrote:
> I prefer to use CLOCK_MONOTONIC, not because it is also available for
> older Linux kernels, but because it is more reliable. Even if the
> underlying clock source is unstable (unstable frequency), a delta of
> two reads of the CLOCK_MONOTONIC
On Fri, Apr 6, 2012 at 00:17, Cameron Simpson wrote:
> Gah! ALL functions are like that! How often do we see questions about
> max() or split() etc that a close reading of the docs obviate?
My point exactly.
//Lennart
___
Python-Dev mailing list
Python
On Fri, Apr 6, 2012 at 23:26, Ethan Furman wrote:
> Huh? Your point is that all APIs are less than ideal because you have to
> read the docs to know for certain how they work?
No.
//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
http://mail
On Sat, Apr 14, 2012 at 02:51, Victor Stinner wrote:
> Hi,
>
> Before posting a first draft of the PEP 418 to python-dev, I have some
> questions.
>
> == Naming: time.monotonic() or time.steady()? ==
The clock is monotonic by all reasonable definitions of monotonic (ie
they don't go backwards). T
Why do I get the feeling that most people who hate distutils and want
to replace it, has transferred those feelings to distutils2/packaging,
mainly because of the name?
In the end, I think this discussion is very similar to all previous
packaging/building/installing discussions: There is a lot of
On Sat, Jun 23, 2012 at 1:25 PM, Nick Coghlan wrote:
> If you think that, you haven't read the whole thread.
This is true, I kinda gave up early yesterday. It's good that it became better.
//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
htt
On Sun, Jul 15, 2012 at 1:28 AM, Alexandre Zani
wrote:
> I'm +1 on not having a public API for this. Ultimately the contract
> for a length hint will depend heavily upon what you need it for. Some
> applications would require a length hint to be an "at least" others an
> "at most" and others somet
Switched from python-dev to python-porting.
On Sun, Sep 2, 2012 at 9:48 PM, anatoly techtonik wrote:
> I work offline from remote location about 2000m above the sea level. There
> is no internet connection here, so I can not use tracker online. I need a
> Python editor here, and I have Spyder che
On Mon, Sep 3, 2012 at 10:18 PM, anatoly techtonik wrote:
> On Sun, Sep 2, 2012 at 11:26 PM, Lennart Regebro wrote:
>> Switched from python-dev to python-porting.
>>
>> On Sun, Sep 2, 2012 at 9:48 PM, anatoly techtonik
>> wrote:
>>> I work offline from remot
On Wed, Sep 12, 2012 at 9:02 PM, Éric Araujo wrote:
> “find a PEP dictator and propose changes”. And when I started the
> thread about removing packaging in 3.3, hundreds of replies discussed
> changing the whole distutils architecture, splitting the project,
> exploring new systems, etc.,
Yes,
With 3.3 out, it's time to bring up something for 3.4. And it's about pytz
and stdlib, basically. And we have been over that again, but I have a
proposal anyway.
The problem with including pytz in the stdlib is that it contains the
tz/zoneinfo/Olson database, and it updates much more often than Py
On Sep 30, 2012 10:34 PM, "Guido van Rossum" wrote:
>>
>> When people use pytz they have to reinstall pytz too if thet want to
benefit from the updates. (Or depend on automated updates via some vendor
package management system.) If we can ensure that with pytz in the stdlib,
updates to the Olson d
On Sun, Sep 30, 2012 at 11:28 PM, Serhiy Storchaka wrote:
> Why not use the system data which are updated by the OS? I know that
> Windows also changes the clock for local DST.
>
The Windows timezone information does not include any historical
information, as it's designed primarily to keep your
On Mon, Oct 1, 2012 at 12:17 AM, Matthias Klose wrote:
> > priority:
> > 1) api call supplying tz data to the process.
> > 2) pytzdata module if it exists
> > 3) tz data from the underlying operating system
> > 4) error.
>
> I disagree on this order, at least for Linux systems. the tzdata
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
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 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
> Py
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 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: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 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 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.
>
&g
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
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
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.
>>
>
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 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 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
On Thu, Oct 4, 2012 at 7:01 PM, Zachary Ware
wrote:
> It occurred to me this morning that Python already ships a set of
> timezone data with the Windows installer: Tcl/Tk's. Is there any way
> we could use that as the default on Windows?
We could, but it wouldn't solve any of the problems that n
This PEP is also available on github:
https://github.com/regebro/tz-pep/blob/master/pep-04tz.txt
Text:
PEP: 4??
Title: Time zone support improvements
Version: $Revision$
Last-Modified: $Date$
Author: Lennart Regebro
BDFL-Delegate: Barry Warsaw
Status: Draft
Type: Standards Track
Content-Type
General comments:
It seems like the consensus is moving towards making sure there always is a
database available. If this means including it in the standard Python
distribution as well, or only on Windows, I don't know, opinions on that are
welcome.
The steps to look for a database would then ch
On Wed, Dec 12, 2012 at 5:21 PM, Dirkjan Ochtman wrote:
> That entirely depends on when you define to be "the start". It seems
> to me the consensus on python-dev has been that packages primarily
> evolve outside the stdlib; it seems a bit weird to then, at the time
> of stdlib inclusion, start ch
On Wed, Dec 12, 2012 at 5:54 PM, Steve Dower wrote:
> Details of the registry entries are at
> http://msdn.microsoft.com/en-us/library/ms725481.aspx. It looks like the data
> is focused on modern timezones rather than localities, which would mean a
> many-to-one mapping from zoneinfo. Unfortuna
On Thu, Dec 13, 2012 at 12:23 AM, Terry Reedy wrote:
> As a Windows user, I would like there to be one tz data file used by all
> Python versions on my machine, including ones included with other apps.
That would be nice, but where would that be installed? There is no
standard location for zonein
On Thu, Dec 13, 2012 at 2:24 AM, Terry Reedy wrote:
> Or ask the user where to put it.
If we ask where it should be installed, then we need a registry
setting for that or we don't know where it's located when it is to be
used. And if we ask, then people will install it in non-standard
locations.
On Mon, Dec 10, 2012 at 8:22 AM, Antonio Cavallo
wrote:
> Hi,
> I wonder if is it worth/if there is any interest in trying to "clean" up
> distutils: nothing in terms to add new features, just a *major* cleanup
> retaining the exact same interface.
>
>
> I'm not planning anything like *adding feat
On Thu, Dec 13, 2012 at 9:22 AM, Terry Reedy wrote:
> On 12/13/2012 1:06 AM, Lennart Regebro wrote:
>> All in all I would say I would prefer to install this per Python.
>
> Then explicit update requires multiple downloads or copying. This is a
> violation of DRY. If if is not t
OK, so it's been 12 hours with no further discussion, so I'll make an
attempt to summarize what I think is the consensus changes before
updating the PEP.
1. Python will include a timezone database both in the source
distribution and the Windows installer (although I suspect that binary
packages fo
On Fri, Dec 14, 2012 at 9:49 AM, Antonio Cavallo
wrote:
> My requirements would quite simple:
> 2. cross compiling
That is *not* a simple requirement.
//Lennart
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/
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
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
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 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
On Sat, Dec 29, 2012 at 7:00 AM, Nick Coghlan wrote:
> 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:
&
On Sat, Dec 29, 2012 at 7:38 PM, Tres Seaver wrote:
> - -Lots for enabling fallback by default except on platforms known not to
> have their own database
Well, it's the same thing really. If the platform does have a database, the
fallback will not be used.
Of course, there is the case of the da
On Sat, Dec 29, 2012 at 7:54 PM, Lennart Regebro wrote:
> On Sat, Dec 29, 2012 at 7:38 PM, Tres Seaver wrote:
>
>> - -Lots for enabling fallback by default except on platforms known not to
>> have their own database
>
>
> Well, it's the same thing really. If t
On Sat, Dec 29, 2012 at 8:04 PM, Antoine Pitrou wrote:
> On Sat, 29 Dec 2012 19:56:43 +0100
> Lennart Regebro wrote:
> > On Sat, Dec 29, 2012 at 7:54 PM, Lennart Regebro
> wrote:
> >
> > > On Sat, Dec 29, 2012 at 7:38 PM, Tres Seaver >wrote:
> > &g
On Sat, Dec 29, 2012 at 11:55 PM, Cameron Simpson wrote:
> On 29Dec2012 21:16, Lennart Regebro wrote:
> | On Sat, Dec 29, 2012 at 8:04 PM, Antoine Pitrou
> wrote:
> | > Why should we care about that situation if we *do* provide a database?
> | > Distributions can decide
On Sat, Dec 29, 2012 at 11:59 PM, Terry Reedy wrote:
> On 12/29/2012 3:16 PM, Lennart Regebro wrote:
>
> Yes, but a comprehensible error message is useful even if somebody
>> messed up the system/configuration.
>>
>
> Just reuse whatever exception type you create
On Sun, Dec 30, 2012 at 11:19 AM, Steven D'Aprano wrote:
> If I've understood it correctly, that contradicts the PEP. One example
> given is "Etc/GMT+11", which is not a timezone *name*, but a timezone
> name *plus an offset*. Presumably if GMT+11 is legal, so should be
> GMT+10:30.
>
This depend
On Sun, Dec 30, 2012 at 10:47 AM, Ronald Oussoren wrote:
> The module could be split into several modules in a package without
> affecting the public API if that would help with maintenance, simular to
> unittest.
>
This is of course true. Maybe that is a good idea.
//Lennart
___
On Mon, Dec 31, 2012 at 2:40 PM, Brett Cannon wrote:
> Since this has happened for the second time in the past month, I want to
> prevent a trend from starting here. Please do not CC the peps mailing list
> on any discussions as it makes it impossible to know what emails are about
> an actual upd
On Sat, Dec 29, 2012 at 8:05 PM, Arfrever Frehtes Taifersar Arahesis <
arfrever@gmail.com> wrote:
> 2012-12-29 19:54:42 Lennart Regebro napisał(a):
> > On Sat, Dec 29, 2012 at 7:38 PM, Tres Seaver
> wrote:
> >
> > > - -Lots for enabling fallback by default e
On Sun, Dec 30, 2012 at 10:47 AM, Ronald Oussoren wrote:
> The module could be split into several modules in a package without
> affecting the public API if that would help with maintenance, simular to
> unittest.
>
Is there popular support for doing so, ie make datetime into a package,
have all
301 - 399 of 399 matches
Mail list logo
