Re: [Python-Dev] Easier debugging with f-strings

[Steve Holden]

What's not to like?


On Tue, May 7, 2019 at 2:31 AM Glenn Linderman 
wrote:

> On 5/6/2019 5:39 PM, Eric V. Smith wrote:
>
> Last fall Larry Hastings made a suggestion for adding a way to make
> so-called "print-based debugging" easier with f-strings. Basically the
> approach is that f-strings would be able to produce the text of the
> expression and the value of that expression, without repeating the
> expression in the f-sting. No more writing f'foo={foo}, bar={bar}'. foo and
> bar should each only be in there once each!
>
>
> My plan is to commit this change before 3.8b1. If anyone would like to
> discuss it at PyCon, I'll be around until about 10:30 am on Tuesday. I'll
> be in the CPython sprint room, and I'll be watching bpo, too.
>
>
> Yes, I'd like this yesterday, please :)  Thanks!
> ___
> 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] Easier debugging with f-strings

[Paul Moore]

On Tue, 7 May 2019 at 01:43, Eric V. Smith  wrote:
> After that lightning talk, Larry and I talked about it some more, and
> for a number of reasons decided that it would make more sense if the
> syntax used an = sign. So we came up with f"{foo=}", which would also
> produce "foo='Hello'".

Works for me. Whatever the spelling, I expect I'll use this a lot - thanks :-)

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] Easier debugging with f-strings

[Barry Warsaw]

On May 7, 2019, at 03:52, Steve Holden  wrote:
> 
> What's not to like?

My only complaint is that you steadfastly refuse use Guido’s time machine keys 
to make this available in 3.7.

-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] Easier debugging with f-strings

[Larry Hastings]

Guido just stopped by--we're all at the PyCon 2019 dev sprints--and we 
had a chat about it.  Guido likes it but wanted us to restore a little 
of the magical behavior we had in "!d": now, = in f-strings will default 
to repr (!r), /unless/ you specify a format spec. If you specify a 
format spec it will always default to format.  And naturally if you 
specify an explicit conversion function (!r !s !a) it will use that.


This makes !f irrelevant, so we're removing it.

Here's the thinking: 99% of the time the user will just use {foo=}, and 
for that you want repr.  After that, 0.99% of the time the user will 
want a format spec that applies directly the value. It's exceedingly 
unlikely that someone will want a format spec, but want it to apply to 
repr(value) and not value itself.  So that's /possible/ 
(f'{foo=!r:20}').  But the default behavior is the most common case at 
every step.



"So, is it checked in?" --GvR,


//arry/


On 5/6/19 8:39 PM, Eric V. Smith wrote:
Last fall Larry Hastings made a suggestion for adding a way to make 
so-called "print-based debugging" easier with f-strings. Basically the 
approach is that f-strings would be able to produce the text of the 
expression and the value of that expression, without repeating the 
expression in the f-sting. No more writing f'foo={foo}, bar={bar}'. 
foo and bar should each only be in there once each!


At PyCon US 2019 I did a lightning talk about this, suggesting the 
syntax of !d, so that if foo="Hello", then f"{foo!d}" would produce 
"foo='Hello'". That is, it's the text of the expression, followed by 
an equal sign, followed by the repr of the expression. I have 
implemented this and a PR exists. Arbitrary expressions are allowed. I 
heard from core devs and end users after this talk, and all were 
positive.


After that lightning talk, Larry and I talked about it some more, and 
for a number of reasons decided that it would make more sense if the 
syntax used an = sign. So we came up with f"{foo=}", which would also 
produce "foo='Hello'".


The reasons for the change are:
- Having '=' in the expression is a better mnemonic than !d.
- By not using a conversion starting with !, we can compose = with the 
existing ! conversions, !r, !s, and the rarely used !a.

- We can let the user have a little more control of the resulting string.

Another thing I like about this approach over !d is that the patch is 
simpler, because there are fewer special cases. And because there are 
fewer special cases in the code, I think the proposal is easier to 
explain than !d (in particular how it interacts (or doesn't!) with 
format specifiers).


There's a good rationale here, along with a PR: 
https://bugs.python.org/issue36817.


My plan is to commit this change before 3.8b1. If anyone would like to 
discuss it at PyCon, I'll be around until about 10:30 am on Tuesday. 
I'll be in the CPython sprint room, and I'll be watching bpo, too.


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/larry%40hastings.org
___
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] Easier debugging with f-strings

