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

On 29 November 2017 at 04:31, Eric V. Smith wrote: > On 11/28/17 7:02 AM, Nick Coghlan wrote: >> So in the above example, you would have: >> >>>>> B.__field_layout__ is B >>True >>>>> C1.__field_layout__ is B >>True >>>>> C2.__field_layout__ is B >>True

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

On 29 November 2017 at 07:15, Mark Haase wrote: > Hi Lukasz, I don’t have plans on editing or promoting the PEP any further, > unless there is renewed interest or somebody proposes a more Pythonic > syntax. We should probably set the state of both this and the related circuit

Re: [Python-Dev] Can Python guarantee the order of keyword-only parameters?

On 29 November 2017 at 03:13, Brett Cannon wrote: > On Tue, 28 Nov 2017 at 03:33 Nick Coghlan wrote: >> P.S. Note that inspect.getfullargspec() was actually undeprecated a >> while back - enough folks that didn't need access to the function >> annotations

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

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 C.__gt__. Which had better not reject this on the

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

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 through a state where it raises an error. But that decision > was based on

Re: [Python-Dev] Regular expressions: splitting on zero-width patterns

On 2017-11-28 22:27, Guido van Rossum wrote: On Tue, Nov 28, 2017 at 2:23 PM, MRAB > wrote: On 2017-11-28 20:04, Serhiy Storchaka wrote: The two largest problems in the re module are splitting on zero-width

Re: [Python-Dev] Regular expressions: splitting on zero-width patterns

On Tue, Nov 28, 2017 at 2:23 PM, MRAB wrote: > On 2017-11-28 20:04, Serhiy Storchaka wrote: > >> The two largest problems in the re module are splitting on zero-width >> patterns and complete and correct support of the Unicode standard. These >> problems are solved in

Re: [Python-Dev] Regular expressions: splitting on zero-width patterns

On 2017-11-28 20:04, Serhiy Storchaka wrote: The two largest problems in the re module are splitting on zero-width patterns and complete and correct support of the Unicode standard. These problems are solved in regex. regex has many other features, but they are less important. I want to tell

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

Hi Lukasz, I don’t have plans on editing or promoting the PEP any further, unless there is renewed interest or somebody proposes a more Pythonic syntax. -- Mark E. Haase > On Nov 28, 2017, at 3:31 PM, Raymond Hettinger > wrote: > > >> I also cc python-dev to

Re: [Python-Dev] iso8601 parsing

The basics should be possible already with issue31800 , that said the issue you reference is to get a single function to parse it (without having to put the whole format), which would be neat. I believe Paul Ganssle is planning on adding it to dateutil as well:

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

On Tue, Nov 28, 2017 at 12:56 PM, Eric V. Smith wrote: > On 11/28/2017 1:57 PM, Guido van Rossum wrote: > >> I would also be happy with a retreat, where we define `__eq__` to insist >> that the classes are the same, and people can override this to their >> hearts' content. >>

Re: [Python-Dev] iso8601 parsing

It's got its own little parsing language, different than the usual strftime/strptime format scheme, more like what you might see in Excel. I never worried too much about the speed of dateutil.parser.parse() unless I was calling it in an inner loop, but arrow.get() seems to be a fair bit faster

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

> On Nov 28, 2017, at 15:59, Paul Moore wrote: > > On 28 November 2017 at 20:38, Barry Warsaw wrote: >> I had occasional to speak with someone very involved in Rust development. >> They have a process roughly similar to our PEPs. One of the things he

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

On 11/28/2017 1:57 PM, Guido van Rossum wrote: I would also be happy with a retreat, where we define `__eq__` to insist that the classes are the same, and people can override this to their hearts' content. I agree. And I guess we could always add it later, if there's a huge demand and

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

On 28 November 2017 at 20: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

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

On 11/28/2017 12:31 PM, Raymond Hettinger wrote: timeout ?? local_timeout ?? global_timeout 'foo' in (None ?? ['foo', 'bar']) requested_quantity ?? default_quantity * price name?.strip()[4:].upper() user?.first_name.upper() Cryptic, indeed. -1 from me. -- ~Ethan~

Re: [Python-Dev] iso8601 parsing

IIRC, arrow usually calls dateutil to parse dates anyway, and there are many other, lighter dependencies that will parse an ISO 8601 date quickly into a datetime.datetime object. I still think it's reasonable for the .isoformat() operation to have an inverse operation in the standard library.

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

On 2017-11-28 21: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 more Perlish

Re: [Python-Dev] Regular expressions: splitting on zero-width patterns

On 2017-11-28 20:04, Serhiy Storchaka wrote: The two largest problems in the re module are splitting on zero-width patterns and complete and correct support of the Unicode standard. These problems are solved in regex. regex has many other features, but they are less important. I want to tell

