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

[Nick Coghlan]

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
>>
>> It would then be up to the dataclass decorator to set
>> `__field_layout__` correctly, using the follow rules:
>>
>> 1. Use the just-defined class if the class defines any fields
>> 2. Use the just-defined class if it inherits from multiple base
>> classes that define fields and don't already share an MRO
>> 3. Use a base class if that's either the only base class that defines
>> fields, or if all other base classes that define fields are already in
>> the MRO of that base class
>
>
> That seems like a lot of complication for a feature that will be rarely
> used. I'll give it some thought, especially the MI logic.
>
> I think what you're laying out is an optimization for "do the classes have
> identical fields, inherited through a common base class or classes", right?

It's a combination of that and "How do I get my own class to compare
equal with a dataclass instance?".

However, having the dataclass methods return NotImplemented for
mismatched types should be enough to enable interoperability, since it
will leave the question up to the other type.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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
breaking protocol PEPs to Deferred so folks know neither of us is
actually working on them.

While I still think there's merit to the idea of making it easier to
write concise data cleanup pipelines in Python, I find the argument
"The currently proposed spelling doesn't even come close to reading
like executable pseudo code" to be a compelling one.

I think a big part of the problem is that these kinds of data cleanup
operations don't even have a good *vocabulary* around them yet, so
nobody actually knows how to write them as pseudo code in the first
place - we only know how to express them in particular programming
languages.

Trying to come up with pseudo code for the example cases Raymond mentioned:

   timeout if defined, else local_timeout if defined, else global_timeout
   price * (requested_quantity if defined, else default_quantity)

   name if not defined, else name.strip()[4:].upper()
   user if not defined, else name.first_name.upper()

And that's not actually that different to their current spellings in Python:

   timeout if timeout is not None else local_timeout if local_timeout
is not None, else global_timeout
   price * (requested_quantity if requested_quantity is not None else
default_quantity)

   name if name is None else name.strip()[4:].upper()
   user if user is None else name.first_name.upper()

One key aspect that Python does miss relative to the pseudocode
versions is that we don't actually have a term for "expr is not None".
"def" is used specifically for functions, so "defined" isn't reference
right. References to "None" are bound like anything else, so "bound"
isn't right. "exists" probably comes closest (hence the title of the
withdrawn PEP 531).

That said, if we did decide to allow "def" in a conditional expression
to mean "defined" in the "lhs is not None" sense, it would look like:

   timeout if def else local_timeout if def else global_timeout
   price * (requested_quantity if def else default_quantity)

   name if not def else name.strip()[4:].upper()
   user if not def else user.first_name.upper()

Cheers,
Nick.

P.S. Compared to this, our last symbolic feature addition (matrix
multiplication), was a relatively straightforward transcription of "⋅"
to "@", just as regular multiplication is a transcription of "×" to
"*".

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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 were reimplementing it for themselves "because the
>> standard library API is deprecated" that the most logical course of
>> action was to just declare it as being supported again. I don't think
>> that changes the argument here though - it just means guaranteed order
>> preservation in that API will only happen if we declare dicts to be
>> insertion ordered in general.
>
> OT for this thread, but is there an issue number tracking the
> un-deprecating? Basically I want to make sure there is an issue tracking
> deprecating it again when we stop worrying about any Python 2/3 support.

The issue is https://bugs.python.org/issue27172, but the undeprecation
isn't a Python 2/3 issue, it's a "tuples, lists and dicts are really
handy representations of things, and Python developers often prefer
them to more structured objects" issue.

The modern inspect.getfullargspec implementation is a relatively thin
wrapper around inspect.signature, and the only lossy part of the
output transformation is that you can't tell the difference between
positional-only and positional-or-keyword parameters.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Eric V. Smith]

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 basis that other is not an 
instance of a subclass of C.


IIRC there's already something in the interpreter that tries the most 
derived class first for binary operators -- that may force our hand here.


I'm leaning toward doing the same thing attrs does. They have much more 
experience with this.


This is my last open specification issue. I think I'm ready for a 
pronouncement on the PEP once I do one final editing pass, in hopes of 
getting this in 3.7.0a3 by next weekend. If the comparisons need to 
change, I'm okay with doing that in the beta.


Eric.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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 FutureWarning being shown to users by default, not
> because it matches the nominal purpose :-). IIRC I proposed this
> policy for NumPy in the first place, and I still don't even know if it
> matches the original intent because the docs are so vague. "Will
> change behavior in the future" describes every case where you might
> consider using FutureWarning *or* DeprecationWarning, right?
>
> 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 been doing this for a few years now, and I'd say our
> experience so far has been... poor. I'm trying to figure out how to
> say this politely. Basically it doesn't work at all. What happens in
> practice is that we issue a DeprecationWarning for a year, mostly
> no-one notices, then we make the change in a 1.x.0 release, everyone's
> code breaks, we roll it back in 1.x.1, and then possibly repeat
> several times in 1.(x+1).0 and 1.(x+2).0 until enough people have
> updated their code that the screams die down. I'm pretty sure we'll be
> changing our policy at some point, possibly to always use
> FutureWarning for everything.


Can one of you check that the latest version of PEP 565 gets this right?

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[MRAB]

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
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 patterns. It
already was discussed on Python-Dev 13 years ago [3] and maybe
later.
See also issues: [4], [5], [6], [7], [8].

[snip]
After some thought, I've decided that if this happens in the re
module in Python 3.7, then, for the sake of compatibility (and
because the edge cases are debatable anyway), I'll have the regex
module do the same when used on Python 3.7.


Maybe it should also be selectable with a version flag?