[Skip Montanaro]

> My only complaint is that you steadfastly refuse use Guido’s time machine 
> keys to make this available in 3.7.

Wait a minute, Barry. You mean you don't already have an Emacs
function to do the rewriting as a pre-save-hook?

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

[Python-Dev] [RELEASE] Python 3.8.0a4 is now available for testing

[Łukasz Langa]

It's time for the LAST alpha of Python 3.8.0. Go get it here:
https://www.python.org/downloads/release/python-380a4/ 


Python 3.8.0a4 is the fourth and final alpha release of Python 3.8,
the next feature release of Python.  During the alpha phase, Python 3.8
remains under heavy development: additional features will be added
and existing features may be modified or deleted.  Please keep in mind
that this is a preview release and its use is not recommended for
production environments.  The first beta release, 3.8.0b1, is planned
for 2019-05-31.

The release has slipped a week because of me being overwhelmed
with PyCon US this year.  There was also a release blocker and
a breaking change to ElementTree.  Anyway, sorry for the wait!
I moved the planned date of beta1 a few days to make up for it.

If you have a feature you're working on and you'd like to see it in
3.8.0, NOW IS THE TIME TO ACT. Please don't wait until May 30th,
get a proper review and land your change as soon as possible.

Q: Can I get my feature in after that date if I ask nicely?
A: Yes, of course. I will release it in Python 3.9.

- Ł


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] Easier debugging with f-strings

[Eric V. Smith]

On 5/7/19 9:49 AM, Barry Warsaw wrote:

On May 7, 2019, at 03:52, Steve Holden  wrote:


What's not to like?


My only complaint is that you steadfastly refuse use Guido’s time machine keys 
to make this available in 3.7.


Open a feature request here: https://github.com/asottile/future-fstrings

!

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] Easier debugging with f-strings

[Tim Peters]

[Larry Hastings ]
> Guido just stopped by--we're all at the PyCon 2019 dev sprints--and we had
> a chat about it.  Guido likes it but wanted us to restore a little of the 
> magical
> behavior we had in "!d": now, = in f-strings will default to repr (!r), unless
> you specify a format spec. If you specify a format spec it will always default
> to format.  And naturally if you specify an explicit conversion function (!r 
> !s !a)
> it will use that.
>
> This makes !f irrelevant, so we're removing it.
>
> Here's the thinking: 99% of the time the user will just use {foo=}, and for 
> that
> you want repr.  After that, 0.99% of the time the user will want a format spec
> that applies directly the value.  It's exceedingly unlikely that someone will
> want a format spec, but want it to apply to repr(value) and not value itself. 
>  So
> that's possible (f'{foo=!r:20}').  But the default behavior is the most common
> case at every step.

+1.  Perfect!  I'm one of the 0.99% who will frequently use this to
display floats, and really wants them to show as "0.99%" rather than
"0.9913499340289%".

BTW, that Guido person has made enough decent contributions by now
that I think he should be asked whether he wants to become a core dev!
___
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] Easier debugging with f-strings

[Eric V. Smith]

Hi, Tim. 

Your name came up frequently as a target for this use case. I think we’ve come 
up with a pretty good solution. 

Now if I could only convince my clients to upgrade from 2.7! I’ve heard about 
these f-string things, and I think I would enjoy using them. 

Eric

