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

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

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

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

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

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

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

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

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

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

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

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

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

On Sat, Aug 15, 2015 at 8:49 PM, Alexander Belopolsky < 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 accepted

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

Re: [Python-Dev] PEP 495 accepted

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

Re: [Python-Dev] PEP 495 accepted

On Tue, Sep 22, 2015 at 10:55 AM, Alexander Belopolsky < 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

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

Re: [Python-Dev] PEP 495 accepted

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

Re: [Python-Dev] PEP 495 accepted

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

Re: [Python-Dev] PEP 495 accepted

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

Re: [Python-Dev] PEP 495 accepted

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

Re: [Python-Dev] PEP 495 accepted

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

[Python-Dev] Committing a bug fix

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

Re: [Python-Dev] Committing a bug fix

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

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

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

Re: [Python-Dev] Should PEP 498 specify if rf'...' is valid?

Have you ever used a command line application that --accepted --Boolean --flags? Have you ever found one that required the flags to be in order? You remember how much you hated that application for being so arbitrary about the input? That is exactly how I feel about the order mattering for

[Python-Dev] collections.Counter __add__ implementation quirk

collections.Counter.__add__ as a bit of a quirk. Counters allow for negative numbers. You can subtract from a counter into the negative no problem. However, if you have a counter with a negative value and add it to another counter, and if that value, after addition, would still be negative..

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] 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] 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 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] Building with VS2015

This is a mailing list for the development of python itself, not support for building it. That said... 3.4 uses visual studio 2010, for starters. 3.5 uses 2015. It also looks like you have a lot of missing dependencies. On 1/12/2016 21:55, Eddy Quicksall wrote: I downloaded https://www.pyt

Re: [Python-Dev] Update PEP 7 to require curly braces in C

On 1/18/2016 23:27, Greg Ewing wrote: Brett Cannon wrote: For me, I don't see how:: if (x != 10) return NULL; do_some_more(); is any clearer or more readable than:: if (x != 10) { return NULL; } do_some_more(); Maybe not for that piece of code on its own, but the version

Re: [Python-Dev] Update PEP 7 to require curly braces in C

On 1/19/2016 00:09, Greg Ewing wrote: Alexander Walters wrote: When someone trying to make this argument in #python for Python code... the response is newlines are free. Well, I disagree. I very rarely put blank lines in a function in any language, because it makes it hard to scan the code

Re: [Python-Dev] Update PEP 7 to require curly braces in C

On 1/19/2016 01:04, Glenn Linderman wrote: On 1/18/2016 9:16 PM, Greg Ewing wrote: Alexander Walters wrote: I am not a core developer, but I just kind of feel its hypocritical to oppose always using brackets for the development of *python* If we were being *really* pythonic, we would write

Re: [Python-Dev] Update PEP 7 to require curly braces in C

On 1/19/2016 02:21, Larry Hastings wrote: On 01/18/2016 08:40 PM, Alexander Walters wrote: I am not a core developer, but I just kind of feel its hypocritical to oppose always using brackets for the development of *python* CPython isn't written in Python, it's written in C. S

Re: [Python-Dev] Python environment registration in the Windows Registry

...just when I thought I have solved the registry headaches I have been dealing with... I am not saying this proposal will make the registry situation worse, but it may break my solution to the headaches Python's registry use causes with some non-standard module installers (and even the standa

Re: [Python-Dev] Python environment registration in the Windows Registry

On 2/3/2016 11:17, Steve Dower wrote: I know for PTVS manually adding a python environment to visual studio is trivial - you fill in three locations, and its done. Just today I added a python environment to my system that was not autodetected. It took under a minute and almost no effort to ad

Re: [Python-Dev] Python environment registration in the Windows Registry

do not include all of pywin32, and wxpython) and perhaps more. On 2/3/2016 14:32, Matthew Einhorn wrote: On Wed, Feb 3, 2016 at 3:15 AM, Alexander Walters mailto:tritium-l...@sdamon.com>> wrote: ...just when I thought I have solved the registry headaches I have been dealin

Re: [Python-Dev] More optimisation ideas

On 2/5/2016 12:27, Emile van Sebille wrote: On 2/1/2016 9:20 AM, Ethan Furman wrote: On 02/01/2016 08:40 AM, R. David Murray wrote: On the other hand, if the distros go the way Nick has (I think) been advocating, and have a separate 'system python for system scripts' that is independent of

