Re: [Python-Dev] Second post: PEP 557, Data Classes

On 11/28/2017 8:31 PM, Eric V. Smith wrote: On 11/28/2017 4:14 PM, Guido van Rossum wrote: Hm. Maybe for the ordering comparisons we could defer to the class with the longest list of fields, as long as there's a subtype relationship? That way bb would be equivalent, and both would use

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

On 29 November 2017 at 06:17, Guido van Rossum wrote: > Please, not for 3.7. I think it will be very difficult to get consensus > about this, and I personally feel something like +/- zero about it -- > sometimes I think it makes sense, sometimes I think we're jumping the shark >

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

28.11.17 22:31, Raymond Hettinger пише: I also cc python-dev to see if anybody here is strongly in favor or against this inclusion. Put me down for a strong -1. The proposal would occasionally save a few keystokes but comes at the expense of giving Python a more Perlish look and a more

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

> On Nov 19, 2017, at 8:40 AM, Nathaniel Smith wrote: > > We have been using DeprecationWarning for changes where code will > transition from working -> raising an error, and that *is* based on > the Official Recommendation to hide those by default whenever > possible. We've

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

I like much of the thinking in Random's approach. But I still think None isn't quite special enough to warrant it's own syntax. However, his '(or None: name.strip()[4:].upper())' makes me realize that what is being asked in all the '?(', '?.', '?[' syntax ideas is a kind of ternary expression.

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

> On Nov 29, 2017, at 12:40 PM, David Mertz wrote: > > I like much of the thinking in Random's approach. But I still think None > isn't quite special enough to warrant it's own syntax. > > However, his '(or None: name.strip()[4:].upper())' makes me realize that what > is

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

On Tue, Nov 28, 2017, at 15:31, Raymond Hettinger wrote: > > > I also cc python-dev to see if anybody here is strongly in favor or against > > this inclusion. > > Put me down for a strong -1. The proposal would occasionally save a few > keystokes but comes at the expense of giving Python a

Re: [Python-Dev] iso8601 parsing

Hi, This thread isn't about the numerous third-party solutions that are a pip command away. But rather getting a minimal return parser to handle datetime.isoformat() into the std library. It's been needed for years, and hopefully someone can squeeze it into 3.7 before its too late. (It

Re: [Python-Dev] Removing files from the repository

That sounds a bit excessive. Is there a recent incident that inspired this proposal? On Wed, Nov 29, 2017 at 10:26 AM, Serhiy Storchaka wrote: > After removing files from the repository they disappear from the source > tree, and it is even hard to notice this if you don't

Re: [Python-Dev] Removing files from the repository

On Wed, Nov 29, 2017 at 1:47 PM, Ryan Gonzalez wrote: > Doesn't Git make this rather easy, though? +1. PEP-like process for removing/renaming files is too much, in my opinion. Yury ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] Removing files from the repository

29.11.17 20:47, Ryan Gonzalez пише: Doesn't Git make this rather easy, though? e.g. you can find all deleted files with: git log --diff-filter=D --summary and find a specific file with (showing glob patterns): git log --all --full-history -- **/thefile.* and then show it: git show -- or

Re: [Python-Dev] Removing files from the repository

Hi, Serhiy opened this thread after I removed tools for CVS and Subversion from the master branch: two scripts and a svnmap.txt file. I removed Misc/svnmap.txt, a mapping of Subversion commits to Mercurial commits. The change was approved by 3 core dev, but then I was asked to restore (only) the

Re: [Python-Dev] Removing files from the repository

29.11.17 21:00, Guido van Rossum пише: That sounds a bit excessive. Is there a recent incident that inspired this proposal? The concrete inspiration is issue32159 [1]. I am still not sure that removing these scripts is needed. But there were other cases in which I was not sure about the

Re: [Python-Dev] Removing files from the repository

On 11/29/2017 07:26 PM, Serhiy Storchaka wrote: [...] Perhaps it is worth to track all removals in a special file, so if later you will find that the removed file can be useful you could restore it instead of recreating its functionality from zero in the case if you even don't know that

Re: [Python-Dev] Third and hopefully final post: PEP 557, Data Classes

On 11/29/2017 03:26 PM, Eric V. Smith wrote: > I've posted a new version of PEP 557, it should soon be available at > https://www.python.org/dev/peps/pep-0557/. > > The only significant changes since the last version are: > > - changing the "compare" parameter to be "order", since that more >

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

There were discussions about having it a function, making the constructor of datetime accept a string(this was strongly rejected), having a static funcion in datetime, etc... and there was no real agreement. If the agreement is that we want a funcion to be able to parse it I am sure Paul G will

Re: [Python-Dev] iso8601 parsing

Yeah! I'm available for writing docs and testing it if needed. Performance is not a big concern in this first version, unless you've already written most of it. If it is a concern for others then the third-party modules will still be available as well. -Mike On 2017-11-29 16:19, Paul G

Re: [Python-Dev] Third and hopefully final post: PEP 557, Data Classes

I plan to accept this on Monday if no new objections are raised. On Nov 29, 2017 3:28 PM, "Eric V. Smith" wrote: > I've posted a new version of PEP 557, it should soon be available at > https://www.python.org/dev/peps/pep-0557/. > > The only significant changes since the

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

2017-11-12 10:24 GMT+01:00 Nick Coghlan : > I've written a short(ish) PEP for the proposal to change the default > warnings filters to show DeprecationWarning in __main__: > https://www.python.org/dev/peps/pep-0565/ I understand the rationale of the PEP, but I dislike the

Re: [Python-Dev] Removing files from the repository

Hm. For the file used for lookup, I see the point of keeping it. But in general, I don't see the point of keeping files we no longer need -- that's what VCS systems are for! On Wed, Nov 29, 2017 at 2:28 PM, Serhiy Storchaka wrote: > 29.11.17 21:00, Guido van Rossum пише: >

[Python-Dev] Third and hopefully final post: PEP 557, Data Classes

I've posted a new version of PEP 557, it should soon be available at https://www.python.org/dev/peps/pep-0557/. The only significant changes since the last version are: - changing the "compare" parameter to be "order", since that more accurately reflects what it does. - Having the combination

Re: [Python-Dev] iso8601 parsing

On Wed, Nov 29, 2017 at 10:05 AM, Mike Miller wrote: > This thread isn't about the numerous third-party solutions that are a pip > command away. But rather getting a minimal return parser to handle > datetime.isoformat() into the std library. > > It's been needed for

Re: [Python-Dev] Third and hopefully final post: PEP 557, Data Classes

On Wed, Nov 29, 2017 at 3:51 PM, Carl Meyer wrote: > On 11/29/2017 03:26 PM, Eric V. Smith wrote: > > I've posted a new version of PEP 557, it should soon be available at > > https://www.python.org/dev/peps/pep-0557/. > > > > The only significant changes since the last version

Re: [Python-Dev] Third and hopefully final post: PEP 557, Data Classes

On 11/29/2017 6:51 PM, Carl Meyer wrote: On 11/29/2017 03:26 PM, Eric V. Smith wrote: I've posted a new version of PEP 557, it should soon be available at https://www.python.org/dev/peps/pep-0557/. The only significant changes since the last version are: - changing the "compare" parameter to

Re: [Python-Dev] iso8601 parsing

I can write at least a pure Python implementation in the next few days, if not a full C implementation. Shouldn't be too hard since I've got a few different Cython implementations sitting around anyway. On November 29, 2017 7:06:58 PM EST, Alexander Belopolsky

Re: [Python-Dev] PEP 565: Show DeprecationWarning in __main__

On Nov 28, 2017 3:55 PM, "Guido van Rossum" wrote: On Sun, Nov 19, 2017 at 5:40 AM, Nathaniel Smith wrote: > Eh, numpy does use FutureWarning for changes where the same code will > transition from doing one thing to doing something else without > passing

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

On Nov 29, 2017, at 12:40, David Mertz wrote: > I think some syntax could be possible to only "catch" some exceptions and let > others propagate. Maybe: > >val = name.strip()[4:].upper() except (AttributeError, KeyError): -1 > > I don't really like throwing a colon in an

Re: [Python-Dev] What's the status of PEP 505: None-aware operators?

On 28 November 2017 at 18:38, Barry Warsaw wrote: > On Nov 28, 2017, at 15:31, Raymond Hettinger > wrote: > >> Put me down for a strong -1. The proposal would occasionally save a few >> keystokes but comes at the expense of giving Python a more

[Python-Dev] Removing files from the repository

After removing files from the repository they disappear from the source tree, and it is even hard to notice this if you don't use it regularly. It is hard to track the history of the removed file even if you know it exact path. If you know it only approximate this is harder. I think that any

Re: [Python-Dev] Removing files from the repository

Doesn't Git make this rather easy, though? e.g. you can find all deleted files with: git log --diff-filter=D --summary and find a specific file with (showing glob patterns): git log --all --full-history -- **/thefile.* and then show it: git show -- or restore it: git checkout ^ --