> On May 7, 2019, at 12:50 PM, Tim Peters  wrote:
> 
> [Larry Hastings ]
>> Guido just stopped by--we're all at the PyCon 2019 dev sprints--and we had
>> a chat about it.  Guido likes it but wanted us to restore a little of the 
>> magical
>> behavior we had in "!d": now, = in f-strings will default to repr (!r), 
>> unless
>> you specify a format spec. If you specify a format spec it will always 
>> default
>> to format.  And naturally if you specify an explicit conversion function (!r 
>> !s !a)
>> it will use that.
>> 
>> This makes !f irrelevant, so we're removing it.
>> 
>> Here's the thinking: 99% of the time the user will just use {foo=}, and for 
>> that
>> you want repr.  After that, 0.99% of the time the user will want a format 
>> spec
>> that applies directly the value.  It's exceedingly unlikely that someone will
>> want a format spec, but want it to apply to repr(value) and not value 
>> itself.  So
>> that's possible (f'{foo=!r:20}').  But the default behavior is the most 
>> common
>> case at every step.
> 
> +1.  Perfect!  I'm one of the 0.99% who will frequently use this to
> display floats, and really wants them to show as "0.99%" rather than
> "0.9913499340289%".
> 
> BTW, that Guido person has made enough decent contributions by now
> that I think he should be asked whether he wants to become a core dev!
> ___
> 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/eric%2Ba-python-dev%40trueblade.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] PEP 574 ready for review

[Antoine Pitrou]

Should I submit a PR to change the PEP status or would you like to do
it?

Regards

Antoine.


On Wed, 1 May 2019 12:49:24 -0700
Nick Coghlan  wrote:
> Thanks Antoine.
> 
> As BDFL-Delegate I'm happy with this version of the PEP, so it's my
> pleasure to accept it for inclusion in Python 3.8.
> 
> Regards,
> Nick.
> 

___
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] Adding a tzidx cache to datetime

[Paul Ganssle]

Greetings all,

I have one last feature request that I'd like added to datetime for
Python 3.8, and this one I think could use some more discussion, the
addition of a "time zone index cache" to the /datetime/ object. The
rationale is laid out in detail in bpo-35723
. The general problem is that
currently, /every/ invocation of utcoffset, tzname and dst needs to do
full, independent calculations of the time zone offsets, even for time
zones where the mapping is guaranteed to be stable because datetimes are
immutable. I have a proof of concept implementation: PR #11529
.

I'm envisioning that the `datetime` class will add a private `_tzidx`
single-byte member (it seems that this does not increase the size of the
datetime object, because it's just using an unused alignment byte).
`datetime` will also add a `tzidx()` method, which will return `_tzidx`
if it's been set and otherwise it will call `self.tzinfo.tzidx()`.  If
`self.tzinfo.tzidx()` returns a number between 0 and 254 (inclusive), it
sets `_tzidx` to this value. tzidx() then returns whatever
self.tzinfo.tzidx() returned.

The value of this is that as far as I can tell, nearly all non-trivial
tzinfo implementations construct a list of possible offsets, and
implement utcoffset(), tzname() and dst() by calculating an index into
that list and returning it. There are almost always less than 255
distinct offsets. By adding this cache /on the datetime/, we're using a
small amount of currently-unused memory to prevent unnecessary
calculations about a given datetime. The feature is entirely opt-in, and
has no downsides if it goes unused, and it makes it possible to write
tzinfo implementations that are both lazy and as fast as the "eager
calculation" mode that pytz uses (and that causes many problems for
pytz's users).

I have explored the idea of using an lru cache of some sort on the
tzinfo object itself, but there are two problems with this:

1. Calculating the hash of a datetime calls .utcoffset(), which means
that it is necessary to, at minimum, do a `replace` on the datetime (and
constructing a new datetime is a pretty considerable speed hit)

2. It will be a much bigger memory cost, since my current proposal uses
approximately zero additional memory (not sure if the alignment stuff is
platform-dependent or something, but it doesn't use additional memory on
my linux computer).

I realize this proposal is somewhat difficult to wrap your head around,
so if anyone would like to chat with me about it in person, I'll be at
PyCon sprints until Thursday morning.

Best,
Paul



signature.asc
Description: OpenPGP digital signature
___
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] Hello

[Ben Kane]

My name is Ben Kane. I'm joining this mailing list and introducing myself
as asked in the "welcome to python-dev" email. I've been using Python for
maybe 7 years now. I started to learn it in college to help with accounting
homework and I continue to use it now for personal projects ranging from
small scripts to larger applications and in my day job as a LinkedIn Site
Reliability Engineer.

I'd like to contribute back to the language that's helped me so much; and
talking with core devs at PyCon 2019 has really encouraged me. So I'll be
lurking and trying to pick things up as I see them.

