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

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.

Re: [Python-Dev] Definition of equality check behavior

[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

Re: [Python-Dev] Hello

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

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

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,

Re: [Python-Dev] Definition of equality check behavior

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 do

Re: [Python-Dev] Definition of equality check behavior

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 P

Re: [Python-Dev] Definition of equality check behavior

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 m

Re: [Python-Dev] Definition of equality check behavior

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 instea

[Python-Dev] Definition of equality check behavior

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

Re: [Python-Dev] PEP 574 ready for review

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

Re: [Python-Dev] Hello

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

[Python-Dev] PEP 578 accepted

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 w

[Python-Dev] Hello

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 sm

[Python-Dev] Adding a tzidx cache to datetime

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

Re: [Python-Dev] PEP 574 ready for review

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

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

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

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

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

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

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

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 p

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

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

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

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

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

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 ___ P

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

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 f

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

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 wou