Well, when anyone who uses re updates to Python 3.7, they'll be faced 
with the change anyway.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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 regex. regex has many other features, but they
>> are less important.
>>
>> I want to tell the problem of splitting on zero-width patterns. It
>> already was discussed on Python-Dev 13 years ago [3] and maybe later.
>> See also issues: [4], [5], [6], [7], [8].
>>
>> [snip]
> After some thought, I've decided that if this happens in the re module in
> Python 3.7, then, for the sake of compatibility (and because the edge cases
> are debatable anyway), I'll have the regex module do the same when used on
> Python 3.7.
>

Maybe it should also be selectable with a version flag?

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[MRAB]

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 the problem of splitting on zero-width patterns. It
already was discussed on Python-Dev 13 years ago [3] and maybe later.
See also issues: [4], [5], [6], [7], [8].


[snip]
After some thought, I've decided that if this happens in the re module 
in Python 3.7, then, for the sake of compatibility (and because the edge 
cases are debatable anyway), I'll have the regex module do the same when 
used on Python 3.7.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Mark Haase]

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 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 like about Python is that I can walk non-programmers 
> through the code and explain what it does.  The examples in PEP 505 look like 
> a step in the wrong direction.  They don't "look like Python" and make me 
> feel like I have to decrypt the code to figure-out what it does.
> 
>timeout ?? local_timeout ?? global_timeout
>'foo' in (None ?? ['foo', 'bar'])
>requested_quantity ?? default_quantity * price
>name?.strip()[4:].upper()
>user?.first_name.upper()
> 
> 
> Raymond
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Mario Corchero]

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:
https://github.com/dateutil/dateutil/pull/489/files

On 28 November 2017 at 19:51, Mike Miller  wrote:

> 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 the front burner?
>>
>>  http://bugs.python.org/issue15873
>>
>> In the comments there's a lot of hand-wringing about different variations
>> that bogged it down, but right now I only need it to handle the output of
>> datetime.isoformat():
>>
>>  >>> dt.isoformat()
>>  '2017-10-20T08:20:08.986166+00:00'
>>
>> Perhaps if we could get that minimum first step in, it could be iterated
>> on and made more lenient in the future.
>>
>> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/mariocj89
> %40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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.
>>
>
> I agree. And I guess we could always add it later, if there's a huge
> demand and someone writes a decent implementation. There would be a slight
> backwards incompatibility, though. Frankly, I think it would never be
> needed.
>
> One question remains: do we do what attrs does: for `__eq__` and `__ne__`
> use an exact type match, and for the 4 ordered comparison operators use an
> isinstance check? On the comparison operators, they also ignore attributes
> defined on any derived class [0]. As I said, I couldn't find an attrs issue
> that discusses their choice. I'll ask Hynek over on the dataclasses github
> issue.
>
> Currently the dataclasses code on master uses an exact type match for all
> 6 methods.
>
> Eric.
>
> [0] That is, they do the following (using dataclasses terms):
>
> Given:
>
> @dataclass
> class B:
> i: int
> j: int
>
> @dataclass
> class C:
> k: int
>
> Then B.__eq__ is:
>
> def __eq__(self, other):
> if other.__class__ is self.__class__:
> return (other.i, other.j) == (self.i, self.j)
> return NotImplemented
>
> And B.__lt__ is:
>
> def __lt__(self, other):
> if isinstance(other, self.__class__):
> return (other.i, other.j) < (self.i, self.j)
> return NotImplemented
>
> So if you do:
> b = B(1, 2)
> c = C(1, 2, 3)
>
> Then `B(1, 2) < C(1, 2, 3)` ignores `c.k`.
>

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 basis that other is not an instance of a
subclass of C.

IIRC there's already something in the interpreter that tries the most
derived class first for binary operators -- that may force our hand here.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Skip Montanaro]

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 than dateutil.parser.parse. This makes sense, as the latter tries to
figure out what you've given it (you never give it a format string), while
in the absence of a format string, arrow.get assumes you have an ISO-8601
date/time, with only a few small variations allowed.

Skip

On Tue, Nov 28, 2017 at 2:52 PM, Paul G  wrote:

> 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.
>
> On November 28, 2017 3:45:41 PM EST, Skip Montanaro <
> skip.montan...@gmail.com> wrote:
>>
>>  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
>  arrow.get('2017-10-20T08:20:08.986166+00:00')
>
 
>>
>>>  arrow.get('2017-10-20T08:20:08.986166+00:00').datetime
>
 datetime.datetime(2017, 10, 20, 8, 20, 8, 986166, tzinfo=tzoffset(None, 0))
>>
>> Skip
>>
>>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Barry Warsaw]

> 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 told 
>> me, which I found very interesting and have been mulling over for PEPs is, 
>> they require a section in their specification discussion how any new feature 
>> will be taught, both to new Rust programmers and experienced ones.  I love 
>> the emphasis on teachability.  Sometimes I really miss that when considering 
>> some of the PEPs and the features they introduce (look how hard it is to 
>> teach asynchronous programming).
> 
> That's a really nice idea. I'd like to see Python adopt something
> similar (even just as a guideline on how to write a PEP).

https://github.com/python/peps/issues/485

-Barry



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Eric V. Smith]

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 someone writes a decent implementation. There would be a 
slight backwards incompatibility, though. Frankly, I think it would 
never be needed.


One question remains: do we do what attrs does: for `__eq__` and 
`__ne__` use an exact type match, and for the 4 ordered comparison 
operators use an isinstance check? On the comparison operators, they 
also ignore attributes defined on any derived class [0]. As I said, I 
couldn't find an attrs issue that discusses their choice. I'll ask Hynek 
over on the dataclasses github issue.