Thanks!
-- 

Ben Kane
___
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] PEP 578 accepted

[Christian Heimes]

Hi,

Steve and I worked on the final touch of the PEP during PyCon. PEP 578
[1] is now ready. As the BDFL delegate I'm honoured to accept Steve's PEP.

There is a very slim possibility that the PEP implementation might need
adjustment for Linux. I haven't got feedback from a Red Hat engineer
that works on Linux Kernel Auditing team. Everybody is busy with RHEL 8
release and the Red Hat Summit in Boston. I don't anticipate any changes
to the PEP itself. After some consideration I decided to accept PEP now
to give Steve enough time to push and test his implementation. There is
sufficient time to address issues until the first release candidate of
3.8.0.

Thanks Steve, it's been a privilege to work with you!

Christian

[1] https://www.python.org/dev/peps/pep-0578/
___
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] Hello

[Victor Stinner]

Welcome Ben!

Le mar. 7 mai 2019 à 16:28, Ben Kane  a écrit :
> My name is Ben Kane. I'm joining this mailing list and introducing myself as 
> asked in the "welcome to python-dev" email. I've been using Python for maybe 
> 7 years now. I started to learn it in college to help with accounting 
> homework and I continue to use it now for personal projects ranging from 
> small scripts to larger applications and in my day job as a LinkedIn Site 
> Reliability Engineer.
>
> I'd like to contribute back to the language that's helped me so much; and 
> talking with core devs at PyCon 2019 has really encouraged me. So I'll be 
> lurking and trying to pick things up as I see them.

python-dev is not the proper mail to introduce yourself to contribute.
I suggest you to start reading http://devguide.python.org/ and please
send the same email to core-mentorship mailing list:
https://mail.python.org/mailman3/lists/core-mentorship.python.org/?x=22

It would help if you can elaborate on which parts of Python you would
be interested to contribute ;-)

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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 574 ready for review

[Victor Stinner]

You can do it. I like when the acceptance email is linked from the PEP ;-)

Victor

Le mar. 7 mai 2019 à 14:12, Antoine Pitrou  a écrit :
>
>
> Should I submit a PR to change the PEP status or would you like to do
> it?
>
> Regards
>
> Antoine.
>
>
> On Wed, 1 May 2019 12:49:24 -0700
> Nick Coghlan  wrote:
> > Thanks Antoine.
> >
> > As BDFL-Delegate I'm happy with this version of the PEP, so it's my
> > pleasure to accept it for inclusion in Python 3.8.
> >
> > Regards,
> > Nick.
> >
>
> ___
> 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/vstinner%40redhat.com



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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] Definition of equality check behavior

[Jordan Adler]

Hey folks!

Through the course of work on the future polyfills
 that mimic the
behavior of Py3 builtins across versions of Python, we've discovered that
the equality check behavior of at least some builtin types do not
match the documented
core data model
.

Specifically, a comparison between a primitive (int, str, float were
tested) and an object of a different type always return False, instead of
raising a NotImplementedError.  Consider `1 == '1'` as a test case.

Should the data model be adjusted to declare that primitive types are
expected to fallback to False, or should the cpython primitive type's
__eq__ implementation fallback to raise NotImplementedError?

Reasonable people could disagree about the right approach, but my distaste
for silent failures leads me to recommend that the implementation be
adjusted to return NotImplementedError as a fallback, and to document that
the operands should not be coerced to the same type prior to comparison
(enforcing a stricter equality check). This will of course require a
deprecation protocol.

Alternatively some new equality operator could be used to specify the level
of coercion/type checking desired (currently Python has 'is' and '==').

Jordan
___
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] Definition of equality check behavior

[Max Vogler]

Thanks for starting this discussion and addressing my issue, Jordan.

I would like to clarify the intentions behind my original issue
: It does not
concern coercion in Python's __eq__. Instead, the issue concerns the return
of False instead of NotImplemented in future.types.newstr.__eq__. As a
result, in special cases this breaks the symmetry of equality.

