Re: [Python-Dev] Language Summit Follow-Up
Chris Barker writes: that way. Saying that their very first easy program is: print(hello world) is fine I have had similar experience on a small scale. Also I've been teaching R recently. The students who know Python (Python 3, we don't have backward compatibility issues in our work) got the concept that all real work in R is done by functions, immediately. Those who don't, have trouble with the concept that help and q (for quit) need parentheses to get them to work. Unfortunately R doesn't have Python's Easter Eggs, so they get a code dump rather than help when they type the bare names. ___ 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] Language Summit Follow-Up
On Thu, May 29, 2014 at 4:43 AM, Nick Coghlan ncogh...@gmail.com wrote:
For that last point, my interest is as much educational as it is in
easing the transition from Python 2. The parentheses in print('Hello
world!') mean introducing the idea of function calls early to explain
how it works, while being able to omit them makes it easier to gloss
over the distinction between statements and function calls initially
and then cover it later after the basics of flow control have been
nailed down.
I've been doing a lot of intro-to-python teaching lately (py2 so far...),
and I understand this desire. IN fact, a lot of notes point to the fact
that python's hello world is simply : print hello world, rather than
what is required in some languages to do something that simple.
However, I also believe that when teaching it's better to introduce the
right way to do something up front, rather than a beginners' way, then
later say, well, you really SHOULD do it this other way... So if we want
our students to use print as a function, we might a well start them off
that way. Saying that their very first easy program is:
print(hello world)
is fine -- they don't have to know or understand what a function call is --
they simply copy the syntax. And frankly, we get to simple function calls,
VERY early in the program -- you can't really do anything without them...
In fact, in my latest class, we've made an effort to introduce
forward-thinking up front, even before we explain quite what it all means:
use ua string to make a string
you write a class like:
class C(object):
...
before we talk about subclassing, or what object is...
just my $0.02
-Chris
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/chris.barker%40noaa.gov
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/ORR(206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
chris.bar...@noaa.gov
___
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] Language Summit Follow-Up
On Thu, May 29, 2014 at 9:30 AM, Terry Reedy tjre...@udel.edu wrote: On 5/28/2014 6:26 PM, Glyph Lefkowitz wrote: I hope it's not controversial to say that most new Python code is still being written against Python 2.7 today; Given that Python 3 downloads now outnumber Python 2 downloads, I think 'most' might be an overstatement. But I think it a moot point. How can you determine that Python3 downloads actually outnumber Python2 downloads? It seems that looking at Windows downloads (as I saw in a thread earlier this month) is fallacious at absolute best. Linux and OSX both ship with Python2, and most downloads happen via individual package management tools. Even including Python3.4 as a default Python3 doesn't mean that it's the default Python on the system. From my perspective as an engineer and library maintainer: Pypi seems to indicate an overwhelming number of Python2 usage, and so do the job requisitions that I've seen. Furthermore, even Python based libraries for cutting edge technologies are still written in Python2 and later converted to Python3. I just don't understand how we (as a community) can make the assertion that most new Python is written in Python 3. What I'd really like to see is a Python 2.8 that makes sufficient changes to Python 2 that writing libraries which cross the boundary between 2 and 3 is relatively easy instead of a painful nightmarish chore. Because when push comes to shove, Python 2 support is still infinitely more important than Python 3. -Mark ___ 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] Language Summit Follow-Up
On Sat, May 31, 2014 at 3:40 AM, Mark Roberts wiz...@gmail.com wrote: What I'd really like to see is a Python 2.8 that makes sufficient changes to Python 2 that writing libraries which cross the boundary between 2 and 3 is relatively easy instead of a painful nightmarish chore. Because when push comes to shove, Python 2 support is still infinitely more important than Python 3. That's of absolutely ZERO value to anyone who has to maintain support for Python 2.3 or even 2.7. Will this hypothetical 2.8 run, unchanged, all code written for 2.7? If not, all you've done is add a third branch to maintain, and solved nothing; and if it will, how much can you really change? ChrisA ___ 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] Language Summit Follow-Up
On 30/05/2014 18:40, Mark Roberts wrote: What I'd really like to see is a Python 2.8 that makes sufficient changes to Python 2 that writing libraries which cross the boundary between 2 and 3 is relatively easy instead of a painful nightmarish chore. Because when push comes to shove, Python 2 support is still infinitely more important than Python 3. -Mark What is the point of flogging a horse that's been dead for so long that it's already down to a skeleton? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.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] Language Summit Follow-Up
On 05/30/2014 09:46 AM, Chris Barker wrote:
On Thu, May 29, 2014 at 4:43 AM, Nick Coghlan wrote:
For that last point, my interest is as much educational as it is in
easing the transition from Python 2. The parentheses in print('Hello
world!') mean introducing the idea of function calls early to explain
how it works, while being able to omit them makes it easier to gloss
over the distinction between statements and function calls initially
and then cover it later after the basics of flow control have been
nailed down.
However, I also believe that when teaching it's better to introduce the right
way to do something up front, rather
than a beginners' way, then later say, well, you really SHOULD do it this
other way...
+1
Function calls are not that hard to understand. Anybody who has ever asked someone to do something for them should have
a basic grasp of the nature of a function call.
--
~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] Language Summit Follow-Up
On Wed, 28 May 2014 15:26:38 -0700 Glyph Lefkowitz gl...@twistedmatrix.com wrote: Backport 'yield from' to allow people to use Tulip and Tulip-compatible code, and to facilitate the development of Tulip-friendly libraries and a Tulip ecosystem. A robust Tulip ecosystem requires the participation of people who are not yet using Python 3. I was wondering whether you were trolling or not on this one. From a quality assurance point of view, adding major features to a bugfix branch is extremely destructive, so I'm strongly -1 on it. Get rid of 2to3. Particularly, of any discussion of using 2to3 in the documentation. More than one very experienced, well-known Python developer in this discussion has told me that they thought 2to3 was the blessed way to port their code, and it's no surprise that they think so, given that the first technique https://docs.python.org/3/howto/pyporting.html mentions is still 2to3. 2to3 is certainly fine if you are porting to 3.x without looking to keep your code 2.x-compatible. Until there's a better alternative, of course. So what we should do is better explain the choice (if you want to port your code to 3.x, use 2to3; if you want to maintain dual-compatible code, use six or something similar). Regards Antoine. ___ 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] Language Summit Follow-Up
2to3 is poorly named. With different fixers it is a fine tool for converting 2-only code to 2-and-3 straddling code. Even when using six, you need to do things like convert print statements to print() calls with future import, use 'as' in except clauses, and so on. On Fri, May 30, 2014 at 1:47 PM, Antoine Pitrou solip...@pitrou.net wrote: On Wed, 28 May 2014 15:26:38 -0700 Glyph Lefkowitz gl...@twistedmatrix.com wrote: Backport 'yield from' to allow people to use Tulip and Tulip-compatible code, and to facilitate the development of Tulip-friendly libraries and a Tulip ecosystem. A robust Tulip ecosystem requires the participation of people who are not yet using Python 3. I was wondering whether you were trolling or not on this one. From a quality assurance point of view, adding major features to a bugfix branch is extremely destructive, so I'm strongly -1 on it. Get rid of 2to3. Particularly, of any discussion of using 2to3 in the documentation. More than one very experienced, well-known Python developer in this discussion has told me that they thought 2to3 was the blessed way to port their code, and it's no surprise that they think so, given that the first technique https://docs.python.org/3/howto/pyporting.html mentions is still 2to3. 2to3 is certainly fine if you are porting to 3.x without looking to keep your code 2.x-compatible. Until there's a better alternative, of course. So what we should do is better explain the choice (if you want to port your code to 3.x, use 2to3; if you want to maintain dual-compatible code, use six or something similar). Regards Antoine. ___ 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] Language Summit Follow-Up
On 31 May 2014 08:42, Guido van Rossum gu...@python.org wrote: 2to3 is poorly named. With different fixers it is a fine tool for converting 2-only code to 2-and-3 straddling code. Even when using six, you need to do things like convert print statements to print() calls with future import, use 'as' in except clauses, and so on. Both modernize futurize build on lib2to3 to do the heavy lifting - they don't reinvent that wheel, they just change which fixes are applied by default and add a few more of their own. However, even if going straight to Python 3, I suspect folks would still be better off doing something like: * futurize --stage1 (migrates to 2.6+, but adds no new runtime dependencies - the output should be fairly idiomatic Python 2.6/7 code) * 2to3 (wholesale migration to Python 3) The trick, though, is that the granularity of that approach is at the process level - the entire application must be converted at once. You also can't start your own migration until all your dependencies are available in Python 3. By contrast, migration via the common subset can be incremental and opportunistic: * the granularity of migration is individual modules, rather than entire processes, so you can make a low risk gradual transition, even without a comprehensive regression test suite * you initially stay on Python 2, so you can start whenever is convenient for you, rather than having to wait for all your dependencies Cheers, Nick. On Fri, May 30, 2014 at 1:47 PM, Antoine Pitrou solip...@pitrou.net wrote: On Wed, 28 May 2014 15:26:38 -0700 Glyph Lefkowitz gl...@twistedmatrix.com wrote: Backport 'yield from' to allow people to use Tulip and Tulip-compatible code, and to facilitate the development of Tulip-friendly libraries and a Tulip ecosystem. A robust Tulip ecosystem requires the participation of people who are not yet using Python 3. I was wondering whether you were trolling or not on this one. From a quality assurance point of view, adding major features to a bugfix branch is extremely destructive, so I'm strongly -1 on it. Get rid of 2to3. Particularly, of any discussion of using 2to3 in the documentation. More than one very experienced, well-known Python developer in this discussion has told me that they thought 2to3 was the blessed way to port their code, and it's no surprise that they think so, given that the first technique https://docs.python.org/3/howto/pyporting.html mentions is still 2to3. 2to3 is certainly fine if you are porting to 3.x without looking to keep your code 2.x-compatible. Until there's a better alternative, of course. So what we should do is better explain the choice (if you want to port your code to 3.x, use 2to3; if you want to maintain dual-compatible code, use six or something similar). Regards Antoine. ___ 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/ncoghlan%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] Language Summit Follow-Up
On 31 May 2014 02:47, Chris Barker chris.bar...@noaa.gov wrote: However, I also believe that when teaching it's better to introduce the right way to do something up front, rather than a beginners' way, then later say, well, you really SHOULD do it this other way... So if we want our students to use print as a function, we might a well start them off that way. Saying that their very first easy program is: print(hello world) is fine -- they don't have to know or understand what a function call is -- they simply copy the syntax. And frankly, we get to simple function calls, VERY early in the program -- you can't really do anything without them... OK, that's a fair criticism of that particular argument, so I'll stop using it. There are others, though: * improve consistency between IPython's existing implied call support and vanilla Python 3.5+ * retroactively make a lot of Python 2 examples also valid for Python 3.5+ * ease the migration to Python 3 for ad hoc utility scripts (which often use print heavily) * reduce the syntactic noise in migration patches (although large applications tend to use print less than scripts do) * largely eliminate one of the *human* barriers to migration from Python 2 (forgetting the parens for print at the interactive console and in ad hoc scripts) I already have too many other things on my todo list to work this up into a full PEP, but the proof of concept (along with IPython's existing support) shows there's no *technical* barrier to adding the feature. It's a question of whether or not we *want* to blur the boundary between simple statements and simple imperative function calls like that. Cheers, 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
Re: [Python-Dev] Language Summit Follow-Up
On 31 May 2014 03:42, Mark Roberts wiz...@gmail.com wrote: What I'd really like to see is a Python 2.8 that makes sufficient changes to Python 2 that writing libraries which cross the boundary between 2 and 3 is relatively easy instead of a painful nightmarish chore. That's what projects like python-future are for. Python 2.8 wouldn't help, since most folks still target 2.6 for compatibility with stable Linux platforms like RHEL, CentOS, Debian Stable Ubuntu LTS. This is a key point folks often miss in these discussions: even putting Python 3 aside entirely, the migration of the overall ecosystem from Python 2.6 to Python *2.7* is not yet finished. RHEL 7 (which uses 2.7 as the system Python) is currently only available as a release candidate, and the same necessarily holds true for its downstream rebuilds like CentOS. We saw this happen with Python 2.4 as well: for a lot of library developers, the day CentOS 6 finally landed (with Python 2.6 as the system Python) was the day they finally decided to drop support for Python 2.4. It's that slow adoption cycle for new feature releases *within* the Python 2 series that means the effort that would be needed to create a Python 2.8 release is better put into tools and utilities that people can use *now* (like PyPI backports of standard library modules, python-future and the pymigrate utility Steve Dower suggested and Eric Snow has started working on), tweaks to 2.7 itself (like PEP 466 and a possible future backport of the ensurepip changes) and Python 3 changes that improve both Python 3 *and* the subset it shares with Python 2 (like the restoration of binary interpolation support approved for 3.5). Cheers, Nick. P.S. I've written more about adoption cycles for new Python versions at http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html#wouldn-t-a-python-2-8-release-help-ease-the-transition ___ 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] Language Summit Follow-Up
On Fri, May 30, 2014 at 7:05 PM, Nick Coghlan ncogh...@gmail.com wrote: I already have too many other things on my todo list to work this up into a full PEP, but the proof of concept (along with IPython's existing support) shows there's no *technical* barrier to adding the feature. That doesn't follow. A PoC and even IPython can ignore all kinds of *technical* issues (e.g. giving code that's valid today a different meaning). Please drop this idea or at least take it out of this thread and focus on what *can* and *should* be done, in particular adding warnings with good hints about what went wrong when Python 3 encounters what appears to be a print statement. -- --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] Language Summit Follow-Up
Right. The point is that the current HOWTO gives information that is not useful for most people who are tasked with a port. On Fri, May 30, 2014 at 6:46 PM, Nick Coghlan ncogh...@gmail.com wrote: On 31 May 2014 08:42, Guido van Rossum gu...@python.org wrote: 2to3 is poorly named. With different fixers it is a fine tool for converting 2-only code to 2-and-3 straddling code. Even when using six, you need to do things like convert print statements to print() calls with future import, use 'as' in except clauses, and so on. Both modernize futurize build on lib2to3 to do the heavy lifting - they don't reinvent that wheel, they just change which fixes are applied by default and add a few more of their own. However, even if going straight to Python 3, I suspect folks would still be better off doing something like: * futurize --stage1 (migrates to 2.6+, but adds no new runtime dependencies - the output should be fairly idiomatic Python 2.6/7 code) * 2to3 (wholesale migration to Python 3) The trick, though, is that the granularity of that approach is at the process level - the entire application must be converted at once. You also can't start your own migration until all your dependencies are available in Python 3. By contrast, migration via the common subset can be incremental and opportunistic: * the granularity of migration is individual modules, rather than entire processes, so you can make a low risk gradual transition, even without a comprehensive regression test suite * you initially stay on Python 2, so you can start whenever is convenient for you, rather than having to wait for all your dependencies Cheers, Nick. On Fri, May 30, 2014 at 1:47 PM, Antoine Pitrou solip...@pitrou.net wrote: On Wed, 28 May 2014 15:26:38 -0700 Glyph Lefkowitz gl...@twistedmatrix.com wrote: Backport 'yield from' to allow people to use Tulip and Tulip-compatible code, and to facilitate the development of Tulip-friendly libraries and a Tulip ecosystem. A robust Tulip ecosystem requires the participation of people who are not yet using Python 3. I was wondering whether you were trolling or not on this one. From a quality assurance point of view, adding major features to a bugfix branch is extremely destructive, so I'm strongly -1 on it. Get rid of 2to3. Particularly, of any discussion of using 2to3 in the documentation. More than one very experienced, well-known Python developer in this discussion has told me that they thought 2to3 was the blessed way to port their code, and it's no surprise that they think so, given that the first technique https://docs.python.org/3/howto/pyporting.html mentions is still 2to3. 2to3 is certainly fine if you are porting to 3.x without looking to keep your code 2.x-compatible. Until there's a better alternative, of course. So what we should do is better explain the choice (if you want to port your code to 3.x, use 2to3; if you want to maintain dual-compatible code, use six or something similar). Regards Antoine. ___ 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/ncoghlan%40gmail.com -- --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] Language Summit Follow-Up
On 5/29/2014 1:22 AM, INADA Naoki wrote: We would like to stress that we don't believe anything on this list is as important as the continuing efforts that everyone in the broader ecosystem is making. If you just want to ease the transition by working on anything at all, the best use of your time right now is porting https://warehouse.python.org/project/MySQL-python/ to Python 3. :) I've did it. https://github.com/PyMySQL/mysqlclient-python https://pypi.python.org/pypi/mysqlclient I don't think that most people interpret Programming Language :: Python as indicating support for Python 3. So I suggest adding Programming Language :: Python :: 3 or even the more specific 3.3 and 3.4 -- Terry Jan Reedy ___ 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] Language Summit Follow-Up
On 29 May 2014 08:26, Glyph Lefkowitz gl...@twistedmatrix.com wrote: Thanks for the write-up! Here are some ideas for Python 2.7+. Add ensurepip to the installers. Having pip reliably available increases the availability of libraries that help with porting, and will generally strengthen the broader ecosystem in the (increasingly long) transition period. Agreed on this one - I only dropped it from 453 because I didn't think I could continue to push for it and still make the beta deadline for 3.4, not because I changed my mind. This mainly needs a champion to write the PEP to describe the exact details of what would be backported (the tricky parts of PEP 453 relating to pyvenv don't apply) and to actually do the work. Bundling the Python Launcher with the Windows installer would also be desirable. Add some warnings about python 3 compatibility. It should at least be possible to get a warning for every single implicit string coercion. Old-style classes. Old-style division. Print statements. Old-style exception syntax. buffer(). bytes(memoryview(b'abc')) Importing old locations from the stdlib (see point 4.) Long integer syntax. Use of variables beyond the lifetime of an 'except Exception as e' block or a list comprehension. A few more for the missing -3 warning list: - calling str.encode - calling unicode.decode - returning str from str.decode - returning unicode from unicode.encode The relevant TypeErrors in 3.x show where the latter two warnings need to go in 2.7. More controversially: warn for any calls to Py2 str methods that aren't present on Py3 bytes. Backport 'yield from' to allow people to use Tulip and Tulip-compatible code, and to facilitate the development of Tulip-friendly libraries and a Tulip ecosystem. A robust Tulip ecosystem requires the participation of people who are not yet using Python 3. Given that the target audience here is our more conservative user base, Tulip/Trollius backends for Twisted and gevent seem more conducive to that than supporting Tulip's native coroutine syntax. That said, it's a pure additive change without any significant backwards compatibility implications, so I personally wouldn't object if Guido said yes. Add aliases for the renamed modules in the stdlib. This will allow people to just write python 3 in a lot more circumstances. This is what the module aliasing options provided by python-future are designed to do - it's much closer to just write Python 3 than six is (although that comes at the price of being a bit more magical). The python-future experience also shows there's a potential backwards compatibility issue here - depending on exactly how you do it, you can end up conflicting with other libraries trying to do the same thing. (re-)Enable warnings by default, including enabling -3 warnings. Right now all warnings are silent by default, which greatly reduces discoverability of future compatibility issues. I hope it's not controversial to say that most new Python code is still being written against Python 2.7 today; if people are writing that code in such a way that it's not 3-friendly, it should be a more immediately noticeable issue. The reasons these were turned off haven't changed, and passing -3 already enables DeprecationWarnings generally (along with -Qwarn). However, several of the warnings mentioned in the list above are currently missing entirely, so they won't show up regardless of the warning state. Get rid of 2to3. Particularly, of any discussion of using 2to3 in the documentation. More than one very experienced, well-known Python developer in this discussion has told me that they thought 2to3 was the blessed way to port their code, and it's no surprise that they think so, given that the first technique https://docs.python.org/3/howto/pyporting.html mentions is still 2to3. We should replace 2to3 with something like https://github.com/mitsuhiko/python-modernize. 2to3 breaks your code on python 2, and doesn't necessarily get it running on python 3. A more conservative approach that reduced the amount of work to get your code 2/3 compatible but was careful to leave everything working would be a lot more effective. +1, although I think python-future provides a better subset language experience than modernize+six does, and provides a 3-common subset converter in addition to a 2-common subset (see http://python-future.org/faq.html#relationship-between-python-future-and-other-compatibility-tools for more on the difference between the two approaches). The futurize script also has the nice property of supporting two different stages, with --stage1 being a pure syntactic update - no new runtime dependencies needed. Big bang migrations are highly unlikely to be the right choice for anyone, and while the code produced by python-future will still have some quirks (e.g. avoiding direct use of any mapping methods as PEP 469 ended up recommending, plus a bunch of import
Re: [Python-Dev] Language Summit Follow-Up
On 5/28/2014 6:26 PM, Glyph Lefkowitz wrote: I hope it's not controversial to say that most new Python code is still being written against Python 2.7 today; Given that Python 3 downloads now outnumber Python 2 downloads, I think 'most' might be an overstatement. But I think it a moot point. if people are writing that code in such a way that it's not 3-friendly, it should be a more immediately noticeable issue. If the truth were, conservatively, 1/4 of new Python code in 2.7, or even less, I would still be in favor of making 3-friendly 2.7 code easier. This is also important for the separate codebase approach, as in the stdlib. Just last week, I got a rejected chunk when backporting because a 2.7 idlelib module uses 'file(...' instead of 'open(...'. -- Terry Jan Reedy ___ 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] Language Summit Follow-Up
Thanks for for putting this together. On Wed, May 28, 2014 at 4:26 PM, Glyph Lefkowitz gl...@twistedmatrix.com wrote: At the language summit, Alex and I volunteered to put together some recommendations on what changes could be made to Python (the language) in order to facilitate a smoother transition from Python 2 to Python 3. One of the things that motivated this was the (surprising, to us) consideration that features like ensurepip might be added to the future versions of the 2.7 installers from python.org. The specific motivations for writing this are: 1. Library maintainers have a rapidly expanding matrix that requires an increasing number of branches to satisfy. 2. People with large corporate codebases absolutely cannot port all at once. If you don't have perfect test coverage then you can't make any progress. So these changes are intended to make porting from python 2 to python 3 more guided and incremental. We believe that these attributes are necessary. One of the parallel discussions that came out of the language summit centers on basically the same idea: https://mail.python.org/pipermail/python-dev/2014-April/133986.html The key points are that there would be a separate tool that wraps the 2.7 interpreter and enforces the 2.7/3.x subset language but only for source files that have are tagged (a la the coding cookie). So there would be no need to make changes to Python itself. Some have also suggested this could also be accomplished via a pylint plugin. I'm working on an implementation called (for now) pymigrate that should eventually be available via the cheeseshop. A lot of what you've written here is really useful. Here are some ideas for Python 2.7+. 1. Add ensurepip to the installers. Having pip reliably available increases the availability of libraries that help with porting, and will generally strengthen the broader ecosystem in the (increasingly long) transition period. My understanding is that this is already the plan. 2. Add some warnings about python 3 compatibility. 1. It should at least be possible to get a warning for every single implicit string coercion. 2. Old-style classes. 3. Old-style division. 4. Print statements. 5. Old-style exception syntax. 6. buffer(). 7. bytes(memoryview(b'abc')) 8. Importing old locations from the stdlib (see point 4.) 9. Long integer syntax. 10. Use of variables beyond the lifetime of an 'except Exception as e' block or a list comprehension. +1 to improving the coverage of the -3 option in 2.7. 3. Backport 'yield from' to allow people to use Tulip and Tulip-compatible code, and to facilitate the development of Tulip-friendly libraries and a Tulip ecosystem. A robust Tulip ecosystem requires the participation of people who are not yet using Python 3. What about Trellis? Regardless, adding yield from to 2.7 is going to be a tough sell. 4. Add aliases for the renamed modules in the stdlib. This will allow people to just write python 3 in a lot more circumstances. I like this, but it seems to me to be a better fit for something like six or even pymigrate. 5. (re-)Enable warnings by default, including enabling -3 warnings. Right now all warnings are silent by default, which greatly reduces discoverability of future compatibility issues. This is also something that fits better with a separate tool. We have rejected any changes for Python 3.5, simply because of the extremely long time to get those features into users hands. Any changes for Python 3 that we're proposing would need to get into a 3.4.x release Good luck with that one! wink -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] Language Summit Follow-Up
On Wed, May 28, 2014, at 15:26, Glyph Lefkowitz wrote: Add some warnings about python 3 compatibility. It should at least be possible to get a warning for every single implicit string coercion. Old-style classes. Old-style division. Fun fact: This can be achieved with the -Qwarn command line option. ___ 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] Language Summit Follow-Up
We would like to stress that we don't believe anything on this list is as important as the continuing efforts that everyone in the broader ecosystem is making. If you just want to ease the transition by working on anything at all, the best use of your time right now is porting https://warehouse.python.org/project/MySQL-python/ to Python 3. :) I've did it. https://github.com/PyMySQL/mysqlclient-python https://pypi.python.org/pypi/mysqlclient -- INADA Naoki songofaca...@gmail.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