Currently the dataclasses code on master uses an exact type match for 
all 6 methods.


Eric.

[0] That is, they do the following (using dataclasses terms):

Given:

@dataclass
class B:
i: int
j: int

@dataclass
class C:
k: int

Then B.__eq__ is:

def __eq__(self, other):
if other.__class__ is self.__class__:
return (other.i, other.j) == (self.i, self.j)
return NotImplemented

And B.__lt__ is:

def __lt__(self, other):
if isinstance(other, self.__class__):
return (other.i, other.j) < (self.i, self.j)
return NotImplemented

So if you do:
b = B(1, 2)
c = C(1, 2, 3)

Then `B(1, 2) < C(1, 2, 3)` ignores `c.k`.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Paul Moore]

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

-1 from me, too.

>> One of the things I like about Python is that I can walk non-programmers 
>> through the code and explain what it does.  The examples in PEP 505 look 
>> like a step in the wrong direction.  They don't "look like Python" and make 
>> me feel like I have to decrypt the code to figure-out what it does.
>
> 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 told 
> me, which I found very interesting and have been mulling over for PEPs is, 
> they require a section in their specification discussion how any new feature 
> will be taught, both to new Rust programmers and experienced ones.  I love 
> the emphasis on teachability.  Sometimes I really miss that when considering 
> some of the PEPs and the features they introduce (look how hard it is to 
> teach asynchronous programming).

That's a really nice idea. I'd like to see Python adopt something
similar (even just as a guideline on how to write a PEP).

Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ethan Furman]

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~

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Paul G]

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.

On November 28, 2017 3:45:41 PM EST, Skip Montanaro  
wrote:
>> 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
 arrow.get('2017-10-20T08:20:08.986166+00:00')
>
 arrow.get('2017-10-20T08:20:08.986166+00:00').datetime
>datetime.datetime(2017, 10, 20, 8, 20, 8, 986166, tzinfo=tzoffset(None,
>0))
>
>Skip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Christian Heimes]

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 look and a 
> more arcane feel.   
> 
> One of the things I like about Python is that I can walk non-programmers 
> through the code and explain what it does.  The examples in PEP 505 look like 
> a step in the wrong direction.  They don't "look like Python" and make me 
> feel like I have to decrypt the code to figure-out what it does.
> 
> timeout ?? local_timeout ?? global_timeout
> 'foo' in (None ?? ['foo', 'bar'])
> requested_quantity ?? default_quantity * price
> name?.strip()[4:].upper()
> user?.first_name.upper()

Your examples have convinced me, -1 from me.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[MRAB]

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 the problem of splitting on zero-width patterns. It
already was discussed on Python-Dev 13 years ago [3] and maybe later.
See also issues: [4], [5], [6], [7], [8].

In short it doesn't work. Splitting on the pattern r'\b' doesn't split
the text at boundaries of words, and splitting on the pattern
r'\s+|(?<=-)' will split the text on whitespaces, but will not split
words with hypens as expected.

In Python 3.4 and earlier:

  >>> re.split(r'\b', 'Self-Defence Class')
['Self-Defence Class']
  >>> re.split(r'\s+|(?<=-)', 'Self-Defence Class')
['Self-Defence', 'Class']
  >>> re.split(r'\s*', 'Self-Defence Class')
['Self-Defence', 'Class']

Note that splitting on r'\s*' (0 or more whitespaces) actually split on
r'\s+' (1 or more whitespaces). Splitting on patterns that only can
match the empty string (like r'\b' or r'(?<=-)') never worked, while
splitting

Starting since Python 3.5 splitting on a pattern that only can match the
empty string raises a ValueError (this never worked), and splitting a
pattern that can match the empty string but not only emits a
FutureWarning. This taken developers a time for replacing their patterns
r'\s*' to r'\s+' as they should be.

Now I have created a final patch [9] that makes re.split() splitting on
zero-width patterns.

  >>> re.split(r'\b', 'Self-Defence Class')
['', 'Self', '-', 'Defence', ' ', 'Class', '']
  >>> re.split(r'\s+|(?<=-)', 'Self-Defence Class')
['Self-', 'Defence', 'Class']
  >>> re.split(r'\s*', 'Self-Defence Class')
['', 'S', 'e', 'l', 'f', '-', 'D', 'e', 'f', 'e', 'n', 'c', 'e', 'C',
'l', 'a', 's', 's', '']

The latter case the result is differ too much from the previous result,
and this likely not what the author wanted to get. But users had two
Python releases for fixing their code. FutureWarning is not silent by
default.

Because these patterns produced errors or warnings in the recent two
releases, we don't need an additional parameter for compatibility.

But the problem was not just with re.split(). Other functions also
worked not good with patterns that can match the empty string.

  >>> re.findall(r'^|\w+', 'Self-Defence Class')
['', 'elf', 'Defence', 'Class']
  >>> list(re.finditer(r'^|\w+', 'Self-Defence Class'))
[, , ,
]
  >>> re.sub(r'(^|\w+)', r'<\1>', 'Self-Defence Class')
'<>S- '

After matching the empty string the following character will be skipped
and will be not included in the next match. My patch fixes these
functions too.

  >>> re.findall(r'^|\w+', 'Self-Defence Class')
['', 'Self', 'Defence', 'Class']
  >>> list(re.finditer(r'^|\w+', 'Self-Defence Class'))
[, , ,
]
  >>> re.sub(r'(^|\w+)', r'<\1>', 'Self-Defence Class')
