Re: [Python-Dev] New Python Initialization API

> To make the API public, _PyWstrList, _PyInitError, _PyPreConfig, > _PyCoreConfig and related functions should be made public. Would you consider making _Py_UnixMain public as well? It is useful for high level embedding and not trivial for 3rd parties to reimplement.

Re: [Python-Dev] datetime.timedelta total_microseconds

> while "some_var / some_other_var" could be doing anything. "At an elementary level the division of two natural numbers is – among other possible interpretations – the process of calculating the number of times one number is contained within another one." --

Re: [Python-Dev] datetime.timedelta total_microseconds

On Fri, Feb 15, 2019 at 5:29 PM Paul Ganssle wrote: > it allows you to use non-traditional units like weeks (timedelta(days=7)) > Weeks are traditional: >>> timedelta(weeks=1) datetime.timedelta(7) :-) ___ Python-Dev mailing list

Re: [Python-Dev] datetime.timedelta total_microseconds

On Thu, Feb 14, 2019 at 9:07 AM Paul Ganssle wrote: > I don't think it's totally unreasonable to have other total_X() methods, > where X would be days, hours, minutes and microseconds > I do. I was against adding the total_seconds() method to begin with because the same effect can be achieved

Re: [Python-Dev] Return type of datetime subclasses added to timedelta

builtin, >>>>> and as such doesn't necessarily need to be categorized in this group), is >>>>> that unlike almost all other arithmetic types, *datetime* has a >>>>> special, dedicated type for describing differences in datetimes.

Re: [Python-Dev] Return type of datetime subclasses added to timedelta

On Wed, Jan 2, 2019 at 10:18 PM Paul Ganssle wrote: > .. the original objection was that this implementation assumes that the > datetime subclass has a constructor with the same (or a sufficiently > similar) signature as datetime. > While this was used as a possible rationale for the way

Re: [Python-Dev] Removal of install_misc command from distutils

feature back in Python 3.7.1? If yes, should it start to emit a deprection warning? > > Did you manage to workaround the removal? If yes, maybe we can add more doc to the Porting section of What's New in Python 3.7? > > Victor > > Le jeudi 5 juillet 2018, Alexander Belopolsky < alexan

Re: [Python-Dev] PEP 572: Do we really need a ":" in ":="?