Also, please be aware of the difference between NotImplemented (a singleton
that is used as indicator for an unimplemented equality operation) and
NotImplementedError
, a
RuntimeError used for example in abstract classes. To quote from the docs:
> NotImplementedError and NotImplemented are not interchangeable, even
though they have similar names and purposes.

On Tue, May 7, 2019 at 11:06 PM Jordan Adler 
wrote:

> Hey folks!
>
> Through the course of work on the future polyfills
>  that mimic
> the behavior of Py3 builtins across versions of Python, we've discovered
> that the equality check behavior of at least some builtin types do not
> match the documented core data model
> .
>
> Specifically, a comparison between a primitive (int, str, float were
> tested) and an object of a different type always return False, instead of
> raising a NotImplementedError.  Consider `1 == '1'` as a test case.
>
> Should the data model be adjusted to declare that primitive types are
> expected to fallback to False, or should the cpython primitive type's
> __eq__ implementation fallback to raise NotImplementedError?
>
> Reasonable people could disagree about the right approach, but my distaste
> for silent failures leads me to recommend that the implementation be
> adjusted to return NotImplementedError as a fallback, and to document that
> the operands should not be coerced to the same type prior to comparison
> (enforcing a stricter equality check). This will of course require a
> deprecation protocol.
>
> Alternatively some new equality operator could be used to specify the
> level of coercion/type checking desired (currently Python has 'is' and
> '==').
>
> Jordan
>
___
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] Definition of equality check behavior

[Steven D'Aprano]

On Tue, May 07, 2019 at 05:05:57PM -0400, Jordan Adler wrote:
[...]
> Specifically, a comparison between a primitive (int, str, float were
> tested) and an object of a different type always return False, instead of
> raising a NotImplementedError.  Consider `1 == '1'` as a test case.

I think you may be labouring under a few misapprehensions here.

1. Comparisons between builtins such as ints and objects of different 
types do not always return False:

py> class X:
... def __eq__(self, other):
... return True
...
py> 123 == X()
True

You don't need a custom class to demonstrate this fact, you just need 
values which actually are equal:

py> 123 == 1.23e2  # int compared to float
True


2. Comparisons are not supposed to raise NotImplementedError as part of 
the core data model, they are supposed to return (not raise) 
NotImplemented. Note that NotImplementedError is a completely different 
thing).

As the documentation you linked to says:

A rich comparison method may return the singleton NotImplemented 
if it does not implement the operation for a given pair of 
arguments.



3. Equality does not suppress exceptions and lead to silent failure:

py> class Y:
... def __eq__(self, other):
... raise NotImplementedError
...
py> 123 == Y()
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 3, in __eq__
NotImplementedError


Hope this helps.



-- 
Steven
___
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] Definition of equality check behavior

[Steven D'Aprano]

On Wed, May 08, 2019 at 12:05:07AM +0200, Max Vogler wrote:
> Thanks for starting this discussion and addressing my issue, Jordan.
> 
> I would like to clarify the intentions behind my original issue
> : It does not
> concern coercion in Python's __eq__. Instead, the issue concerns the return
> of False instead of NotImplemented in future.types.newstr.__eq__. 

Unless there is something special about newstr that it should force an 
unequal result, it should return NotImplemented when comparing to types 
it knows nothing about.

I'm reluctant to outright declare a class I know nothing about in a 
library I don't understand is buggy, but on the face of it, if 
newstr.__eq__ doesn't return NotImplemented, it probably is buggy.

If so, newstr is in good company: failure to return NotImplemented is a 
very common bug in third-party code. I've written heaps of classes that 
wrongly force a False result. But I've learned better and don't do it 
any more :-)



-- 
Steven
___
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] Definition of equality check behavior

[Ethan Furman]

On 05/07/2019 02:05 PM, Jordan Adler wrote:


Specifically, a comparison between a primitive (int, str, float were
 tested) and an object of a different type always return False,
 instead of raising a NotImplementedError.  Consider `1 == '1'` as a
 test case.


If the object of a different type doesn't support comparing to an int, str, or 
float then False is the correct answer.  On the other hand, if the object of a 
different type wants to compare equal to, say, ints then it will have to supply 
its own __eq__ method to return False/True as appropriate.



Should the data model be adjusted to declare that primitive types are
 expected to fallback to False