Re: [Python-Dev] Windows: Remove support of bytes filenames in the os module?

On 2/8/2016 12:02, Brett Cannon wrote: If Unicode string don't work in Python 2 then what is Python 2/3 to do as a cross-platform solution if we completely remove bytes support in Python 3? Wouldn't that mean there is no common type between Python 2 & 3 that one can use which will work wit

Re: [Python-Dev] HackIllinois 2016 + Python

Hello. You might want to post this in the psf-community list too. There are a lot of open source developers in the community they are not working directly on CPython (what this list is about). On 2/8/2016 12:19, Kevin Hong wrote: Hi all! My name is Kevin and I am a staff member of HackIllino

Re: [Python-Dev] Issue #26204: compiler now emits a SyntaxWarning on constant statement

I am not keen on a SyntaxWarning. Either something is python syntax, or it is not. This warning catches something linters have been catching for ages. I really don't see the value in adding this, and can see it causing more confusion than it solves. In the #python irc channel, we see quite

Re: [Python-Dev] Issue #26204: compiler now emits a SyntaxWarning on constant statement

led, falling back to readline >>> assert True >>> On 2/8/2016 16:23, Victor Stinner wrote: Le 8 févr. 2016 9:10 PM, "Alexander Walters" <mailto:tritium-l...@sdamon.com>> a écrit : > > I am not keen on a SyntaxWarning. Either something is python syn

Re: [Python-Dev] Issue #26204: compiler now emits a SyntaxWarning on constant statement

On 2/8/2016 16:37, John Mark Vandenberg wrote: fwiw, pyflakes doesnt detect this. I've created a bug for that https://bugs.launchpad.net/pyflakes/+bug/1543246 Flake8 does, so it might be in the ... poorly named ... pep8 checker. ___ Python-Dev mai

[Python-Dev] Thank you.

I don't know if it is appropriate for this list, or not. I don't exactly care. As much as I might disagree with some of you... Thank you. Your work on Python has made a notable difference in how happy my life is. ___ Python-Dev mailing list Python-D

Re: [Python-Dev] Python should be easily compilable on Windows with MinGW

