Re: [Python-Dev] PEP 3121, 384 Refactoring Issues

On Thu, Jul 10, 2014 at 2:59 PM, Mark Lawrence wrote: > I'm just curious as to why there are 54 open issues after both of these > PEPs have been accepted and 384 is listed as finished. Did we hit some > unforeseen technical problem which stalled development? I tried to bring some sanity to tha

Re: [Python-Dev] PEP 3121, 384 Refactoring Issues

On Sat, Jul 12, 2014 at 11:19 AM, Nick Coghlan wrote: > The main downside of "do as we say, not as we do" in this case is that we > miss out on the feedback loop of what the stable ABI is like to *use*. I good start for improving the situation would be to convert the extension module templates

Re: [Python-Dev] PEP 3121, 384 Refactoring Issues

On Mon, Jul 14, 2014 at 11:41 AM, Brett Cannon wrote: > So maybe we should re-examine the patches and accept the bits that clean > up init/finalization and leave out any ABI-related changes. This is precisely what I suggested two years ago. http://bugs.python.org/issue15390#msg170249 I am not

Re: [Python-Dev] sum(...) limitation

On Sat, Aug 2, 2014 at 3:39 AM, Steven D'Aprano wrote: > String concatenation with + is an attractive > nuisance for many people, including some who actually know better but > nevertheless do it. Also, for reasons I don't understand, many people > dislike or cannot remember to use ''.join. > Sin

Re: [Python-Dev] sum(...) limitation

On Sat, Aug 2, 2014 at 11:06 AM, Stefan Behnel wrote: > I don't think sum(strings) is beautiful enough sum(strings) is more beautiful than ''.join(strings) in my view, but unfortunately it does not work even for lists because the initial value defaults to 0. sum(strings, '') and ''.join(string

Re: [Python-Dev] Surely "nullable" is a reasonable name?

On Mon, Aug 4, 2014 at 12:57 PM, Ethan Furman wrote: > 'allow_none' is definitely clearer. I disagree. Unlike "nullable", "allow_none" does not tell me what happens on the C side when I pass in None. If the receiving type is PyObject*, either NULL or Py_None is a valid choice.

Re: [Python-Dev] Surely "nullable" is a reasonable name?

On Mon, Aug 4, 2014 at 1:53 PM, Antoine Pitrou wrote: > I disagree. Unlike "nullable", "allow_none" does not tell me what >> happens on the C side when I pass in None. If the receiving type is >> PyObject*, either NULL or Py_None is a valid choice. >> > > But here the receiving type can be an in