No, because they aren't.


or should the cpython primitive type's __eq__ implementation fallback
 to raise NotImplementedError?


No, because raising an error is not appropriate.  Did you mean `return 
NotImplemented`?  Because empirical evidence suggests that they do:

---
class MyCustomInt():
def __init__(self, value):
self.value = value
def __eq__(self, other):
if isinstance(other, int):
return self.value == other
else:
return NotImplemented
def __ne__(self, other):
if isinstance(other, int):
return self.value != other
else:
return NotImplemented

core_int = 7
my_int = MyCustomInt(7)

print(core_int == my_int)  # True
print(my_int == core_int)  # True
---

If the core types were not returning NotImplemented then the above would be 
False on the `core_int == my_int` line.

Hopefully this is clearer now?

--
~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] Easier debugging with f-strings

[Steven D'Aprano]

Disclaimer: this topic seems to have been split over at least two issues 
on the bug tracker, a Python-Ideas thread from 2018, Discourse (I 
think...) and who knows what else. I haven't read it all, so excuse me 
if I'm raising something already discussed.

On Mon, May 06, 2019 at 08:39:41PM -0400, Eric V. Smith wrote:

> After that lightning talk, Larry and I talked about it some more, and 
> for a number of reasons decided that it would make more sense if the 
> syntax used an = sign. So we came up with f"{foo=}", which would also 
> produce "foo='Hello'".
> 
> The reasons for the change are:
> - Having '=' in the expression is a better mnemonic than !d.
> - By not using a conversion starting with !, we can compose = with the 
> existing ! conversions, !r, !s, and the rarely used !a.
> - We can let the user have a little more control of the resulting string.

You're going to hate me for bike-shedding, but I really don't like using 
= as a defacto unary postfix operator. To me, spam= is always going to 
look like it was meant to be spam== and the second half got 
accidentally deleted.

I don't have a better suggestion, sorry.

In an earlier draft, back when this was spelled !d, you specifically 
talked about whitespace. Does this still apply?

spam = 42
f'{spam=}'  # returns 'spam=42'
f'{spam =}'  # returns 'spam =42'
f'{spam = }'  # returns 'spam = 42' I guess?
f'{spam+1=}'  # returns 'spam+1=41' I guess?




-- 
Steven
___
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] Hello

[Ben Kane]

Sorry Victor, I must have misinterpreted this snippet from the mailbot.
Maybe it would be a good idea to re-word it? I'll be happy to open an issue
for that in an appropriate mailing list if you think that would help.

> Welcome to the Python-Dev@python.org mailing list! If you are a new
subscriber, please take the time to introduce yourself briefly in your
first post. It is appreciated if you lurk around for a while before
posting! :-)

I talked to Barry Warsaw about https://bugs.python.org/issue36837 and he
said I should post to python-dev to get feedback. I'll work on that email
and post back here once I'm happy with it.

Thanks,
Ben


On Tue, May 7, 2019 at 4:47 PM Victor Stinner  wrote:

> Welcome Ben!
>
> Le mar. 7 mai 2019 à 16:28, Ben Kane  a écrit :
> > My name is Ben Kane. I'm joining this mailing list and introducing
> myself as asked in the "welcome to python-dev" email. I've been using
> Python for maybe 7 years now. I started to learn it in college to help with
> accounting homework and I continue to use it now for personal projects
> ranging from small scripts to larger applications and in my day job as a
> LinkedIn Site Reliability Engineer.
> >
> > I'd like to contribute back to the language that's helped me so much;
> and talking with core devs at PyCon 2019 has really encouraged me. So I'll
> be lurking and trying to pick things up as I see them.
>
> python-dev is not the proper mail to introduce yourself to contribute.
> I suggest you to start reading http://devguide.python.org/ and please
> send the same email to core-mentorship mailing list:
> https://mail.python.org/mailman3/lists/core-mentorship.python.org/?x=22
>
> It would help if you can elaborate on which parts of Python you would
> be interested to contribute ;-)
>
> Victor
> --
> Night gathers, and now my watch begins. It shall not end until my death.
>


-- 

Ben Kane
___
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] Definition of equality check behavior

[Tim Peters]