On Thu, Jul 5, 2018 at 10:10 PM Tim Peters wrote: > .. > I solved the problem in my own code by using an editor that displays a > single "=" in C source as a left-arrow graphic (that's one of its > C-specific display options - again a response to how notorious this > bug-magnet is). So

Re: [Python-Dev] PEP 572: Do we really need a ":" in ":="?

On Thu, Jul 5, 2018 at 8:28 PM Tim Peters wrote: > [Alexander Belopolsky] > > ... > > I also think that the dreadfulness of mistyping = where == is expected > > is exaggerated. > > There are a number of core devs who would be rabidly opposed to allowing > that con

Re: [Python-Dev] PEP 572: Do we really need a ":" in ":="?

On Thu, Jul 5, 2018 at 7:47 PM Yury Selivanov wrote: > I think I tried a variation of your proposal here > https://mail.python.org/pipermail/python-dev/2018-April/152939.html > and nobody really liked it. > > Right. I now recall your proposal. I think I did not support it at the time because I

[Python-Dev] PEP 572: Do we really need a ":" in ":="?

I wish I had more time to make my case, but with the PEP 572 pronouncement imminent, let me make an attempt to save Python from having two assignment operators. I've re-read the PEP, and honestly I am warming up to the idea of allowing a limited form of assignment in expressions. It looks like

[Python-Dev] Removal of install_misc command from distutils

I started porting my project [1] to Python 3.7 and came across bpo-29218: "The unused distutils install_misc command has been removed." [2] Historically, the distutils package was very conservative about changes because many 3rd party packages extended it in ways unforeseen by the Python core

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

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

Re: [Python-Dev] The `for y in [x]` idiom in comprehensions

On Mon, Feb 26, 2018 at 7:51 PM, Guido van Rossum wrote: .. > The reason is that for people who are not Python experts there's no obvious > reason why `for VAR = EXPR` should mean one thing and `for VAR in EXPR` > should mean another. This would be particularly surprising for

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

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

[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.

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

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. >

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 >

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

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, >

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

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

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

Re: [Python-Dev] for...else

On Mon, Jul 24, 2017 at 12:23 PM, Ben Hoyt wrote: > .. I found a kind of mnemonic to help me remember when the > "else" part happens: I think of it not as "for ... else" but as "break ... > else" -- saying it this way makes it clear to me that the break goes with > the else.

Re: [Python-Dev] Impact of Namedtuple on startup time

On Mon, Jul 17, 2017 at 8:16 PM, Barry Warsaw wrote: > .. > > class Foo(NamedTuple, fields = 'x,y,z'): > > ... > > > > Then the name is explicit and you get to add methods > > etc. if you want. > > Yes, I like how that reads. > > I would prefer class

Re: [Python-Dev] Impact of Namedtuple on startup time

On Mon, Jul 17, 2017 at 6:27 PM, Greg Ewing wrote: > > > Maybe a metaclass could be used to make something > like this possible: > > >class Foo(NamedTuple, fields = 'x,y,z'): > ... > > If you think of it, collection.namedtuple *is* a metaclass. A simple

Re: [Python-Dev] Fwd: Re: Enum conversions in the stdlib

> I strongly prefer numeric order for signals. > > --Guido (mobile) +1 Numerical values of UNIX signals are often more widely known than their names. For example, every UNIX user knows what signal 9 does. ___ Python-Dev mailing list

Re: [Python-Dev] GDB macros in Misc/gdbinit are broken

On Tue, Feb 28, 2017 at 3:33 AM, Victor Stinner wrote: > > Alexander, Skip: Oh, which kind of issues do you have with > python-gdb.py? It doesn't work? You are unable to dump some data? First, I had to rename python-gdb.py to python3.6-gdb.py to make it load. Then

Re: [Python-Dev] GDB macros in Misc/gdbinit are broken

On Mon, Feb 27, 2017 at 7:34 PM, Victor Stinner wrote: > Does someone still need gdbinit macros for gdb without python binding? > I find them useful. I've never had success with python-gdb.py. ___ Python-Dev mailing list

[Python-Dev] GDB macros in Misc/gdbinit are broken

I have opened an issue on b.p.o., [1] but I wonder whether Misc/gdbinit is still supported in 3.6. [1]: http://bugs.python.org/issue29673 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

Re: [Python-Dev] "format" builtin function, docstring improvement

On Thu, Feb 9, 2017 at 1:18 PM, Hugo PROD HOMME wrote: > > I have made a template of the docstring to begin with, that I send as an attached file, but I am not familiar with docstring format. Please open an issue at bugs.python.org. We did something similar in issue

Re: [Python-Dev] Why is PyDateTimeAPI not initialized by datetime module import?

On Thu, Jan 26, 2017 at 11:00 AM, Skip Montanaro wrote: > I just got burned (wasted a good day or so) by the fact that PyDateTimeAPI > wasn't initialized. The datetime.rst doc states (emphasis mine): > > Before using any of these functions, the header file

Re: [Python-Dev] Adding bytes.frombuffer() constructor to PEP 467

On Fri, Jan 6, 2017 at 4:43 PM, Serhiy Storchaka wrote: > Compare these two calls: >> >> from array import array > bytes(array('h', [1, 2, 3])) > b'\x01\x00\x02\x00\x03\x00' >> >> and >> >> bytes(array('f', [1, 2, 3])) >

Re: [Python-Dev] Adding bytes.frombuffer() constructor to PEP 467

On Thu, Jan 5, 2017 at 5:54 PM, Serhiy Storchaka <storch...@gmail.com> wrote: > On 05.01.17 22:37, Alexander Belopolsky wrote: > >> I propose the following: >> >> 1. For 3.6, restore and document 3.5 behavior. Recommend that 3rd party >> types that are both in

Re: [Python-Dev] Adding bytes.frombuffer() constructor to PEP 467

On Wed, Oct 12, 2016 at 12:08 AM, INADA Naoki wrote: > > Now I'm sure about bytes.frombuffer() is worth enough. I would like to revive this thread (taking a liberty to shorten the subject line.) The issue of how the bytes(x) constructor should behave when given objects

Re: [Python-Dev] Missing PY_ prefixes in structmember.h

On Mon, Oct 3, 2016 at 1:11 PM, Skip Montanaro wrote: > Why didn't these flags > (and the T_* flags in structmember.h) get swept up in all the hubbub > around the grand renaming. > Note that structmember.h is semi-private - it is not included in Python.h. See

Re: [Python-Dev] C99

On Sat, Aug 6, 2016 at 5:55 PM, Sturla Molden wrote: > Either they install Xcode or they > don't get to build anything. I always thought "Command Line Tools" would be enough.

Re: [Python-Dev] Status of the Argument Clinic DSL

On Thu, Aug 4, 2016 at 7:12 PM, Larry Hastings wrote: > C extension functions get the module passed in automatically, but this is > done internally and from the Python level you can't see it. Always something new to learn! This was not so in Python 2.x - self was passed as

Re: [Python-Dev] Status of the Argument Clinic DSL

On Thu, Aug 4, 2016 at 7:00 PM, Brett Cannon wrote: >> >>> os.rename.__text_signature__ >> '($module, /, src, dst, *, src_dir_fd=None, dst_dir_fd=None)' >> >> ? >> >> What does the "$module, /," part mean? > > > Don't remember what the $module means but the / means

Re: [Python-Dev] Status of the Argument Clinic DSL

On Thu, Aug 4, 2016 at 2:19 PM, Larry Hastings wrote: > AFAIK the Clinic DSL can handle all of Python's C extensions. I have no > plans to "revise the whole approach"; if someone else does I haven't heard > about it. I was just wondering that with so much effort to bring

Re: [Python-Dev] Method signatures in the datetime module documentation

On Wed, Aug 3, 2016 at 10:41 PM, Martin Panter wrote: > If replace() actually supported these keywords all along, then I am happy > with this proposal. > With the obvious exception of "fold", it did at least since Python 3.0 (and likely since 2.x where x is 5 ± 1.) > There

[Python-Dev] Status of the Argument Clinic DSL

What is the current status of the Argument Clinic DSL? The clinic preprocessor was released [1] with Python 3.4 with a promise [2] "that signature metadata for programmatic introspection will be added to additional callables implemented in C as part of Python 3.4 maintenance releases." We are

Re: [Python-Dev] Method signatures in the datetime module documentation

On Fri, Jul 29, 2016 at 12:55 PM, Alexander Belopolsky <alexander.belopol...@gmail.com> wrote: > > How should I present the signature of the new replace method in the > documentation? Having not seeing any replies, let me make a proposal: datetime.replace(hour=self.hour, min

[Python-Dev] Method signatures in the datetime module documentation

I have started [1] writing documentation for the new PEP 495 (Local Time Disambiguation) features and ran into the following problem. The current documentation is rather inconsistent in presenting the method signatures. For example: date.replace(year, month, day) [2], but

Re: [Python-Dev] PEP 467: next round

On Mon, Jul 18, 2016 at 6:00 PM, Ethan Furman wrote: > bytes.fromsize() sounds good to me, thanks for brainstorming that one for > me. > +1 ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] PEP 467: next round

On Mon, Jul 18, 2016 at 5:01 PM, Jonathan Goble wrote: > full(), despite its use in numpy, is also unintuitive to me (my first > thought is that it would indicate whether an object has room for more > entries). > > Perhaps bytes.fillsize? > I wouldn't want to see

Re: [Python-Dev] PEP 467: next round

On Mon, Jul 18, 2016 at 4:17 PM, Ethan Furman wrote: > - 'bytes.zeros' renamed to 'bytes.size', with option byte filler > (defaults to b'\x00') > Seriously? You went from a numpy-friendly feature to something rather numpy-hostile. In numpy, ndarray.size is an attribute

Re: [Python-Dev] Status of Python 3.6 PEPs?

On Tue, Jul 12, 2016 at 4:26 AM, Victor Stinner <victor.stin...@gmail.com> wrote: > > "PEP 495 -- Local Time Disambiguation" > https://www.python.org/dev/peps/pep-0495/ > => accepted > > Alexander Belopolsky asked for a review of the implementation: > http

Re: [Python-Dev] PEP 495 implementation

for now. I will try to get the documentation patch ready before the beta, but I don't want to delay checking in the code. On Mon, Mar 21, 2016 at 10:34 PM, Alexander Belopolsky < alexander.belopol...@gmail.com> wrote: > > Dear All, > > I am getting close to completing PEP 495 imp

Re: [Python-Dev] Defining a path protocol

On Wed, Apr 6, 2016 at 2:32 PM, Brett Cannon wrote: > +1 for __path__, +0 for __fspath__ (I don't know how widespread the notion > that "fs" means "file system" is). Same here. In the good old days, "fs" stood for a "Font Server." And in even older (and better?) days, FS

Re: [Python-Dev] Counting references to Py_None

On Mon, Mar 21, 2016 at 5:56 PM, Tim Peters wrote: > I've seen this trigger, > from C code that had no idea it was playing with None, but just had > general refcounting errors. So this does serve a debugging purpose, > although rarely > You probably have a better

Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server)

On Sun, Dec 20, 2015 at 9:00 PM, Guido van Rossum wrote: > but I would really like to see a change in the repr of negative timedeltas: >> >> >>> timedelta(minutes=-1) >> datetime.timedelta(-1, 86340) >> >> And str() is not much better: >> >> >>> print(timedelta(minutes=-1)) >>

Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server)

On Sun, Dec 20, 2015 at 5:28 PM, Chris Angelico wrote: > > A helpful trivia: a year is approximately π times 10 million seconds. > > Sadly doesn't help here, as the timedelta for a number of years looks like > this: > > >>> datetime.timedelta(days=365*11) >

Re: [Python-Dev] Change the repr for datetime.timedelta (was Re: Asynchronous context manager in a typical network server)

On Sun, Dec 20, 2015 at 10:25 PM, Tim Peters wrote: > For > > >>> print(timedelta(minutes=-1)) > > I'd like to see: > > -00:01:00 > > But I wouldn't change repr() - the internal representation is fully > documented, and it's appropriate for repr() to reflect documented >

Re: [Python-Dev] Asynchronous context manager in a typical network server

On Fri, Dec 18, 2015 at 4:09 PM, Guido van Rossum wrote: > >> It's 11 days. Which is pretty reasonable server uptime. >> > > Oops, blame the repr() of datetime.timedelta. I'm sorry I so rashly > thought I could do better than the OP. > A helpful trivia: a year is approximately

[Python-Dev] PEP acceptance and SIGs

It has been my understanding that some PEPs may be discussed on specialized mailings lists, but a notice would be given on python-dev prior to any acceptance. I have recently received a notification that since PEP 470 has been accepted, I can no longer use external hosting for one of the packages

Re: [Python-Dev] PEP acceptance and SIGs

On Wed, Sep 30, 2015 at 8:32 PM, Donald Stufft wrote: > > I don’t see any requirement to post PEPs to python-dev if they have a Discussions-To header in PEP 1. When I faced a similar situation with PEP 495, Guido's advise was "I think that a courtesy message to python-dev is

Re: [Python-Dev] Committing a bug fix

On Mon, Sep 28, 2015 at 4:13 AM, Terry Reedy wrote: > Normal one specified in devguide: commit 3.4, merge 3.5, merge 3.6, That's exactly what I did at fist, but apparently while I was doing this, another commit was pushed to all three branches. To recover, I did a series of

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

[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 Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev

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

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

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

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

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

Re: [Python-Dev] PEP 495 accepted

There is no way any fromtimestamp() 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 co

Re: [Python-Dev] PEP 495 accepted

On Tue, Sep 22, 2015 at 10:55 AM, Alexander Belopolsky < alexander.belopol...@gmail.com> wrote: > On Tue, Sep 22, 2015 at 10:43 AM, Guido van Rossum <gu...@python.org> > wrote: > >> Based on the UTC/local diagram from the "Mind the Gap" section, am I >

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

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 == >>

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

On Sat, Aug 15, 2015 at 8:49 PM, Alexander Belopolsky < alexander.belopol...@gmail.com> 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 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

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

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

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 <v+pyt...@g.nevcal.com> 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 tha

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

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

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

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 <random...@fastmail.com> wrote: > Alexander Belopolsky <alexander.belopol...@gmail.com> writes: > > There is no "earlier" or "later". There are "lesser" and "greater" > > which are al

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

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

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

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

[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

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 gu...@python.org 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

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

On Mon, Jul 27, 2015 at 10:59 AM, Paul Moore p.f.mo...@gmail.com 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

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

On Mon, Jul 27, 2015 at 11:42 AM, Ryan Hiebert r...@ryanhiebert.com 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 transitions. You still have

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

On Mon, Jul 27, 2015 at 12:15 PM, Nikolaus Rath nikol...@rath.org wrote: On Jul 27 2015, Lennart Regebro rege...@gmail.com 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

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

On Mon, Jul 27, 2015 at 12:30 PM, Lennart Regebro rege...@gmail.com wrote: On Mon, Jul 27, 2015 at 6:15 PM, Nikolaus Rath nikol...@rath.org wrote: On Jul 27 2015, Lennart Regebro rege...@gmail.com wrote: (The *first* option) That you add one hour to it, and the datetime moves forward one

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

On Mon, Jul 27, 2015 at 5:13 PM, Tim Peters tim.pet...@gmail.com wrote: [Brett Cannon br...@python.org] \ 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

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

On Sun, Jul 26, 2015 at 11:33 AM, Nick Coghlan ncogh...@gmail.com 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

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

On Sun, Jul 26, 2015 at 11:39 AM, Berker Peksağ berker.pek...@gmail.com 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

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

On Sat, Jul 25, 2015 at 2:40 AM, Lennart Regebro rege...@gmail.com 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.

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

On Fri, Jul 24, 2015 at 9:39 PM, Tim Peters tim.pet...@gmail.com 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

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

On Thu, Jul 23, 2015 at 12:22 PM, Lennart Regebro rege...@gmail.com 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

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 p.f.mo...@gmail.com wrote: does anyone seriously think a core dev commits code as a joke??? Yes, https://hg.python.org/cpython/rev/0530aadff696. :-) ___ Python-Dev mailing list Python-Dev@python.org

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

On Tue, Apr 21, 2015 at 2:23 PM, Guido van Rossum gu...@python.org 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] 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 about other

  1   2   3   4   5   6   7   >