No. Visual Studio is a solid compiler suit, mingw is a jenky mess, especially when you try and move to 64bit (where I don't think there is one true version of mingw). I'm sorry that Visual Studio makes it very hard for you to contribute, but changing THE compiler of the distribution from the

Re: [Python-Dev] Python should be easily compilable on Windows with MinGW

both visual studio and mingw. That is, there probably should be two builds on windows, since there's no clear consensus about which to use. I certainly prefer mingw over visual studio - and I have adequate bandwidth for either. On Fri, Feb 26, 2016 at 9:55 AM, Alexander Walters wrote

Re: [Python-Dev] Python should be easily compilable on Windows with MinGW

2016 at 1:10 PM, Alexander Walters wrote: Ok, fine. Bring a windows build bot online. And also take on the support burden of guiding people to which version of which compiler you use for each of the currently supported python versions. And go ahead and write the pep to change how wheel distribu

Re: [Python-Dev] Python should be easily compilable on Windows with MinGW

The 9 gig initial download is not the only problem. Visual studio is very bandwidth hungry in day to day operations (between polling websites and vcs remotes, near constant updating, integration with the VS web service, etc.). You can of course shut all of that off, but it's a pain. It's my

Re: [Python-Dev] Python should be easily compilable on Windows with MinGW

that would be a good intermediate solution if it’s possible. [1]: https://www.microsoft.com/en-us/download/details.aspx?id=49983 – Chris On February 27, 2016 at 4:36:54 PM, Alexander Walters (tritium-l...@sdamon.com <mailto:tritium-l...@sdamon.com>) wrote: The 9 gig initial download

Re: [Python-Dev] Very old git mirror under github user "python-git"

Can we even ask github to pull it down and reasonably expect them to comply? Their entire model is built on everyone forking everyone else. On 2/27/2016 06:25, Mathieu Dupuy wrote: Ahah. Obtaining his electronic coordinates like email to gently ask him to pull it down by himself (otherwise we

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] When should pathlib stop being provisional?

On 4/5/2016 18:55, Guido van Rossum wrote: My last/only comment in the discussion was about there possibly being a dichotomy between people who use Python for scripting and those who use it to write more substantial programs (I'm trying not to judge one group more important than another -- I'm

Re: [Python-Dev] When should pathlib stop being provisional?

On 4/5/2016 22:44, Nick Coghlan wrote: Option 4: define a rich-object-to-text path serialisation convention, as paths are not conceptually the same as arbitrary strings Just as a nit to pick, it is perfectly acceptable for hypothetical path objects to raise when someone tries to shoehorn them in

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

[Python-Dev] Maybe, just maybe, pathlib doesn't belong.

In reviewing the ongoing arguments about how to make pathlib better, there have been circular arguments about if it is even broken, if it should support bytes, if there should be a path protocol that all functions that touch the filesystem should use, if that protocol should support bytes, how

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

to implement one of them? If not, we should consider either dropping the matter or dropping the module. On 4/11/2016 16:48, Sven R. Kunze wrote: On 11.04.2016 22:33, Alexander Walters wrote: If there is headway being made, I do not see it. Funny that you brought it up. I was about posting

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

That is great news. I just couldn't see it myself in the threads On 4/11/2016 16:51, Ethan Furman wrote: If there is headway being made, I do not see it. It's being made, and I dare say we are close to the end. ___ Python-Dev mailing list Python-

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

solution. I think this thread can safely be sunset. On 4/11/2016 17:04, Sven R. Kunze wrote: On 11.04.2016 22:55, Alexander Walters wrote: Every conceivable way to fix pathlib have already been argued. Are any of them worth doing? Can we get consensus enough to implement one of them? If not

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On 4/12/2016 12:14, Sven R. Kunze wrote: I cannot remember us using another datetime library. So, I don't value this "advantage" as much as you do. They exist, and there are many cases where you would use a datetime library other than datetime for various reasons (integration in third party s

Re: [Python-Dev] pathlib - current status of discussions

On 4/13/2016 13:10, Brett Cannon wrote: https://gist.github.com/brettcannon/b3719f54715787d54a206bc011869aa1 has the four potential approaches implemented (although it doesn't follow the "separate functions" approach some are proposing and instead goes with the allow_bytes approach I originally

Re: [Python-Dev] pathlib - current status of discussions

On 4/13/2016 13:49, Ethan Furman wrote: Number 3: it allows bytes, but only when told it's okay to do so. Having code get a bytes object when one is not expected is not a headache we need to inflict on anyone. This is an artifact of the other needless restrictions I said I wouldn't rant abou

Re: [Python-Dev] obmalloc mmap/munmap thrashing

...is that a typo for 2.7.11? On 4/21/2016 17:44, Neil Schemenauer wrote: I was running Python 2.4.11 under strace and I noticed some odd looking system calls: mmap(NULL, 262144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9848681000 munmap(0x7f9848681000, 262144) =

Re: [Python-Dev] VAX NaN evaluations

On Mon, Nov 4, 2013 at 3:47 PM, John Klos wrote: > What would be the best way to find code which handles evaluation of "NaN"? I would be surprised to find NaN handling outside of math module, float object and their complex counterparts (cmath and complex object). Other areas that deal with NaN

Re: [Python-Dev] A small patch.

On Wed, Nov 6, 2013 at 3:43 PM, Antoine Pitrou wrote: > Besides, if it's an assertion it's only an internal helper to check > implementation correctness. If it's an error that can be caused by > erroneous user data, it should be replaced with the proper exception class > (perhaps ValueError). A

Re: [Python-Dev] One-line abstractmethod function?

On Thu, Dec 5, 2013 at 1:24 PM, Guido van Rossum wrote: > How would you get the docstrings in? It seems cramming that much on a > single line doesn't help readability (even though I agree there is a > fair amount of boilerplace). > One way to reduce the amount of boilerplate code is to make abst

Re: [Python-Dev] One-line abstractmethod function?

On Thu, Dec 5, 2013 at 3:06 PM, Brett Cannon wrote: > How will abstractmethod know its function has no body? >> > > Technically you could inspect the code object of the method. to figure out > if the body is empty. > One way if to check f.__code__.co_lnotab - it will be empty when f has no body.

Re: [Python-Dev] (#19562) Asserts in Python stdlib code (datetime.py)

On Fri, Nov 15, 2013 at 9:10 PM, Tim Peters wrote: > > _DI4Y = _days_before_year(5) > > # A 4-year cycle has an extra leap day over what we'd get from pasting > > # together 4 single years. > > assert _DI4Y == 4 * 365 + 1 > > > > To me, the constant should be directly set to its known value. >

Re: [Python-Dev] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)

On Sun, Jan 26, 2014 at 8:52 PM, Nick Coghlan wrote: > There's also the fact that breaking working code in a maintenance release > is always dubious, especially when there's no current supported way to get > the equivalent behaviour prior to the maintenance release. This is the kind > of change t

Re: [Python-Dev] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)

On Sun, Jan 26, 2014 at 12:00 PM, Vajrasky Kok wrote: > >>> repeat('a', times=-1) > repeat('a') > As I think about it, this may be more than a bug but a door for a denial of service attack. Imagine an application where times comes from an untrusted source. Someone relying on documented behavio

Re: [Python-Dev] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)

On Sun, Jan 26, 2014 at 11:02 PM, Nick Coghlan wrote: > That is, I'm OK with either not backporting anything at all, or > backporting the full change. > +1 A partial backport will do a disservice to both users and maintainers. ___ Python-Dev mailing l

Re: [Python-Dev] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)