Re: [Python-Dev] pathlib handling of trailing slash (Issue #21039)

On Wed, Aug 6, 2014 at 8:11 PM, Antoine Pitrou wrote: > Am I overlooking other cases? There are many interfaces where trailing slash is significant. For example, rsync uses trailing slash on the target directory to avoid creating an additional directory level at the destination. Loosing it wh

Re: [Python-Dev] pathlib handling of trailing slash (Issue #21039)

On Fri, Aug 8, 2014 at 8:27 AM, Paul Moore wrote: > I had a use case where I wanted to allow a config file to contain > "path: foo" to create a file called foo, and "path: foo/" to create a > directory. It was a shortcut for specifying an explicit "directory: > true" parameter as well. > Here is

Re: [Python-Dev] sum(...) limitation

On Fri, Aug 8, 2014 at 8:56 PM, Ethan Furman wrote: > I don't use sum at all, or at least very rarely, and it still irritates me. You are not alone. When I see sum([a, b, c]), I think it is a + b + c, but in Python it is 0 + a + b + c. If we had a "join" operator for strings that is different

Re: [Python-Dev] sum(...) limitation

On Sat, Aug 9, 2014 at 3:08 AM, Stephen J. Turnbull wrote: > All the suggestions > I've seen so far are (IMHO, YMMV) just as ugly as the present > situation. > What is ugly about allowing strings? CPython certainly has a way to to make sum(x, '') at least as efficient as y='';for in in x; y+= x

Re: [Python-Dev] sum(...) limitation

On Sat, Aug 9, 2014 at 2:02 PM, Alexander Belopolsky < [email protected]> wrote: > y='';for in in x; y+= x Should have been y='' for i in x; y += i ___ Python-Dev mailing list [email protected] ht

Re: [Python-Dev] sum(...) limitation

On Sat, Aug 9, 2014 at 1:08 AM, Steven D'Aprano wrote: > We wouldn't be having > these interminable arguments about using sum() to concatenate strings > (and lists, and tuples) if the & operator was used for concatenation and > + was only used for numeric addition. > But we would probably have a

Re: [Python-Dev] class Foo(object) vs class Foo: should be clearly explained in python 2 and 3 doc

On Sat, Aug 9, 2014 at 8:44 PM, Steven D'Aprano wrote: > It is certainly required when writing code that will behave the same in > version 2 and 3 > This is not true. An alternative is to put __metaclass__ = type at the top of your module to make all classes in your module new-style in python

Re: [Python-Dev] sum(...) limitation

On Mon, Aug 11, 2014 at 8:19 PM, Nick Coghlan wrote: > Teaching users the difference between linear time operations and quadratic > ones isn't about purity, it's about passing along a fundamental principle > of algorithm scalability. I would understand if this was done in reduce(operator.add, .

Re: [Python-Dev] Real-world use of Counter

On Wed, Nov 5, 2014 at 2:47 PM, R. David Murray wrote: > As I said on the issue, there is no reason I can see to add extra code > just to turn an AttributeError into a TypeError. The AttributeError > works just fine in letting you know your input type didn't work. > +1 Unlike ValueError or Loo

Re: [Python-Dev] PEP 479: Change StopIteration handling inside generators

On Wed, Nov 19, 2014 at 3:10 PM, Guido van Rossum wrote: > There's a new PEP proposing to change how to treat StopIteration bubbling > up out of a generator frame (not caused by a return from the frame). The > proposal is to replace such a StopIteration with a RuntimeError (chained to > the origi

Re: [Python-Dev] LTTng-UST support for CPython

On Mon, Dec 1, 2014 at 5:48 PM, Francis Giraldeau < [email protected]> wrote: > - On the C-API side: I did a horrible and silly function show_type() to > run every Py*_Check() to determine the type of a PyObject *. What would be > the sane way to do that? Questions like this are better

Re: [Python-Dev] datetime nanosecond support (ctd?)

On Tue, Dec 16, 2014 at 12:10 PM, matthieu bec wrote: > I wonder if the datetime module is really the right location, that has > constructor(year, month, day, ..., second, microsecond) - with 0 no millis. adding 0 quite right. We can make nanosecond a keyword-only argument, so that time(1, 2,

Re: [Python-Dev] Hi, I am new to this board and have a question

On Wed, Feb 4, 2015 at 6:18 PM, Jianhua Zhou wrote: > The necessary bits to build these optional modules were not found: > > _bz2 _lzma _ssl > > _tkinter zlib > > > > .. > > > > So what package name should I gave to download the additional source to >

Re: [Python-Dev] subclassing builtin data structures

On Thu, Feb 12, 2015 at 7:55 PM, Guido van Rossum wrote: > the problem is that the base class (e.g. int) doesn't know how to > construct an instance of the subclass -- there is no reason (in general) > why the signature of a subclass constructor should match the base class > constructor, and it o

Re: [Python-Dev] subclassing builtin data structures

On Thu, Feb 12, 2015 at 11:01 PM, Guido van Rossum wrote: > >> 2) always use the type of self when creating new instances >> .. >>cons: >> - if constructor signatures change, must override all methods which >>create new objects >> > > Con for #2 is a showstopper. Forget about

Re: [Python-Dev] subclassing builtin data structures

On Fri, Feb 13, 2015 at 12:35 PM, Guido van Rossum wrote: > IIUC you're proposing that the base class should *try* to construct an > instance of the subclass by calling the type with an argument, and fail if > it doesn't work. But that makes the whole thing brittle in the light of > changes to th

Re: [Python-Dev] subclassing builtin data structures

On Fri, Feb 13, 2015 at 1:11 PM, Guido van Rossum wrote: > > >> Note that the original pure python prototype of the datetime module had >> date.__add__ and friends call self.__class__(year, month, day). >> Unfortunately, it looks like the original sandbox did not survive the the >> hg conversion,

Re: [Python-Dev] subclassing builtin data structures

On Fri, Feb 13, 2015 at 1:19 PM, Alexander Belopolsky < [email protected]> wrote: >> >> FWIW you're wrong when you claim that "a constructor is no different from any other method". Someone else should probably explain this (it's an old a

Re: [Python-Dev] PEP 471 (scandir): Poll to choose the implementation (full C or C+Python)

On Fri, Feb 13, 2015 at 5:07 AM, Victor Stinner wrote: > Now I see 3 choices: > > - take the full C implementation, because it's much faster (at least > 3.4x faster!) > - reject the whole PEP 471 (not nice), because it adds too much code > for a minor speedup (not true on Windows: up to 44x faste

Re: [Python-Dev] subclassing builtin data structures

On Fri, Feb 13, 2015 at 4:44 PM, Neil Girdhar wrote: > Interesting: > http://stackoverflow.com/questions/5490824/should-constructors-comply-with-the-liskov-substitution-principle > Let me humbly conjecture that the people who wrote the top answers have background in less capable languages than P

Re: [Python-Dev] subclassing builtin data structures

On Sat, Feb 14, 2015 at 7:23 AM, Steven D'Aprano wrote: > Why can't int, str, list, tuple etc. be more like datetime? They are. In all these types, class methods call subclass constructors but instance methods don't. >>> class Int(int): ... pass ... >>> Int.from_bytes(bytes([1,2,3]), 'big

Re: [Python-Dev] subclassing builtin data structures

On Sat, Feb 14, 2015 at 2:36 PM, Georg Brandl wrote: > > In the case of int, there is a good reason for this behavior - bool. In > python, > > we want True + True == 2. In numpy, where binary operations preserve > > subclasses, you have > > > import numpy > numpy.bool_(1) + numpy.bool

Re: [Python-Dev] easy_install ?

ll-blown venv tree. > > > On Tue, Feb 24, 2015 at 4:21 PM, Alexander Belopolsky > wrote: > > > > On Tue, Feb 24, 2015 at 2:03 PM, Daniel Holth wrote: > >> > >> > Is there a recommended way to invoke pip from setup.py? When I specify > >> >

Re: [Python-Dev] Status on PEP-431 Timezones

On Wed, Apr 8, 2015 at 11:18 AM, Lennart Regebro wrote: > === Stdlib option 2: A datetime _is_dst flag === > > By having a flag on the datetime instance that says "this is in DST or not" > the timezone implementation can be kept simpler. > I floated this idea [1] back in the days when we discuss

Re: [Python-Dev] Aware datetime from naive local time Was: Status on PEP-431 Timezones

On Fri, Apr 10, 2015 at 6:38 AM, Nick Coghlan wrote: > It actually took me a long time to understand that the "isdst" flag in > this context related to the following chain of reasoning: > > 1. Due to various reasons, local time offsets relative to UTC may change, > thus repeating certain subsets

Re: [Python-Dev] Status on PEP-431 Timezones

On Fri, Apr 10, 2015 at 12:43 PM, Isaac Schwabacher wrote: > (and strptime doesn't even let you pass in a time zone) Not true: >>> datetime.strptime('-0400 EDT', '%z %Z') datetime.datetime(1900, 1, 1, 0, 0, tzinfo=datetime.timezone(datetime.timedelta(-1, 72000), 'EDT')) ___

Re: [Python-Dev] Status on PEP-431 Timezones

On Thu, Apr 9, 2015 at 11:59 AM, Isaac Schwabacher wrote: > > Storing isdst in the datetime object would allow utcoffset(dt) to > distinguish between 1:30AM before clock change and 1:30AM after. Where do > you propose to store the offset? > > I propose to add an offset field to datetime.datetime.

Re: [Python-Dev] Status on PEP-431 Timezones

On Wed, Apr 8, 2015 at 6:52 PM, Isaac Schwabacher wrote: > > > So "storing the offset" and "storing a flag" are not two alternative solutions to the same problem- these > > are two solutions to two different problems. > > I'm viewing a time zone as a map from UTC to local time; for example, Americ

Re: [Python-Dev] Status on PEP-431 Timezones

On Thu, Apr 9, 2015 at 3:07 PM, Isaac Schwabacher wrote: > > No, it does not. Please read the documentation: "self must be aware > (self.tzinfo must not be None, and self.utcoffset() must not return None)." > > Whoops, you're right. But that's even worse-- it doesn't give you a way to > convert a

Re: [Python-Dev] Status on PEP-431 Timezones

On Wed, Apr 8, 2015 at 8:11 PM, Alex Lord wrote: > Newb question time, what's BoF > http://en.wikipedia.org/wiki/Birds_of_a_feather_%28computing%29 ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Un

Re: [Python-Dev] Status on PEP-431 Timezones

On Thu, Apr 9, 2015 at 3:39 PM, Isaac Schwabacher wrote: > > Well, you are right, but at least we do have a localtime utility hidden > in the email package: > > > > > > >>> from datetime import * > > >>> from email.utils import localtime > > >>> print(localtime(datetime.now())) > > 2015-04-09 15:

Re: [Python-Dev] Status on PEP-431 Timezones

ats the same hour. So in order to know what 01:30 AM is in New York, you also need to know whether it is before we moved the clocks back or after. So "storing the offset" and "storing a flag" are not two alternative solutions to the same problem- these are two solutions to

Re: [Python-Dev] Status on PEP-431 Timezones

On Wed, Apr 8, 2015 at 7:32 PM, Chris Angelico wrote: > On Thu, Apr 9, 2015 at 8:32 AM, Alexander Belopolsky > wrote: > > A "named offset" is an abbreviation such as UTC, EST, MSK, MSD which (at > any > > given time) > > corresponds to a fixed offset from UT

Re: [Python-Dev] Status on PEP-431 Timezones

On Thu, Apr 9, 2015 at 11:59 AM, Isaac Schwabacher wrote: > I just looked through the datetime documentation, and it looks like the > currently blessed way of creating an aware datetime from a naive local > datetime and a tzinfo is datetime.replace, which is too low level to handle > the job. N

Re: [Python-Dev] Status on PEP-431 Timezones

On Thu, Apr 9, 2015 at 12:49 PM, Isaac Schwabacher wrote: > > if someone passed you datetime(2013, 11, 3, 1, 30) without a time zone. astimezone assumes that the input naive time is UTC, which is not the case here. No, it does not. Please read the documentation: "self must be aware (self.tzinfo

Re: [Python-Dev] Aware datetime from naive local time Was: Status on PEP-431 Timezones

On Mon, Apr 13, 2015 at 1:24 PM, Chris Barker wrote: > > >> Because of these discontinuities, an equation wall(loc, t) = lt may >> have 0, 1 >> or 2 solutions. >> > > This is where I'm confused -- I can see how going from "wall" time > ("local" time, etc) to UTC has 0, 1, or 2 solutions: > > On

Re: [Python-Dev] Aware datetime from naive local time Was: Status on PEP-431 Timezones

On Mon, Apr 13, 2015 at 2:05 PM, Chris Barker wrote: > However, different UTC times may map to the same wall time and some >> expressible wall times are not results of a map of any UTC time. >> > > got it. I suggest you perhaps word it something like: > > wall_time = f( location, utc_time) > > an

Re: [Python-Dev] Status on PEP-431 Timezones

On Wed, Apr 8, 2015 at 11:18 AM, Lennart Regebro wrote: > > I wrote PEP-431 two years ago, and never got around to implement it. > This year I got some renewed motivation after Berker Peksağ made an > effort of implementing it. > I'm planning to work more on this during the PyCon sprints, and also

Re: [Python-Dev] Aware datetime from naive local time Was: Status on PEP-431 Timezones

On Wed, Apr 15, 2015 at 4:46 PM, Akira Li <[email protected]> wrote: > > Look what happened on July 1, 1990. At 2 AM, the clocks in Ukraine were > > moved back one hour. So times like 01:30 AM happened twice there on that > > day. Let's see how Python handles this situation > > > > $ TZ=Europe

Re: [Python-Dev] Status on PEP-431 Timezones

On Wed, Apr 15, 2015 at 5:28 PM, Stuart Bishop wrote: > > On 15 April 2015 at 21:51, Lennart Regebro wrote: > > On Wed, Apr 15, 2015 at 3:23 PM, Stuart Bishop wrote: > > > Just punting it to tzinfo to make adjustments, ie effectively just > > doing what normalize() does creates infinite recursio

Re: [Python-Dev] Aware datetime from naive local time Was: Status on PEP-431 Timezones

On Fri, Apr 17, 2015 at 8:19 PM, Akira Li <[email protected]> wrote: > Can you demonstrate that email.utils.localtime does not behave as >> documented? >> > > > No need to be so defensive about it. > There is nothing "defensive" in my question. I simply don't understand what you are complaining

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

On Tue, Apr 21, 2015 at 2:23 PM, Guido van Rossum wrote: > At least nobody will be writing type hints in Cyrillic. :-) Why not? It works just fine: >>> Список = list >>> def sum(x: Список): ... pass ... >>> (See https://en.wikipedia.org/wiki/Rapira for some prior art.) _

Re: [Python-Dev] iso8601 parsing

On Tue, Oct 24, 2017 at 5:26 PM, Chris Barker wrote: > On Mon, Oct 23, 2017 at 5:33 PM, Hasan Diwan wrote: >> > can anyone argue that it's not a good idea for datetime ot > be able to read the iso format it puts out? No, but the last time I suggested that that datetime types should satisfy the s

Re: [Python-Dev] iso8601 parsing

> On Oct 25, 2017, at 11:45 AM, Alex Walters wrote: > > it means > the type of the first argument changes the semantic meaning of subsequent > arguments, and that just adds a level of confusion to any api. No, it does not. Passing a string a the first of three arguments will still be a type e

Re: [Python-Dev] iso8601 parsing

On Wed, Oct 25, 2017 at 3:48 PM, Alex Walters wrote: > Why make parsing ISO time special? It's not the ISO format per se that is special, but parsing of str(x). For all numeric types, int, float, complex and even fractions.Fraction, we have a roundtrip invariant T(str(x)) == x. Datetime types ar

Re: [Python-Dev] iso8601 parsing

On Wed, Oct 25, 2017 at 5:30 PM, Steven D'Aprano wrote: > Maybe I'm just being slow today, but I don't see how you can write > "generic code" to convert text to int/float/complex/Fraction, but not > times. The only difference is that instead of calling the type directly, > you call the appropriate

Re: [Python-Dev] iso8601 parsing

On Wed, Oct 25, 2017 at 5:30 PM, Chris Barker wrote: > Let's get passed the bike shedding and make this work! Sure. Submitting a pull request for would be a good start. ___ Python-Dev mailing list Python-Dev@python

Re: [Python-Dev] iso8601 parsing

On Wed, Nov 29, 2017 at 6:42 PM, Chris Barker wrote: > > indeed what is the holdup? I don't recall anyone saying it was a bad idea > in the last discussion. > > Do we just need an implementation? > > Is the one in the Bug Report not up to snuff? If not, then what's wrong > with it? This is just n

Re: [Python-Dev] iso8601 parsing

On Wed, Nov 29, 2017 at 7:18 PM, Mario Corchero wrote: > There were discussions about having it a function, making the constructor > of datetime accept a string(this was strongly rejected), having a static > function in datetime, etc... and there was no real agreement. > Guido has written severa

Re: [Python-Dev] iso8601 parsing

> is there a strict deadline here if we want this for Python 3.7? The deadline for the new features is the date of the first beta currently scheduled for 2018-01-29, but if you can get this in before the last alpha (2018-01-08) it will be best. See PEP 537 (https://www.python.org/dev/peps/pep-053

[Python-Dev] Unexpected bytecode difference

I have encountered the following difference between Python 3 and 2: (py3) >>> compile('xxx', '<>', 'eval').co_code b'e\x00S\x00' (py2) >>> compile('xxx', '<>', 'eval').co_code 'e\x00\x00S' Note that 'S' (the code for RETURN_VALUE) and a zero byte are swapped in Python 2 compared to Python 3. Is

Re: [Python-Dev] Unexpected bytecode difference

On Fri, Jan 19, 2018 at 7:01 PM, Guido van Rossum wrote: > Presumably because Python 3 switched to wordcode. Applying dis.dis() to > these code objects results in the same output. > dis.dis(c) > 0 LOAD_NAME 0 (0) > 3 RETURN_VALUE I expected these changes to be d

Re: [Python-Dev] Unexpected bytecode difference

On Fri, Jan 19, 2018 at 7:18 PM, Victor Stinner wrote: > It seems like the EXTENDED_ARG doc wasn't updated. I've opened to update the dis module documentation. I have also found a patch (mkfu4.patch) attached to issue 27095 where EXTENDED_ARG is described as

Re: [Python-Dev] Symmetry arguments for API expansion

On Mon, Mar 12, 2018 at 5:18 PM, Tim Peters wrote: > [Guido] >> as_integer_ratio() seems mostly cute (it has Tim Peters all >> over it), > > Nope! I had nothing to do with it. I would have been -0.5 on adding > it had I been aware at the time. > > - I expect the audience is tiny. The datet

Re: [Python-Dev] Dealing with tone in an email (was: Drop/deprecate Tkinter?)

On Fri, May 4, 2018 at 11:43 AM, Steven D'Aprano wrote: > On Thu, May 03, 2018 at 06:31:03PM +, Brett Cannon wrote: > .. > I'm not defending Ivan's initial email. His tantrum *was* annoying, > unreasonable, and unfair to those who do care about tkinter. He could > have done better. > > But *we

Re: [Python-Dev] How do we tell if we're helping or hindering the core development process? (was Re: How far to go with user-friendliness)

On Wed, Jul 22, 2015 at 7:09 AM, Paul Moore wrote: > does anyone seriously think a core dev > commits code as a joke??? > Yes, . :-) ___ Python-Dev mailing list [email protected] https://mail.python.o

Re: [Python-Dev] Status on PEP-431 Timezones

On Thu, Jul 23, 2015 at 12:22 PM, Lennart Regebro wrote: > It turns out it's very complex to solve this when internally storing > the time as the local time. Basically you have to normalize the time > (ie check if daylight savings have changed) when doing arithmetic, but > normalize is doing arit

Re: [Python-Dev] Status on PEP-431 Timezones

On Fri, Jul 24, 2015 at 9:39 PM, Tim Peters wrote: > > But IIUC what Lennart is complaining about > > I don't, and I wish he would be more explicit about what "the > problem(s)" is(are). > > > is the fact that the DST flag isn't part of and can't be embedded into a > local time, > > so it's impos

Re: [Python-Dev] Status on PEP-431 Timezones

On Sat, Jul 25, 2015 at 2:40 AM, Lennart Regebro wrote: > There really is a reason every other date time implementation I know > of uses UTC internally, and there really is a reason why everyone > always recommends storing date times in UTC with the time zone or > offset separately. > Current da

Re: [Python-Dev] Status on PEP-431 Timezones

On Sun, Jul 26, 2015 at 11:33 AM, Nick Coghlan wrote: > As a user, if the apparent semantics of time zone aware date time > arithmetic are accurately represented by "convert time to UTC -> > perform arithmetic -> convert back to stated timezone", then I *don't > care* how that is implemented inte

Re: [Python-Dev] Burning down the backlog.

On Sun, Jul 26, 2015 at 11:39 AM, Berker Peksağ wrote: > > I'm not actually clear what "Commit Review" status means. I did do a > > quick check of the dev guide, and couldn't come up with anything, > > https://docs.python.org/devguide/triaging.html#stage What is probably missing from the dev-gu

Re: [Python-Dev] Status on PEP-431 Timezones

On Mon, Jul 27, 2015 at 10:59 AM, Paul Moore wrote: > The semantic issue here is that users typically say "01:45" and > it never occurs to them to even think about *which* 01:45 they mean. > So recovering that extra information is hard (it's like dealing with > byte streams where the user didn't

Re: [Python-Dev] Status on PEP-431 Timezones

On Mon, Jul 27, 2015 at 11:42 AM, Ryan Hiebert wrote: > > On Jul 27, 2015, at 10:37 AM, Alexander Belopolsky < > [email protected]> wrote: > > > > On the other hand, these rare events are not that different from more or > less regular DST > > t

Re: [Python-Dev] Status on PEP-431 Timezones

On Mon, Jul 27, 2015 at 12:15 PM, Nikolaus Rath wrote: > On Jul 27 2015, Lennart Regebro wrote: > > That you add one hour to it, and the datetime moves forward one hour > > in actual time? That's doable, but during certain circumstance this > > may mean that you go from 1AM to 1AM, or from 1AM t

Re: [Python-Dev] Status on PEP-431 Timezones

On Mon, Jul 27, 2015 at 12:30 PM, Lennart Regebro wrote: > On Mon, Jul 27, 2015 at 6:15 PM, Nikolaus Rath wrote: > > On Jul 27 2015, Lennart Regebro wrote: > (The *first* option) > >> That you add one hour to it, and the datetime moves forward one hour > >> in actual time? That's doable, but d

Re: [Python-Dev] Status on PEP-431 Timezones

On Mon, Jul 27, 2015 at 5:13 PM, Tim Peters wrote: > [Brett Cannon ] > \> Alexander and Tim, you okay with moving this conversation to a > datetime-sig > > if we got one created? > > Fine by me! > +1 Didn't datetime-sig exist some 12 years ago? It would be nice to get some continuity from tha

Re: [Python-Dev] [Datetime-SIG] PEP 495 (Local Time Disambiguation) is ready for pronouncement

[Posted on Python-Dev] On Sun, Aug 16, 2015 at 3:23 PM, Guido van Rossum wrote: > I think that a courtesy message to python-dev is appropriate, with a link to > the PEP and an invitation to discuss its merits on datetime-sig. Per Gudo's advise, this is an invitation to join PEP 495 discussion on

[Python-Dev] PEP 495: What's left to resolve

The good news that other than a few editorial changes there is only one issue which keeps me from declaring PEP 495 complete. The bad news is that the remaining issue is subtle and while several solutions have been proposed, neither stands out as an obviously right. The Problem --- PEP 4

Re: [Python-Dev] PEP 498: Naming

On Tue, Sep 8, 2015 at 2:37 AM, Mike Miller wrote: > To my knowledge there was i for interpolation, t for template, and e for > expression suggested. Any better ideas? I believe someone suggested !"..." as well. I still think f"..." notation is the best as long as these elements are called "

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

On Tue, Sep 8, 2015 at 8:27 PM, Guido van Rossum wrote: > Now if only PEP 495 could be as easy... :-) > I think we nailed the hard issues there. The next update will have a restored hash invariant and == that satisfies all three axioms of equivalency. I am not making a better progress because

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

On Fri, Sep 11, 2015 at 6:45 PM, Terry Reedy wrote: > >> I think we nailed the hard issues there. The next update will have a >> restored hash invariant and == that satisfies all three axioms of >> equivalency. >> > > You are trying to sanely deal with politically mandated insanity. > I think i

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

On Fri, Sep 11, 2015 at 8:56 PM, Random832 wrote: > Alexander Belopolsky writes: > > There is no "earlier" or "later". There are "lesser" and "greater" > > which are already defined for all pairs of aware datetimes. PEP 495 > > doubl

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

On Fri, Sep 11, 2015 at 9:12 PM, Glenn Linderman wrote: [Alexander Belopolsky] > But the decision to allow interzone t - s was made long time ago and it is > a PEP 495 goal to change that. > > The last phrase, about it being a PEP 495 goal to change that, might be > true, but i

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

On Fri, Sep 11, 2015 at 9:12 PM, Glenn Linderman wrote: > That's what the politicians gave us. These are datetime objects, not > mathematical numbers. That's an argument for not defining mathematical operations like <, > or - on them, but you cannot deny the convenience of having those. Beside

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

On Fri, Sep 11, 2015 at 9:51 PM, Glenn Linderman wrote: > It wasn't intended to argue for not defining the operations, just intended > to justify that it is partial ordering... It is not even that. Note that even partial ordering still requires transitivity of <=, but we don't have that in dat

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

On Fri, Sep 11, 2015 at 10:00 PM, Random832 wrote: > > The current datetime rules, such as they are, as far as I am aware, > order all aware datetimes (except spring-forward) according to the UTC > moment they map to. No. See the library reference manual: "If both comparands are aware, and have

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

On Fri, Sep 11, 2015 at 10:00 PM, Random832 wrote: > And if EST and EDT are, against all rationality, distinct tzinfo values, > then when exactly can fold ever actually be 1, and why is it needed? > No, fold is not needed in the case of fixed offset timezones. For an obvious reason: there are n

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

On Fri, Sep 11, 2015 at 10:22 PM, Guido van Rossum wrote: > I think we're getting into python-ideas territory here... Well, a violation of transitivity of <= in the current CPython implementation may be considered a bug by some. This makes this discussion appropriate for python-dev. We could

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

On Fri, Sep 11, 2015 at 11:03 PM, Tim Peters wrote: > > then what exactly would a value landing near the > > "fall back" transition have given for fold? fold=1 but EDT? > > As above, pytz is in its own world here. It doesn't need `fold` > because it has its own hack for disambiguating local time

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

On Fri, Sep 11, 2015 at 11:07 PM, MRAB wrote: > What would happen if it's decided to stay on DST and then, later on, to > reintroduce DST? > No problem as long as you don't move the clock back x minutes and then decide that you did not move it back enough and move it again before x minutes have

Re: [Python-Dev] PEP 495 Was: PEP 498: Literal String Interpolation is ready for pronouncement

On Sat, Sep 12, 2015 at 1:20 AM, Terry Reedy wrote: > A mathematician has no problem with 'a'+'b' != 'b'+'a'. I doubt it. A binary operation denoted + (and called addition) is almost universally a commutative operation. A non-commutative binary operation is usually denoted * (and called mult

Re: [Python-Dev] PEP 495 (Local Time Disambiguation) is ready for pronouncement

On Sat, Aug 15, 2015 at 8:49 PM, Alexander Belopolsky < [email protected]> wrote: > > PEP 495 [1] is a deliberately minimalistic proposal to remove an > ambiguity in representing some local times as datetime.datetime > objects. A major issue has come up since my

Re: [Python-Dev] PEP 495 accepted

On Tue, Sep 22, 2015 at 3:01 AM, Nick Coghlan wrote: > ... for times that > don't exist, "dt.astimezone(utc).astimezone(dt.tzinfo)" will normalise > them to be a time that actually exists in the original time zone, and > that normalisation also effectively happens when calling > "dt.timestamp()".

Re: [Python-Dev] PEP 495 accepted

On Tue, Sep 22, 2015 at 10:43 AM, Guido van Rossum wrote: > Based on the UTC/local diagram from the "Mind the Gap" section, am I >> correct in thinking that the modified invariant that also covers times >> in a gap is: >> >> dt == >> datetime.fromtimestamp(dt.astimezone(utc).astimezone(dt.tzi

Re: [Python-Dev] PEP 495 accepted

On Tue, Sep 22, 2015 at 10:55 AM, Alexander Belopolsky < [email protected]> wrote: > On Tue, Sep 22, 2015 at 10:43 AM, Guido van Rossum > wrote: > >> Based on the UTC/local diagram from the "Mind the Gap" section, am I >>> correct in thinki

Re: [Python-Dev] PEP 495 accepted

mtimestamp() call can > return > >> a time in the gap. > > [Alexander Belopolsky] > > I don't think Nick said that. > > [Tim Peters] > I do, except that he didn't ;-) Count the parens carefully. > OK, it looks like Nick has managed to confuse both a

Re: [Python-Dev] PEP 495 accepted

On Tue, Sep 22, 2015 at 12:47 PM, Tim Peters wrote: > > I was just saying that in the specific, > complicated, contrived expression Nick presented, that it always > returns False (no matter which aware datetime he starts with) would be > more of a head-scratcher than if it raised a "can't compare

Re: [Python-Dev] PEP 495 accepted

On Tue, Sep 22, 2015 at 1:57 PM, Guido van Rossum wrote: > BTW, while the PEP doesn't spell this out, trichotomy can fail in some >> such cases (those where "==" would have returned True had it not been >> forced to return False - then "<" and ">" will also be False). >> >> In any case, nothing c

Re: [Python-Dev] PEP 495 accepted

On Tue, Sep 22, 2015 at 3:32 PM, Guido van Rossum wrote: > it is broken, due to the confusion about classic vs. timeline arithmetic > -- these have different needs but there's only one > operator. I feel silly trying to defend a design against its author. :-) Yes, a language with more than one

Re: [Python-Dev] PEP 495 accepted

On Tue, Sep 22, 2015 at 4:14 PM, Nathaniel Smith wrote: > Is there a good argument against at least deprecating inequality > comparisons and subtraction between mixed timezone datetimes? That's a wrong question. The right question is: "Is current behavior sufficiently broken to justify a backw

Re: [Python-Dev] PEP 495 accepted

> > [Tim Peters] > > > > > Guido's reply gave a clearer invariant: > > > > dt.timestamp() == > > dt.astimezone(utc).timestamp() == > > dt.astimezone().timestamp() > > [ Nick Coghlan] > Might it be worth mentioning Guido's invariant in the section of the PEP > about the timestamp method

[Python-Dev] Committing a bug fix

Can someone remind me which branches regular (non-security) bug fixes go to these days? See for context. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe

Re: [Python-Dev] Committing a bug fix

On Sun, Sep 27, 2015 at 9:12 PM, R. David Murray wrote: > .. > > 3.4, 3.5, and default. > > Thanks. Maybe you can help me to make hg cooperate. I made commits to 3.4, 3.5, and default and tried to push, but hg complains: remote has heads on branch '3.4' that are not known locally: 46aaff5e894

  1   2   3   4   5   6   7   >