[Jordan Adler ]
> Through the course of work on the future polyfills that mimic the behavior
> of Py3 builtins across versions of Python, we've discovered that the
> equality check behavior of at least some builtin types do not match the
> documented core data model.
>
> Specifically, a comparison between a primitive (int, str, float were tested)
> and an object of a different type always return False, instead of raising
> a NotImplementedError.  Consider `1 == '1'` as a test case.
>
> Should the data model be adjusted to declare that primitive types are
> expected to fallback to False, or should the cpython primitive type's
> __eq__ implementation fallback to raise NotImplementedError?

Nope ;-)  This isn't a "data model" issue.  Look instead at the
Standard Library manual's section on Built-In Types, under heading
Comparisons:

"""
Objects of different types, except different numeric types, never
compare equal. ...
The <, <=, > and >= operators will raise a TypeError exception when
comparing a complex number with another built-in numeric type, when
the objects are of different types that cannot be compared, or in
other cases where there is no defined ordering.
"""

It's not an object's responsibility to arrange for that.  It's done
for them by default, and objects only need to supply their own rich
comparison methods if they don't want the defaults.  For example, when
comparing an int with another type, all the int rich comparison
methods _do_ return NotImplemented:

>>> f = 4
>>> f.__eq__("abc")
NotImplemented

It's at a higher level that comparison logic says "OK, I gave both
comparands a chance, and they both returned NotImplemented.  So one
last chance (from object.c's do_richcompare())":

/* If neither object implements it, provide a sensible default
   for == and !=, but raise an exception for ordering. */
switch (op) {
case Py_EQ:
res = (v == w) ? Py_True : Py_False;
break;
case Py_NE:
res = (v != w) ? Py_True : Py_False;
break;
default:
PyErr_Format(PyExc_TypeError,
 "'%s' not supported between instances of '%.100s'
and '%.100s'",
 opstrings[op],
 v->ob_type->tp_name,
 w->ob_type->tp_name);
return NULL;
}

Then the Py_EQ case of that delivers:

>>> f == "abc"
False

and the Py_NE case:

>>> f != "abc"
True

despite that (or because of that ;-) ):

>>> f.__eq__("abc")
NotImplemented
>>> "abc".__eq__(f)
NotImplemented

Note that there's nothing special about builtin types here.  All types
are treated alike.
___
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] Easier debugging with f-strings

[Eric V. Smith]

On 5/7/19 8:39 PM, Steven D'Aprano wrote:

Disclaimer: this topic seems to have been split over at least two issues
on the bug tracker, a Python-Ideas thread from 2018, Discourse (I
think...) and who knows what else. I haven't read it all, so excuse me
if I'm raising something already discussed.


Yeah, it's all over the place. At this stage, I think discussing it here 
is best.




On Mon, May 06, 2019 at 08:39:41PM -0400, Eric V. Smith wrote:


After that lightning talk, Larry and I talked about it some more, and
for a number of reasons decided that it would make more sense if the
syntax used an = sign. So we came up with f"{foo=}", which would also
produce "foo='Hello'".

The reasons for the change are:
- Having '=' in the expression is a better mnemonic than !d.
- By not using a conversion starting with !, we can compose = with the
existing ! conversions, !r, !s, and the rarely used !a.
- We can let the user have a little more control of the resulting string.


You're going to hate me for bike-shedding, but I really don't like using
= as a defacto unary postfix operator. To me, spam= is always going to
look like it was meant to be spam== and the second half got
accidentally deleted.

I don't have a better suggestion, sorry.


I think = makes a great mnemonic for what's happening. I realize it 
looks a little funny at first, but just wait until you start confusing 
it with := (hah!). Everyone else I've discussed it with likes =.



In an earlier draft, back when this was spelled !d, you specifically
talked about whitespace. Does this still apply?


Yes, it does.


spam = 42
f'{spam=}'  # returns 'spam=42'
f'{spam =}'  # returns 'spam =42'
f'{spam = }'  # returns 'spam = 42' I guess?


All correct.


f'{spam+1=}'  # returns 'spam+1=41' I guess?


I'm not proposing to redefine addition by one, so this is actually 
'spam+1=43' :)


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