'<>- '

I think this change don't need preliminary warnings, because it change
the behavior of more rarely used patterns. No re tests have been broken.
I was needed to add new tests for detecting the behavior change.

But there is one spoonful of tar in a barrel of honey. I didn't expect
this, but this change have broken a pattern used with re.sub() in the
doctest module: r'(?m)^\s*?$'. This was fixed by replacing it with
r'(?m)^[^\S\n]+?$'). I hope that such cases are pretty rare and think
this is an avoidable breakage.

The new behavior of re.split() matches the behavior of regex.split()
with the VERSION1 flag, the new behavior of re.findall() and
re.finditer() matches the behavior of corresponding functions in the
regex module (independently from the version flag). But the new behavior
of re.sub() doesn't match exactly the behavior of regex.sub() with any
version flag. It differs from the old behavior as you can see in the
example above, but is closer to it that to regex.sub() with VERSION1.
This allowed to avoid braking existing tests for re.sub().

  >>> regex.sub(r'(\W+|(?<=-))', r':', 'Self-Defence Class')
  
  


'Self:Defence:Class'
  
  


  >>> regex.sub(r'(?V1)(\W+|(?<=-))', r':', 'Self-Defence Class')
  
  


'Self::Defence:Class'
  >>> re.sub(r'(\W+|(?<=-))', r':', 'Self-Defence Class')
'Self:Defence:Class'

As re.split() it never matches the empty string adjacent to the previous
match. re.findall() and re.finditer() only don't match the empty string
adjacent to the previous empty string match. In the regex module
regex.sub() is mutually consistent with regex.findall() and
regex.finditer() (with the VERSION1 flag), but regex.split() is not
consistent with them. In the re module re.split() and re.sub() will be
mutually consistent, as well as re.findall() and re.finditer(). This is
more backward compatible. And I don't know reasons for preferring the
behavior of re.findall() and re.finditer() over the behavior of
re.split() in this corner case.

FTR, you could make an argument for either behaviour. For regex, I 

Re: [Python-Dev] iso8601 parsing

[Skip Montanaro]

> 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
>>> arrow.get('2017-10-20T08:20:08.986166+00:00')

>>> arrow.get('2017-10-20T08:20:08.986166+00:00').datetime
datetime.datetime(2017, 10, 20, 8, 20, 8, 986166, tzinfo=tzoffset(None, 0))

Skip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Mariatta Wijaya]

-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 the expense of giving Python a more Perlish look
> and a more arcane feel.
>
> I am also -1.
>
> > One of the things I like about Python is that I can walk non-programmers
> through the code and explain what it does.  The examples in PEP 505 look
> like a step in the wrong direction.  They don't "look like Python" and make
> me feel like I have to decrypt the code to figure-out what it does.
>
> 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 told
> me, which I found very interesting and have been mulling over for PEPs is,
> they require a section in their specification discussion how any new
> feature will be taught, both to new Rust programmers and experienced ones.
> I love the emphasis on teachability.  Sometimes I really miss that when
> considering some of the PEPs and the features they introduce (look how hard
> it is to teach asynchronous programming).
>
> Cheers,
> -Barry
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> mariatta.wijaya%40gmail.com
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Barry Warsaw]

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 I like about Python is that I can walk non-programmers 
> through the code and explain what it does.  The examples in PEP 505 look like 
> a step in the wrong direction.  They don't "look like Python" and make me 
> feel like I have to decrypt the code to figure-out what it does.

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 told me, 
which I found very interesting and have been mulling over for PEPs is, they 
require a section in their specification discussion how any new feature will be 
taught, both to new Rust programmers and experienced ones.  I love the emphasis 
on teachability.  Sometimes I really miss that when considering some of the 
PEPs and the features they introduce (look how hard it is to teach asynchronous 
programming).

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

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

One of the things I like about Python is that I can walk non-programmers 
through the code and explain what it does.  The examples in PEP 505 look like a 
step in the wrong direction.  They don't "look like Python" and make me feel 
like I have to decrypt the code to figure-out what it does.

timeout ?? local_timeout ?? global_timeout
'foo' in (None ?? ['foo', 'bar'])
requested_quantity ?? default_quantity * price
name?.strip()[4:].upper()
user?.first_name.upper()


Raymond
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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:

> 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 uncontroversial, I could
> likely find somebody interested in implementing it. If not for 3.7 then at
> least for 3.8.
>
> - Ł
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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 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 patterns. It already
> was discussed on Python-Dev 13 years ago [3] and maybe later. See also
> issues: [4], [5], [6], [7], [8].
>
> In short it doesn't work. Splitting on the pattern r'\b' doesn't split the
> text at boundaries of words, and splitting on the pattern r'\s+|(?<=-)'
> will split the text on whitespaces, but will not split words with hypens as
> expected.
>
> In Python 3.4 and earlier:
>
> >>> re.split(r'\b', 'Self-Defence Class')
> ['Self-Defence Class']
> >>> re.split(r'\s+|(?<=-)', 'Self-Defence Class')
> ['Self-Defence', 'Class']
> >>> re.split(r'\s*', 'Self-Defence Class')
> ['Self-Defence', 'Class']
>
> Note that splitting on r'\s*' (0 or more whitespaces) actually split on
> r'\s+' (1 or more whitespaces). Splitting on patterns that only can match
> the empty string (like r'\b' or r'(?<=-)') never worked, while splitting
>
> Starting since Python 3.5 splitting on a pattern that only can match the
> empty string raises a ValueError (this never worked), and splitting a
> pattern that can match the empty string but not only emits a FutureWarning.
> This taken developers a time for replacing their patterns r'\s*' to r'\s+'
> as they should be.
>
> Now I have created a final patch [9] that makes re.split() splitting on
> zero-width patterns.
>
> >>> re.split(r'\b', 'Self-Defence Class')
> ['', 'Self', '-', 'Defence', ' ', 'Class', '']
> >>> re.split(r'\s+|(?<=-)', 'Self-Defence Class')
> ['Self-', 'Defence', 'Class']
> >>> re.split(r'\s*', 'Self-Defence Class')
> ['', 'S', 'e', 'l', 'f', '-', 'D', 'e', 'f', 'e', 'n', 'c', 'e', 'C', 'l',
> 'a', 's', 's', '']
>
> The latter case the result is differ too much from the previous result,
> and this likely not what the author wanted to get. But users had two Python
> releases for fixing their code. FutureWarning is not silent by default.
>
> Because these patterns produced errors or warnings in the recent two
> releases, we don't need an additional parameter for compatibility.
>
> But the problem was not just with re.split(). Other functions also worked
> not good with patterns that can match the empty string.
>
> >>> re.findall(r'^|\w+', 'Self-Defence Class')
> ['', 'elf', 'Defence', 'Class']
> >>> list(re.finditer(r'^|\w+', 'Self-Defence Class'))
> [,  match='elf'>, ,  object; span=(13, 18), match='Class'>]
> >>> re.sub(r'(^|\w+)', r'<\1>', 'Self-Defence Class')
> '<>S- '
>
> After matching the empty string the following character will be skipped
> and will be not included in the next match. My patch fixes these functions
> too.
>
> >>> re.findall(r'^|\w+', 'Self-Defence Class')
> ['', 'Self', 'Defence', 'Class']
> >>> list(re.finditer(r'^|\w+', 'Self-Defence Class'))
> [,  match='Self'>, ,  object; span=(13, 18), match='Class'>]
> >>> re.sub(r'(^|\w+)', r'<\1>', 'Self-Defence Class')
> '<>- '
>
> I think this change don't need preliminary warnings, because it change the
> behavior of more rarely used patterns. No re tests have been broken. I was
> needed to add new tests for detecting the behavior change.
>
> But there is one spoonful of tar in a barrel of honey. I didn't expect
> this, but this change have broken a pattern used with re.sub() in the
> doctest module: r'(?m)^\s*?$'. This was fixed by replacing it with
> r'(?m)^[^\S\n]+?$'). I hope that such cases are pretty rare and think this
> is an avoidable breakage.
>
> The new behavior of re.split() matches the behavior of regex.split() with
> the VERSION1 flag, the new behavior of re.findall() and re.finditer()
> matches the behavior of corresponding functions in the regex module
> (independently from the version flag). But the new behavior of re.sub()
> doesn't match exactly the behavior of regex.sub() with any version flag. It
> differs from the old behavior as you can see in the example above, but is
> closer to it that to regex.sub() with VERSION1. This allowed to avoid
> braking existing tests for re.sub().
>
> >>> regex.sub(r'(\W+|(?<=-))', r':', 'Self-Defence Class')
>
>
> 'Self:Defence:Class'
>
>
> >>> regex.sub(r'(?V1)(\W+|(?<=-))', r':', 'Self-Defence Class')
>
>
> 'Self::Defence:Class'
> >>> re.sub(r'(\W+|(?<=-))', r':', 'Self-Defence Class')
> 'Self:Defence:Class'
>
> As re.split() it never matches the empty string adjacent to the previous
> match. re.findall() and re.finditer() only don't match the empty string
> adjacent to the previous empty string match. In the regex module
> regex.sub() is mutually consistent with regex.findall() and
> regex.finditer() (with the VERSION1 flag), but 

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

[Lukasz Langa]

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 uncontroversial, I could likely find 
somebody interested in implementing it. If not for 3.7 then at least for 3.8.

- Ł


signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Paul G]

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 
is a fine idea, though, with a fairly obvious interface. I'd be happy to take a 
crack at it (I've been working on the somewhat harder problem of an iso8601 
compliant parser for dateutil, so this is fresh in my mind).

On November 28, 2017 2:51:14 PM EST, Mike Miller  
wrote:
>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 the front burner?
>> 
>>      http://bugs.python.org/issue15873
>> 
>> In the comments there's a lot of hand-wringing about different
>variations that 
>> bogged it down, but right now I only need it to handle the output of 
>> datetime.isoformat():
>> 
>>      >>> dt.isoformat()
>>      '2017-10-20T08:20:08.986166+00:00'
>> 
>> Perhaps if we could get that minimum first step in, it could be
>iterated on and 
>> made more lenient in the future.
>> 
>___
>Python-Dev mailing list
>Python-Dev@python.org
>https://mail.python.org/mailman/listinfo/python-dev
>Unsubscribe:
>https://mail.python.org/mailman/options/python-dev/paul%40ganssle.io
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Serhiy Storchaka]

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 patterns. It 
already was discussed on Python-Dev 13 years ago [3] and maybe later. 
See also issues: [4], [5], [6], [7], [8].


In short it doesn't work. Splitting on the pattern r'\b' doesn't split 
the text at boundaries of words, and splitting on the pattern 
r'\s+|(?<=-)' will split the text on whitespaces, but will not split 
words with hypens as expected.


In Python 3.4 and earlier:

>>> re.split(r'\b', 'Self-Defence Class')
['Self-Defence Class']
>>> re.split(r'\s+|(?<=-)', 'Self-Defence Class')
['Self-Defence', 'Class']
>>> re.split(r'\s*', 'Self-Defence Class')
['Self-Defence', 'Class']

