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 Python-Dev@python.o

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 wi

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

>>>>> and builtins (other than the fact that datetime is *not* a 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 >>>>> sp

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 standard

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

ture 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 < a

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 assignmen

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 w

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

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

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] 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] 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 people exposed to Ju

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

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

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

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, 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, 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 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 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 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] 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. "If this condition ins

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 Foo(metaclass=namedtuple, fields = 'x

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 wrapper will make it usable as su

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 Python-Dev@pyth

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 running backtrace gave me a bu

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@python.org https://

[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 #9650, [1] so I think this wi

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 :file:`datetime.h` > must be included in

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])) > b'\x00\x00\x80?\x00\x00\x00@\x00\x00@@' >> > > I don't

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

On Thu, Jan 5, 2017 at 5:54 PM, Serhiy Storchaka 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 integer-like and b

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 of various types have come

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 discussion at

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. https://developer.apple.com/library/ios/technotes/tn2339/_index.html#//apple_ref/doc/uid/DTS40014588-CH1-WHAT_IS_THE_COMM

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 NULL to the C module

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 positional-only > arguments. No

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 typing to the mainstre

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 are a few bug reports

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

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

On Fri, Jul 29, 2016 at 12:55 PM, Alexander Belopolsky 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, minute=self.minute, second=self.second, mi

[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 datetime.replace([year[

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 https://mail.python.org/mailman/listinfo/python-dev Unsubscrib

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 bytes.full() either. Maybe byte

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 that returns the number

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

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

Re: [Python-Dev] PEP 495 implementation

n 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 P

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 was a "Field Separato

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 refcounting sense that I do, bu

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 > internals as directly as

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)) >> -1 day, 23:59:00 >>

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) > datetime.timedelta(4015) > > The origin

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 π times 10 million

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 appropriate, with a

[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] 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 hg update 3.x; hg

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

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

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

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

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

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 10:55 AM, Alexander Belopolsky < alexander.belopol...@gmail.com> 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

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 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 (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 * (and called mult

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 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 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 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: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 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 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: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 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 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 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 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 "

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

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] 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 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 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 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] 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 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] 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 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 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] 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] 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.) _

  1   2   3   4   5   6   7   >