On Sun, Jan 26, 2014 at 11:21 PM, Vajrasky Kok wrote: > What about this alternative? Makes -1 consistently mean unlimited > repetition and other negative numbers consistently mean zero > repetitions > -1 I think this idea was already rejected on the bug tracker. It will be very surprising if li

Re: [Python-Dev] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)

On Sun, Jan 26, 2014 at 11:26 PM, Vajrasky Kok wrote: > In case we are taking "not backporting anything at all" road, what is > the best fix for the document? > > Old > >>> itertools.repeat.__doc__ > 'repeat(object [,times]) -> create an iterator which returns the > object\nfor the specified numbe

Re: [Python-Dev] Negative timedelta strings

On Fri, Mar 28, 2014 at 7:03 AM, Steven D'Aprano wrote: > py> str(timedelta(0, -1)) > '-1 day, 23:59:59' > .. > Does anyone remember the rationale for this behaviour? I don't recall any better rationale than what I wrote in the docs: "String representations of timedelta objects are normalized si

Re: [Python-Dev] Negative timedelta strings

On Fri, Mar 28, 2014 at 12:19 PM, Skip Montanaro wrote: > (*) As an aside (that is, this belongs in a separate thread if you > want to discuss it), in my opinion, attempting to support ISO 8601 > formatting is pointless without the presence of an anchor datetime. > I meant ISO 8601 syntax for "d

Re: [Python-Dev] ISO 8601 durations and datetime.timedelta

On Fri, Mar 28, 2014 at 1:13 PM, Skip Montanaro wrote: > Given that the timedelta has more than "a month's" worth of days, how > would you describe it using the ISO8601 duration notation without > referencing a specific point in time? Conversely, given your example, > "P3Y6M4DT12H30M5S", how woul

Re: [Python-Dev] PEP 465: A dedicated infix operator for matrix multiplication

On Sun, Apr 6, 2014 at 11:13 PM, Benjamin Peterson wrote: > > I believe this leaves only one open question, which is where exactly > > to stick the new matmul slots into PyTypeObject. This is the kind of > > fiddly detail that can easily be settled later if the PEP is accepted, > > though. > > I d

Re: [Python-Dev] PEP 465: A dedicated infix operator for matrix multiplication

On Mon, Apr 7, 2014 at 4:55 PM, Victor Stinner wrote: > I proposed to support both syntaxes, so you can write "@" if you are > unable to write ×. > It won't be obvious for the readers of the code whether × stands for @ or for *. Both * and @ are ASCII approximations to proper mathematical typeset

Re: [Python-Dev] PEP 465: A dedicated infix operator for matrix multiplication

On Mon, Apr 7, 2014 at 1:11 PM, Benjamin Peterson wrote: > > > We can populate that struct with array-specific alternatives for > > PySequence/PyMappingMethods and eliminate the need for dynamically > > created array types to allocate those. > > Why would we want to do that? I assume "that" means

Re: [Python-Dev] PEP 465: A dedicated infix operator for matrix multiplication

On Mon, Apr 7, 2014 at 5:23 PM, Benjamin Peterson wrote: > I can understand why creating new array types is good fun, but how is > creating a new struct helpful? > We can start by reviewing the reasons for having separate PyNumber/PySequence/PyMappingMethods structures. I believe that one of the