Note that splitting on r'\s*' (0 or more whitespaces) actually split on 
r'\s+' (1 or more whitespaces). Splitting on patterns that only can 
match the empty string (like r'\b' or r'(?<=-)') never worked, while 
splitting


Starting since Python 3.5 splitting on a pattern that only can match the 
empty string raises a ValueError (this never worked), and splitting a 
pattern that can match the empty string but not only emits a 
FutureWarning. This taken developers a time for replacing their patterns 
r'\s*' to r'\s+' as they should be.


Now I have created a final patch [9] that makes re.split() splitting on 
zero-width patterns.


>>> re.split(r'\b', 'Self-Defence Class')
['', 'Self', '-', 'Defence', ' ', 'Class', '']
>>> re.split(r'\s+|(?<=-)', 'Self-Defence Class')
['Self-', 'Defence', 'Class']
>>> re.split(r'\s*', 'Self-Defence Class')
['', 'S', 'e', 'l', 'f', '-', 'D', 'e', 'f', 'e', 'n', 'c', 'e', 'C', 
'l', 'a', 's', 's', '']


The latter case the result is differ too much from the previous result, 
and this likely not what the author wanted to get. But users had two 
Python releases for fixing their code. FutureWarning is not silent by 
default.


Because these patterns produced errors or warnings in the recent two 
releases, we don't need an additional parameter for compatibility.


But the problem was not just with re.split(). Other functions also 
worked not good with patterns that can match the empty string.


>>> re.findall(r'^|\w+', 'Self-Defence Class')
['', 'elf', 'Defence', 'Class']
>>> list(re.finditer(r'^|\w+', 'Self-Defence Class'))
[, 4), match='elf'>, , 
]

>>> re.sub(r'(^|\w+)', r'<\1>', 'Self-Defence Class')
'<>S- '

After matching the empty string the following character will be skipped 
and will be not included in the next match. My patch fixes these 
functions too.


>>> re.findall(r'^|\w+', 'Self-Defence Class')
['', 'Self', 'Defence', 'Class']
>>> list(re.finditer(r'^|\w+', 'Self-Defence Class'))
[, 4), match='Self'>, , 
]

>>> re.sub(r'(^|\w+)', r'<\1>', 'Self-Defence Class')
'<>- '

I think this change don't need preliminary warnings, because it change 
the behavior of more rarely used patterns. No re tests have been broken. 
I was needed to add new tests for detecting the behavior change.


But there is one spoonful of tar in a barrel of honey. I didn't expect 
this, but this change have broken a pattern used with re.sub() in the 
doctest module: r'(?m)^\s*?$'. This was fixed by replacing it with 
r'(?m)^[^\S\n]+?$'). I hope that such cases are pretty rare and think 
this is an avoidable breakage.


The new behavior of re.split() matches the behavior of regex.split() 
with the VERSION1 flag, the new behavior of re.findall() and 
re.finditer() matches the behavior of corresponding functions in the 
regex module (independently from the version flag). But the new behavior 
of re.sub() doesn't match exactly the behavior of regex.sub() with any 
version flag. It differs from the old behavior as you can see in the 
example above, but is closer to it that to regex.sub() with VERSION1. 
This allowed to avoid braking existing tests for re.sub().


>>> regex.sub(r'(\W+|(?<=-))', r':', 'Self-Defence Class') 




'Self:Defence:Class' 




>>> regex.sub(r'(?V1)(\W+|(?<=-))', r':', 'Self-Defence Class') 




'Self::Defence:Class'
>>> re.sub(r'(\W+|(?<=-))', r':', 'Self-Defence Class')
'Self:Defence:Class'

As re.split() it never matches the empty string adjacent to the previous 
match. re.findall() and re.finditer() only don't match the empty string 
adjacent to the previous empty string match. In the regex module 
regex.sub() is mutually consistent with regex.findall() and 
regex.finditer() (with the VERSION1 flag), but regex.split() is not 
consistent with them. In the re module re.split() and re.sub() will be 
mutually consistent, as well as re.findall() and re.finditer(). This is 
more backward compatible. And I don't know reasons for preferring the 
behavior of re.findall() and re.finditer() over the behavior of 
re.split() in this corner case.


Would be nice to get this change in 3.7.0a3 for wider 

Re: [Python-Dev] iso8601 parsing

[Mike Miller]

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 the front burner?


     http://bugs.python.org/issue15873

In the comments there's a lot of hand-wringing about different variations that 
bogged it down, but right now I only need it to handle the output of 
datetime.isoformat():


     >>> dt.isoformat()
     '2017-10-20T08:20:08.986166+00:00'

