Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3
Steven D'Aprano : > So not all Python 3 migration stories turn into horror stories :-) Peter Donis and wrote "Practical Python porting for systems programmers": http://www.catb.org/esr/faqs/practical-python-porting/ We developed and applied these techniques on src (a lightweight version-control system for single-contributor projects), reposurgeon (a tool for surgery on version-control repositories, 14KLOC), doclifter (man-page to XML-DocBook markup lifter, 8KLOC), the Python components of GPSD (9KLOC) and the Python components of NTPSec (secure network time service, 16KLOC). All this code runs under either 2 nor 3 without requiring six or any other shim library. Applying the techniques is not particularly difficult. There were no horror stories at any point. I expect to keep writing Python in this polyglot idiom until 2 is obsolete enough to fall off the radar. -- http://www.catb.org/~esr/";>Eric S. Raymond My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 572 and f-strings
I don't think it matters to its acceptance, but PEP 572 should at least
mention that the := syntax means that you cannot use assignment
expressions in f-strings.
As I wrote in a python-ideas email, f'{x:=4}' already has a defined
meaning (even if no one is using it).
Eric
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3
> I have found 2to3 conversion to be remarkably easy and painless. > And the whole Unicode thing is much easier. The intersection of bytes, str and unicode has been the only pain point for me. Everything else I've encountered has been pretty trivial. Skip ___ Python-Dev mailing list [email protected] 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 572 and f-strings
On Sat, May 12, 2018 at 9:11 PM, Eric V. Smith wrote:
> I don't think it matters to its acceptance, but PEP 572 should at least
> mention that the := syntax means that you cannot use assignment expressions
> in f-strings.
>
> As I wrote in a python-ideas email, f'{x:=4}' already has a defined meaning
> (even if no one is using it).
As with lambda functions, you can't write them the simple way.
However, you can parenthesize it, and then it works fine.
>>> f"@{(lambda: 42)}@"
'@ at 0x7f09e18c4268>@'
>>> f"@{(y := 1)}@"
'@1@'
>>> y
1
ChrisA
___
Python-Dev mailing list
[email protected]
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 572 and f-strings
> On May 12, 2018, at 9:03 AM, Chris Angelico wrote:
>
>> On Sat, May 12, 2018 at 9:11 PM, Eric V. Smith wrote:
>> I don't think it matters to its acceptance, but PEP 572 should at least
>> mention that the := syntax means that you cannot use assignment expressions
>> in f-strings.
>>
>> As I wrote in a python-ideas email, f'{x:=4}' already has a defined meaning
>> (even if no one is using it).
>
> As with lambda functions, you can't write them the simple way.
> However, you can parenthesize it, and then it works fine.
>
f"@{(lambda: 42)}@"
> '@ at 0x7f09e18c4268>@'
f"@{(y := 1)}@"
> '@1@'
y
> 1
>
Yes, but just as PEP 498 mentions lambdas, I think 572 should mention
f-strings, and point out this workaround.
Eric
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 554 - strange random boldface
Does anyone know why some lines in the tables of https://www.python.org/dev/peps/pep-0554/ appear in bold when the markup doesn't seem to call for it? I can't find a way to stop this, and it's bugging me! regards Steve ___ Python-Dev mailing list [email protected] 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 554 - strange random boldface
On Sat, 12 May 2018 15:20:11 +0100 Steve Holden wrote: > Does anyone know why some lines in the tables of > https://www.python.org/dev/peps/pep-0554/ appear in bold when the markup > doesn't seem to call for it? I can't find a way to stop this, and it's > bugging me! Apparently this may have to do with the given table cells being laid out in multiple lines? Regards Antoine. ___ Python-Dev mailing list [email protected] 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 554 - strange random boldface
It's certainly true that when I split any of those left-hand cells the bizarre emphasis occurs. Still looking for a workaround. regards Steve Steve Holden On Sat, May 12, 2018 at 3:26 PM, Antoine Pitrou wrote: > On Sat, 12 May 2018 15:20:11 +0100 > Steve Holden wrote: > > Does anyone know why some lines in the tables of > > https://www.python.org/dev/peps/pep-0554/ appear in bold when the markup > > doesn't seem to call for it? I can't find a way to stop this, and it's > > bugging me! > > Apparently this may have to do with the given table cells being laid out > in multiple lines? > > Regards > > Antoine. > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > steve%40holdenweb.com > ___ Python-Dev mailing list [email protected] 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 554 - strange random boldface
On Sat, 12 May 2018 15:48:47 +0100 Steve Holden wrote: > It's certainly true that when I split any of those left-hand cells the > bizarre emphasis occurs. Still looking for a workaround. Depending on whether you indent the second line it might be interpreted as a definition list item: http://docutils.sourceforge.net/docs/user/rst/quickref.html#definition-lists Regards Antoine. ___ Python-Dev mailing list [email protected] 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 554 - strange random boldface
12.05.18 17:48, Steve Holden пише: It's certainly true that when I split any of those left-hand cells the bizarre emphasis occurs. Still looking for a workaround. Remove an extra indentation of the second line. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3
[esr] > All this code runs under either 2 nor 3 without requiring six or any other > shim library. We've got an application that's about 500k loc, runs under both 2 and 3. It has only one shim, a 'metaclass' decorator similar to what six provides, other than that it's all quite clean 2- and 3-wise. We long ago adopted "from __future__" as a standard part of every source file, so we have internalized the Py3 print, division and import behaviors as the norm. An occasion scan with 2to3 kept us honest about list-producing vs iterator-producing functions, and renamings and such. Our major pain point was getting extension libraries that worked with 3, notably VTK and wxPython, which weren't ported completely until last year. We had been ready to switch over completely to Py3 almost four years ago, but those major pieces were missing. We have a production ready version running under 3.6, but are going to wait for the 3.7 release before cutting off support for Python 2 altogether. Of note, we did not have any Unicode issues, as we adopted wxPython's Unicode version as soon as it was available (6-7 years ago?), and had virtually no issues then or since. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