Re: [Python-Dev] PEP 465: A dedicated infix operator for matrix multiplication

On Mon, Apr 7, 2014 at 5:03 PM, Nathaniel Smith wrote: > no-one uses the pip -r requirements.txt system for > deployment... > I must be among "no-one" then. :-) Yet my systems don't leave much of a footprint on PyPI because we use PIP_DOWNLOAD_CACHE and internal PyPI mirrors. ___

Re: [Python-Dev] PEP 465: A dedicated infix operator for matrix multiplication

On Mon, Apr 7, 2014 at 5:03 PM, Nathaniel Smith wrote: > > It would be nice to support A × B too, because it's much more > > readable. You can configure a keyword to write arbitrary characters. > > For example, on Linux you can write × using "Compose x x" if you > > configured the Compose key. Or

Re: [Python-Dev] PEP 465: A dedicated infix operator for matrix multiplication

On Mon, Apr 7, 2014 at 5:58 PM, Larry Hastings wrote: > I am -1**3001 on adding redundant non-ASCII operators to the language. >>> -1**3001 -1 :-) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev U

Re: [Python-Dev] Python "2migr8"

On Mon, Apr 14, 2014 at 10:03 PM, Chris Angelico wrote: > > How about mirg2**3 (pronounced "migrate") ? > > > > ;-) > > > > Just read this, and laughed so loudly and suddenly that my brother's > cat jumped in fright. > > Spelled 2**3 and pronounced 8 makes perfect sense, same as spelling > "Mercu

[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

[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

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

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

[Python-Dev] new binary wheels PEP idea

Hi all, I have an idea regarding Python binary wheels on non-glibc platforms, and it seems that initially I've posted it to the wrong list ([1]) Long story short, the proposal is to use platform tuples (like compiler ones) for wheel names, which will allow much broader platform support, for examp

Re: [Python-Dev] new binary wheels PEP idea

ts the discussion on > Discourse for you). > > Cheers, > Steve > > On 19Feb2019 1341, Brett Cannon wrote: > > Unfortunately you're still posted to the wrong list, Alexander. You want > > to mail distutils-...@python.org <mailto:distutils-...@python

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

> 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] 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] Ordering keyword dicts

On Sun, May 19, 2013 at 1:47 AM, Guido van Rossum wrote: > I'm slow at warming up to the idea. My main concern is speed -- since > most code doesn't need it and function calls are already slow (and > obviously very common :-) it would be a shame if this slowed down > function calls that don't nee

Re: [Python-Dev] cpython (2.7): Fix comment blocks. Adjust blocksize to a power-of-two for better divmod

On Sun, Jun 23, 2013 at 11:37 PM, Raymond Hettinger < raymond.hettin...@gmail.com> wrote: > As far as I can tell, none > of the participants in this thread has ever previously shown any interest > in the deque object. It is discouraging to have a simple parameter > change and struct reordering re

Re: [Python-Dev] Reminder: an oft-forgotten rule about docstring formatting (PEP 257)

On Thu, Jun 27, 2013 at 10:20 AM, Guido van Rossum wrote: > On Thu, Jun 27, 2013 at 1:21 AM, Antoine Pitrou > wrote: > > I don't always find it easy to summarize a function in one line. > > Neither do I. But I always manage to do it anyway. +1 If you cannot summarize what your function does i

Re: [Python-Dev] PEP 8 modernisation

Hi Nick, On Thu, Aug 1, 2013 at 4:44 PM, Nick Coghlan wrote: > 9. Explicit guideline not to assign lambdas to names (use def, that's > what it's for) Even for propose to fit chars-per-line limit and/or to remove duplicates (especially for sorted groupby case)? -- ,,,^..^,,,

Re: [Python-Dev] PEP 8 modernisation

they are looks useless (or useful only for very trivial cases) -- ,,,^..^,,, On Thu, Aug 1, 2013 at 6:41 PM, Ronald Oussoren wrote: > > On 1 Aug, 2013, at 16:34, Alexander Shorin wrote: > >> Hi Nick, >> >> On Thu, Aug 1, 2013 at 4:44 PM, Nick Coghlan wrote: >>

<    1   2   3   4   5   6   7   8   >