Perhaps if we could get that minimum first step in, it could be iterated on and 
made more lenient in the future.



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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 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:
> https://github.com/python/peps/commit/aaa64f53d0434724384b056a3c195d
> 63a5cc3761
>
> > - I would recommend adding a note to the abstract about the
> recommendation
> > for test runners to also enable these warnings by default.
>
> Done.
>
> > - Would be nice to know whether IPython/Jupyter is happy with this.
>
> They implemented a solution along these lines some time ago, so I've
> added a new subsection with advice for folks writing interactive
> shells, and quoted their warnings.filterwarnings call as an example of
> how to do it (with a link to the relevant line in their repo).
>
> > - The sentence "As a result, API deprecation warnings encountered by
> > development tools written in Python should continue to be hidden by
> default
> > for users of those tools" is missing a final period; I also think that
> the
> > argument here is stronger if "development" is left out. (Maybe
> development
> > tools could be called out in a "for example" clause.)
>
> I ended up rewording that paragraph completely (partly prompted by
> your comment about the impact on single file scripts).
>
> > - I can't quite put my finger on it, but reading the three bullets of
> > distinct categories of warnings something seems slightly off, perhaps
> due to
> > independent editing of various phrases. Perhaps the three bullets could
> be
> > rewritten for better correspondence between the various properties and
> > audiences? And what should test runners do for each?
>
> I think I was trying to do too much in that list of categories, so I
> moved everything related to test runners out to a new dedicated
> section.
>
> That means the list of categories can focus solely on the actual
> defaults, while the new test runner section describes how we expect
> test runners to override that.
>
> I also noticed something that seemed worth mentioning in relation to
> BytesWarning, which is that "-Wd" works as well as it does because the
> interpreter doesn't even *try* to emit those warnings if you don't
> pass "-b" or "-bb" on the command line. The warnings filter only
> handles the "Should it be a warning or an exception?" part.
>
> > - Also, is SyntaxWarning worth adding to the list?
>
> I *haven't* added this, since our only current syntax warning that I
> can see is the one for "assert ('always', 'true')", and we've been
> more inclined to go down the DeprecationWarning->SyntaxError path in
> recent years than we have to settle for a persistent syntax warning.
>
> > - The thing about FutureWarning being present since 2.3 feels odd -- if
> your
> > library cares about supporting 2.7 and higher, should it use
> FutureWarning
> > or DeprecationWarning?
>
> I reworded this paragraph to make it more prescriptive and say "Use
> DeprecationWarning on 3.7+, use FutureWarning on earlier versions if
> you don't think the way they handle DeprecationWarning is noisy
> enough")
>
> > - "re-enabling deprecation warnings by default in __main__ doesn't help
> in
> >   handling cases where software has been factored out into support
> modules,
> > but
> >   those modules still have little or no automated test coverage."
> >   This and all bullets in the same list should have an initial capital
> > letter and trailing period.
>
> Fixed.
>
> > This sentence in particular also reads odd: the
> > "but" seems to apply to everything that comes before, but actually is
> meant
> > to apply only to "cases where ...". Maybe rephrasing this can help the
> > sentence flow better.
>
> I missed this comment initially. Follow-up commit to reword that
> sentence: https://github.com/python/peps/commit/
> 47ea35f0510dab2b01e18ff437f95c6b1b75f2e6
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Eric V. Smith]

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 C2(B): pass

You can't compare C1(0) and C2(0), because neither one is an instance of the
other's type. The test to get this case to work would be expensive: find the
common ancestor, and then make sure no fields have been added since then.
And I haven't thought through multiple inheritance.

I suggest we don't try to support this case.


That gets you onto problematic ground as far as transitivity is
concerned, since you'd end up with the following:


Excellent point, thanks for raising it.


>>> b = B(0); c1 = C1(0); c2 = C2(0)
>>> c1 == b
True
>>> b == c2
True
>>> c1 == c2
False

However, I think you can fix this by injecting the first base in the
MRO that defines a data field as a "__field_layout__" class attribute,
and then have the comparison methods check for "other.__field_layout__
is self.__field_layout__", rather than checking the runtime class
directly.

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

It would then be up to the dataclass decorator to set
`__field_layout__` correctly, using the follow rules:

1. Use the just-defined class if the class defines any fields
2. Use the just-defined class if it inherits from multiple base
classes that define fields and don't already share an MRO
3. Use a base class if that's either the only base class that defines
fields, or if all other base classes that define fields are already in
the MRO of that base class


That seems like a lot of complication for a feature that will be rarely 
used. I'll give it some thought, especially the MI logic.


I think what you're laying out is an optimization for "do the classes 
have identical fields, inherited through a common base class or 
classes", right?


Eric.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Steve Holden]

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 heap whence it came ..."

Steve Holden

On Tue, Nov 28, 2017 at 5:13 PM, Brett Cannon  wrote:

>
>
> 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 could.  We could ensure that functools.partial behaves in a sane
>> > way, then document and guarantee that behavior.
>>
>> Right, I think the main implication here would be that we need to
>> ensure that any signature manipulation operations *we* provide are
>> order preserving.
>>
>> Fortunately for Larry, we kinda cheat on that front: all the logic for
>> dealing with this problem is in the inspect module itself, which knows
>> about all the different ways we manipulate signatures in the standard
>> library. That means that if we want to declare that the inspect module
>> will be order preserving, we can, and it shouldn't require changes to
>> anything else.
>>
>> Cheers,
>> Nick.
>>
>> P.S. Note that inspect.getfullargspec() was actually undeprecated a
>> while back - enough folks that didn't need access to the function
>> annotations were reimplementing it for themselves "because the
>> standard library API is deprecated" that the most logical course of
>> action was to just declare it as being supported again. I don't think
>> that changes the argument here though - it just means guaranteed order
>> preservation in that API will only happen if we declare dicts to be
>> insertion ordered in general.
>>
>
> OT for this thread, but is there an issue number tracking the
> un-deprecating? Basically I want to make sure there is an issue tracking
> deprecating it again when we stop worrying about any Python 2/3 support.
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> steve%40holdenweb.com
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Brett Cannon]

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 could.  We could ensure that functools.partial behaves in a sane
> > way, then document and guarantee that behavior.
>
> Right, I think the main implication here would be that we need to
> ensure that any signature manipulation operations *we* provide are
> order preserving.
>
> Fortunately for Larry, we kinda cheat on that front: all the logic for
> dealing with this problem is in the inspect module itself, which knows
> about all the different ways we manipulate signatures in the standard
> library. That means that if we want to declare that the inspect module
> will be order preserving, we can, and it shouldn't require changes to
> anything else.
>
> Cheers,
> Nick.
>
> P.S. Note that inspect.getfullargspec() was actually undeprecated a
> while back - enough folks that didn't need access to the function
> annotations were reimplementing it for themselves "because the
> standard library API is deprecated" that the most logical course of
> action was to just declare it as being supported again. I don't think
> that changes the argument here though - it just means guaranteed order
> preservation in that API will only happen if we declare dicts to be
> insertion ordered in general.
>