Re: [Python-Dev] iso8601 parsing

> I think the latest version can now strptime offsets of the form ±HH:MM with > %z, so there's no longer anything blocking you from parsing from all > isoformat() outputs with strptime, provided you know which one you need. Or just punt and install arrow: >>> import arrow >>>

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

-1 from me too. Mariatta Wijaya On Tue, Nov 28, 2017 at 12:38 PM, 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

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

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 Perlish look and a > more arcane feel. I am also -1. > One of the things

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

> 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 arcane feel. One of the things I

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

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 here. On Tue, Nov 28, 2017 at 12:10 PM, Lukasz Langa wrote:

Re: [Python-Dev] Regular expressions: splitting on zero-width patterns

I trust your instincts and powers of analysis here. Maybe MRAB has some useful feedback on the tar in the honey? On Tue, Nov 28, 2017 at 12:04 PM, Serhiy Storchaka wrote: > The two largest problems in the re module are splitting on zero-width > patterns and complete and

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

Hi Mark, it looks like the PEP is dormant for over two years now. I had multiple people ask me over the past few days about it though, so I wanted to ask if this is moving forward. I also cc python-dev to see if anybody here is strongly in favor or against this inclusion. If the idea itself is

Re: [Python-Dev] iso8601 parsing

I think the latest version can now strptime offsets of the form ±HH:MM with %z, so there's no longer anything blocking you from parsing from all isoformat() outputs with strptime, provided you know which one you need. I think a from_isoformat() like method that *only* supports isoformat outputs

[Python-Dev] Regular expressions: splitting on zero-width patterns

The two largest problems in the re module are splitting on zero-width patterns and complete and correct support of the Unicode standard. These problems are solved in regex. regex has many other features, but they are less important. I want to tell the problem of splitting on zero-width

Re: [Python-Dev] iso8601 parsing

This may have gotten bogged down again. Could we get the output of datetime.isoformat() parsed at a minimum? Perfection is not required. Looks like there is a patch or two and test cases on the bug. -Mike Could anyone put this five year-old bug about parsing iso8601 format date-times on

Re: [Python-Dev] PEP 565: show DeprecationWarning in __main__ (round 2)

This is awesome. If there isn't more feedback in the next few days expect an approval early next week. (Ping me if you don't hear from me, I'm juggling way too many small tasks so I'm likely to forget some.) On Tue, Nov 28, 2017 at 3:00 AM, Nick Coghlan wrote: > On 28

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

I would also be happy with a retreat, where we define `__eq__` to insist that the classes are the same, and people can override this to their hearts' content. ___ Python-Dev mailing list Python-Dev@python.org

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

On 11/28/17 7:02 AM, Nick Coghlan wrote: On 28 November 2017 at 17:41, Eric V. Smith wrote: One thing this doesn't let you do is compare instances of two different subclasses of a base type: @dataclass class B: i: int @dataclass class C1(B): pass @dataclass class

Re: [Python-Dev] Can Python guarantee the order of keyword-only parameters?

I was going to suggest the final DeprecationWarning should be raised unconditionally (subject to whatever silencing rules are agreed) by the final 2.7 release to recommend migration to Python 3. "This is an ex-language ... it has ceased to be ... it is no more ... it has returned to the great

Re: [Python-Dev] Can Python guarantee the order of keyword-only parameters?

On Tue, 28 Nov 2017 at 03:33 Nick Coghlan wrote: > On 28 November 2017 at 15:42, Larry Hastings wrote: > > On 11/27/2017 03:58 PM, Yury Selivanov wrote: > >> We can't say anything about the order if someone passes a partial > >> object > > > > Sure we

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

On 28 November 2017 at 17:41, Eric V. Smith wrote: > One thing this doesn't let you do is compare instances of two different > subclasses of a base type: > > @dataclass > class B: > i: int > > @dataclass > class C1(B): pass > > @dataclass > class C2(B): pass > > You can't

Re: [Python-Dev] Can Python guarantee the order of keyword-only parameters?

On 28 November 2017 at 15:42, Larry Hastings wrote: > On 11/27/2017 03:58 PM, Yury Selivanov wrote: >> We can't say anything about the order if someone passes a partial >> object > > Sure we could. We could ensure that functools.partial behaves in a sane > way, then document

Re: [Python-Dev] PEP 565: show DeprecationWarning in __main__ (round 2)

On 28 November 2017 at 09:52, Guido van Rossum wrote: > I am basically in agreement with this now. Some remarks: I've pushed an update which should address most of these, as well as Serhiy's comment about the existing FutureWarning use case: