Re: [Python-Dev] How far to go with user-friendliness

> By the way, I've also been bitten by this several times, so I > appreciate the desire to at least warn users (or raise an exception, or > whatever). It is not an intention to make tests more robust. It is the implementation, which is questionable at least. I actually still hope that the whole th

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 < alexander.belopol...@gmail.com> wrote: > y='';for in in x; y+= x Should have been y='' for i in x; y += i ___ Python-Dev mailing list Python-Dev@python.org 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 < francis.girald...@gmail.com> 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 < alexander.belopol...@gmail.com> 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] version of freshly built 2.7 python

Are you building from mercurial or a source tarball? On 4/2/2015 21:29, Ethan Furman wrote: I just built the latest version of Python 2.7 on my development machine -- or so I thought. When I invoke it, I get: Python 2.7.6+ (2.7:1beb3e0507fa, Apr 2 2015, 17:57:53) Why am I not seeing 2.7

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

repeating certain subsets of local time > 2. Repeated local times usually relate to winding clocks back an hour at > the end of a DST period > 3. "isdst=True" thus refers to "before the local time change winds the > clocks back", while "isdst=False" refers

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 Python-Dev@python.org 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] Keyword-only parameters

Lacking anything anyone else says... the use case for keyword only arguments (where they actually make the code better rather than simply being different) is rather limited. On 4/14/2015 13:40, Eric V. Smith wrote: I'm working on adding a numeric_owner parameter to some tarfile methods (http:

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 <4kir4...@gmail.com> 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 <4kir4...@gmail.com> 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

So. This is how you try and get me to care about Python 3. Can't speak for others, but this does the opposite for me. This makes me ecstatic that Python 2 has a nearly-frozen api. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python

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] Unicode literals in Python 2.7

does this not work for you? from __future__ import unicode_literals On 4/28/2015 16:20, Adam Bartoš wrote: Hello, is it possible to somehow tell Python 2.7 to compile a code entered in the interactive session with the flag PyCF_SOURCE_IS_UTF8 set? I'm considering adding support for Python 2

Re: [Python-Dev] PEP 492 vs. PEP 3152, new round

Out of curiosity, how much of a breaking change would making unary operators stack arbitrarily be? On 4/30/2015 23:57, Nathaniel Smith wrote: On Apr 30, 2015 8:40 PM, "Guido van Rossum" > wrote: > > On Thu, Apr 30, 2015 at 8:30 PM, Nathaniel Smith

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] 2.7 is here until 2020, please don't call it a waste.

Python is a giant cache-miss generator. A little performance boost on the opt-code dispatch isn't going to change that much. If we really do care about improving python to do less environmental damage, then that is a discussion we should be having on it's own merits. It was really out of pla

Re: [Python-Dev] 2.7 is here until 2020, please don't call it a waste.

n its own right. Otherwise it sounds like guilt-tripping and greenwashing. This patch will do little to nothing statistically significant for the environment. Bringing that up is ideology and politics. On 5/30/2015 04:55, Nick Coghlan wrote: On 30 May 2015 10:46, "Alexander Walters"

Re: [Python-Dev] Computed Goto dispatch for Python 2

A better course of action would be to deprecate the non-portable version. Other than setting the PATH envvar, why do we need to continue even touching the system on install? It is highly annoying for those of us that maintain several installs of python on a single windows system, and it reall

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 Python-Dev@python.org 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 < > alexander.belopol...@gmail.com> 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

Re: [Python-Dev] PEP-498: Literal String Formatting

Please do not change the meaning of the vestigial U''. It was re-added to the language to fix a problem, rebinding it to another meaning introduces new problems. We have plenty of other letters in the alphabet to use. On 8/8/2015 05:34, Nick Coghlan wrote: On 8 August 2015 at 11:39, Eric V.

Re: [Python-Dev] PEP-498: Literal String Formatting

t letter so that it just breaks in python 2, instead of having different meanings between versions. Python 2 is still the dominant python. On 8/8/2015 11:07, Nick Coghlan wrote: On 9 August 2015 at 00:05, Alexander Walters wrote: Please do not change the meaning of the vestigial U'&

Re: [Python-Dev] PEP-498: Literal String Formatting

Wait a second, the pep itself does not use the vestigial u''... it uses i''. where did u'' come from? On 8/8/2015 11:07, Nick Coghlan wrote: On 9 August 2015 at 00:05, Alexander Walters wrote: Please do not change the meaning of the vestigial U''.

Re: [Python-Dev] PEP-498: Literal String Formatting

at') isn't changed. On 8/8/2015 11:07, Nick Coghlan wrote: On 9 August 2015 at 00:05, Alexander Walters wrote: Please do not change the meaning of the vestigial U''. It was re-added to the language to fix a problem, rebinding it to another meaning introduces new problem

Re: [Python-Dev] PEP-498: Literal String Formatting

On 8/10/2015 01:29, Sven R. Kunze wrote: The best solution would be "without prefix and '{var}' only" syntax. Not sure if that is possible at all; I cannot remember using '{...}' anywhere else than for formatting. My JSON string literal 'test fixtures' weep at that idea. _

Re: [Python-Dev] PEP-498: Literal String Formatting

This may seam like a simplistic solution to i18n, but why not just add a method to string objects (assuming we implement f-strings) that just returns the original, unprocessed string. If the string was not an f-string, it just returns self. The gettext module can be modified, I think triviall

Re: [Python-Dev] PEP-498: Literal String Formatting

On 8/11/2015 11:16, Eric V. Smith wrote: On 08/11/2015 11:09 AM, Alexander Walters wrote: This may seam like a simplistic solution to i18n, but why not just add a method to string objects (assuming we implement f-strings) that just returns the original, unprocessed string. If the string was

Re: [Python-Dev] PEP needed for http://bugs.python.org/issue9232 ?

As a user who has banged my head against this more than once, its not a feature, its a bug, it does not need a pep (Guido said as much), just fix it. On 8/11/2015 11:31, Chris Barker - NOAA Federal wrote: there's been enough debate that I suspect we need a PEP. I think we might just need an

Re: [Python-Dev] PEP-498: Literal String Formatting

On 8/11/2015 11:28, Wes Turner wrote: On Aug 11, 2015 10:19 AM, "Wes Turner" > wrote: - [ ] review all string interpolation (for "injection") * [ ] review every '%' * [ ] review every ".format()" * [ ] review every f-string (AND LOCALS AND GLOBALS) * every

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

  1   2   3   4   5   6   7   8   >