OT for this thread, but is there an issue number tracking the
un-deprecating? Basically I want to make sure there is an issue tracking
deprecating it again when we stop worrying about any Python 2/3 support.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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 compare C1(0) and C2(0), because neither one is an instance of the
> other's type. The test to get this case to work would be expensive: find the
> common ancestor, and then make sure no fields have been added since then.
> And I haven't thought through multiple inheritance.
>
> I suggest we don't try to support this case.

That gets you onto problematic ground as far as transitivity is
concerned, since you'd end up with the following:

>>> b = B(0); c1 = C1(0); c2 = C2(0)
>>> c1 == b
True
>>> b == c2
True
>>> c1 == c2
False

However, I think you can fix this by injecting the first base in the
MRO that defines a data field as a "__field_layout__" class attribute,
and then have the comparison methods check for "other.__field_layout__
is self.__field_layout__", rather than checking the runtime class
directly.

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

It would then be up to the dataclass decorator to set
`__field_layout__` correctly, using the follow rules:

1. Use the just-defined class if the class defines any fields
2. Use the just-defined class if it inherits from multiple base
classes that define fields and don't already share an MRO
3. Use a base class if that's either the only base class that defines
fields, or if all other base classes that define fields are already in
the MRO of that base class

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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 and guarantee that behavior.

Right, I think the main implication here would be that we need to
ensure that any signature manipulation operations *we* provide are
order preserving.

Fortunately for Larry, we kinda cheat on that front: all the logic for
dealing with this problem is in the inspect module itself, which knows
about all the different ways we manipulate signatures in the standard
library. That means that if we want to declare that the inspect module
will be order preserving, we can, and it shouldn't require changes to
anything else.

Cheers,
Nick.

P.S. Note that inspect.getfullargspec() was actually undeprecated a
while back - enough folks that didn't need access to the function
annotations were reimplementing it for themselves "because the
standard library API is deprecated" that the most logical course of
action was to just declare it as being supported again. I don't think
that changes the argument here though - it just means guaranteed order
preservation in that API will only happen if we declare dicts to be
insertion ordered in general.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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:
https://github.com/python/peps/commit/aaa64f53d0434724384b056a3c195d63a5cc3761

> - I would recommend adding a note to the abstract about the recommendation
> for test runners to also enable these warnings by default.

Done.

> - Would be nice to know whether IPython/Jupyter is happy with this.

They implemented a solution along these lines some time ago, so I've
added a new subsection with advice for folks writing interactive
shells, and quoted their warnings.filterwarnings call as an example of
how to do it (with a link to the relevant line in their repo).

> - The sentence "As a result, API deprecation warnings encountered by
> development tools written in Python should continue to be hidden by default
> for users of those tools" is missing a final period; I also think that the
> argument here is stronger if "development" is left out. (Maybe development
> tools could be called out in a "for example" clause.)

I ended up rewording that paragraph completely (partly prompted by
your comment about the impact on single file scripts).

> - I can't quite put my finger on it, but reading the three bullets of
> distinct categories of warnings something seems slightly off, perhaps due to
> independent editing of various phrases. Perhaps the three bullets could be
> rewritten for better correspondence between the various properties and
> audiences? And what should test runners do for each?

I think I was trying to do too much in that list of categories, so I
moved everything related to test runners out to a new dedicated
section.

That means the list of categories can focus solely on the actual
defaults, while the new test runner section describes how we expect
test runners to override that.

I also noticed something that seemed worth mentioning in relation to
BytesWarning, which is that "-Wd" works as well as it does because the
interpreter doesn't even *try* to emit those warnings if you don't
pass "-b" or "-bb" on the command line. The warnings filter only
handles the "Should it be a warning or an exception?" part.

> - Also, is SyntaxWarning worth adding to the list?

I *haven't* added this, since our only current syntax warning that I
can see is the one for "assert ('always', 'true')", and we've been
more inclined to go down the DeprecationWarning->SyntaxError path in
recent years than we have to settle for a persistent syntax warning.

> - The thing about FutureWarning being present since 2.3 feels odd -- if your
> library cares about supporting 2.7 and higher, should it use FutureWarning
> or DeprecationWarning?

I reworded this paragraph to make it more prescriptive and say "Use
DeprecationWarning on 3.7+, use FutureWarning on earlier versions if
you don't think the way they handle DeprecationWarning is noisy
enough")

> - "re-enabling deprecation warnings by default in __main__ doesn't help in
>   handling cases where software has been factored out into support modules,
> but
>   those modules still have little or no automated test coverage."
>   This and all bullets in the same list should have an initial capital
> letter and trailing period.

Fixed.

> This sentence in particular also reads odd: the
> "but" seems to apply to everything that comes before, but actually is meant
> to apply only to "cases where ...". Maybe rephrasing this can help the
> sentence flow better.

I missed this comment initially. Follow-up commit to reword that
sentence: 
https://github.com/python/peps/commit/47ea35f0510dab2b01e18ff437f95c6b1b75f2e6

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com