[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2014-12-05 - 2014-12-12)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open4666 ( +0)
closed 30137 (+42)
total 34803 (+42)
Open issues with patches: 2173
Issues opened (31)
==
#9647: os.confstr() does not handle value changing length between cal
http://bugs.python.org/issue9647 reopened by haypo
#22866: ssl module in 2.7 should provide a way to configure default co
http://bugs.python.org/issue22866 reopened by lemburg
#22935: Disabling SSLv3 support
http://bugs.python.org/issue22935 reopened by ned.deily
#23001: Accept mutable bytes-like objects
http://bugs.python.org/issue23001 opened by serhiy.storchaka
#23003: traceback.{print_exc,print_exception,format_exc,format_excepti
http://bugs.python.org/issue23003 opened by Arfrever
#23004: mock_open() should allow reading binary data
http://bugs.python.org/issue23004 opened by jcea
#23008: pydoc enum.{,Int}Enum fails
http://bugs.python.org/issue23008 opened by Antony.Lee
#23010: "unclosed file" warning when defining unused logging FileHandl
http://bugs.python.org/issue23010 opened by wdoekes
#23011: Duplicate Paragraph in documentation for json module
http://bugs.python.org/issue23011 opened by berndca
#23012: RuntimeError: settrace/setprofile function gets lost
http://bugs.python.org/issue23012 opened by arigo
#23013: Tweak wording for importlib.util.LazyLoader in regards to Load
http://bugs.python.org/issue23013 opened by brett.cannon
#23014: Don't have importlib.abc.Loader.create_module() be optional
http://bugs.python.org/issue23014 opened by brett.cannon
#23015: Improve test_uuid
http://bugs.python.org/issue23015 opened by serhiy.storchaka
#23017: string.printable.isprintable() returns False
http://bugs.python.org/issue23017 opened by planet36
#23018: Add version info to python[w].exe
http://bugs.python.org/issue23018 opened by steve.dower
#23019: pyexpat.errors wrongly bound to message strings instead of mes
http://bugs.python.org/issue23019 opened by bkarge
#23020: New matmul operator crashes modules compiled with CPython3.4
http://bugs.python.org/issue23020 opened by amaury.forgeotdarc
#23021: Get rid of references to PyString in Modules/
http://bugs.python.org/issue23021 opened by berker.peksag
#23023: ./Modules/ld_so_aix not found on AIX during test_distutils
http://bugs.python.org/issue23023 opened by lemburg
#23025: ssl.RAND_bytes docs should mention os.urandom
http://bugs.python.org/issue23025 opened by alex
#23026: Winreg module doesn't support REG_QWORD, small DWORD doc updat
http://bugs.python.org/issue23026 opened by markgrandi
#23027: test_warnings fails with -Werror
http://bugs.python.org/issue23027 opened by serhiy.storchaka
#23028: CEnvironmentVariableTests and PyEnvironmentVariableTests test
http://bugs.python.org/issue23028 opened by serhiy.storchaka
#23029: test_warnings produces extra output in quiet mode
http://bugs.python.org/issue23029 opened by serhiy.storchaka
#23030: lru_cache manual get/put
http://bugs.python.org/issue23030 opened by ConnyOnny
#23031: pdb crashes when jumping over "with" statement
http://bugs.python.org/issue23031 opened by DSP
#23033: Disallow support for a*.example.net, *a.example.net, and a*b.e
http://bugs.python.org/issue23033 opened by dstufft
#23034: Dynamically control debugging output
http://bugs.python.org/issue23034 opened by serhiy.storchaka
#23035: python -c: Line causing exception not shown for exceptions oth
http://bugs.python.org/issue23035 opened by Arfrever
#23040: Better documentation for the urlencode safe parameter
http://bugs.python.org/issue23040 opened by wrwrwr
#23041: csv needs more quoting rules
http://bugs.python.org/issue23041 opened by samwyse
Most recent 15 issues with no replies (15)
==
#23029: test_warnings produces extra output in quiet mode
http://bugs.python.org/issue23029
#23028: CEnvironmentVariableTests and PyEnvironmentVariableTests test
http://bugs.python.org/issue23028
#23027: test_warnings fails with -Werror
http://bugs.python.org/issue23027
#23026: Winreg module doesn't support REG_QWORD, small DWORD doc updat
http://bugs.python.org/issue23026
#23021: Get rid of references to PyString in Modules/
http://bugs.python.org/issue23021
#23015: Improve test_uuid
http://bugs.python.org/issue23015
#23013: Tweak wording for importlib.util.LazyLoader in regards to Load
http://bugs.python.org/issue23013
#23012: RuntimeError: settrace/setprofile function gets lost
http://bugs.python.org/issue23012
#23008: pydoc enum.{,Int}Enum fails
http://bugs.python.org/issue23008
#23004: mock_open() should allow reading binary data
http://bugs.python.org/issue23004
#23003: traceback.{print_exc,print_exception,format_exc,format_excepti
http://bugs.python.org/issue23003
#22990: bdist installation dialog
ht
Re: [Python-Dev] Python 2.x and 3.x use survey, 2014 edition
So, I'm more than aware of how to write Python 2/3 compatible code. I've ported 10-20 libraries to Python 3 and write Python 2/3 compatible code at work. I'm also aware of how much writing 2/3 compatible code makes me hate Python as a language. It'll be a happy day when one of the two languages dies so that I never have to write code like that again. However, my point was that just because the core libraries by usage are *starting* to roll out Python 3 support doesn't mean that things are "easy" or "convenient" yet. There are too many libraries in the long tail which fulfill semi-common purposes and haven't been moved over yet. Yeah, sure, they haven't been updated in years... but neither has the language they're built on. I suppose what I'm saying is that the long tail of libraries is far more valuable than it seems the Python3 zealots are giving it credit for. Please don't claim it's "easy" to move over just because merely most of the top 20 libraries have been moved over. :-/ -Mark On Thu, Dec 11, 2014 at 12:14 PM, Dan Stromberg wrote: > On Thu, Dec 11, 2014 at 11:35 AM, Mark Roberts wrote: > > I disagree. I know there's a huge focus on The Big Libraries (and > wholesale > > migration is all but impossible without them), but the long tail of > > libraries is still incredibly important. It's like saying that migrating > the > > top 10 Perl libraries to Perl 6 would allow people to completely ignore > all > > of CPAN. It just doesn't make sense. > > Things in the Python 2.x vs 3.x world aren't that bad. > > See: > https://python3wos.appspot.com/ and > https://wiki.python.org/moin/PortingPythonToPy3k > http://stromberg.dnsalias.org/~strombrg/Intro-to-Python/ (writing code > to run on 2.x and 3.x) > > I believe just about everything I've written over the last few years > either ran on 2.x and 3.x unmodified, or ran on 3.x alone. If you go > the former route, you don't need to wait for your libraries to be > updated. > > I usually run pylint twice for my projects (after each change, prior > to checkin), once with a 2.x interpreter, and once with a 3.x > interpreter (using > http://stromberg.dnsalias.org/svn/this-pylint/trunk/this-pylint) , but > I gather pylint has the option of running on a 2.x interpreter and > warning about anything that wouldn't work on 3.x. > ___ 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] Issue 22919: Update PCBuild for VS 2015
FYI, I've just committed these changes (http://bugs.python.org/issue22919). There shouldn't be any immediate failures, as the updated projects will still build with VS 2010, but our Windows developers/buildbots can migrate onto the later tools as they feel comfortable. I know there are at least a few bugs coming out of the new compiler, so I'll be tracking those down and fixing things. Feel free to nosy me (or Windows) on the issue tracker if you find anything. Cheers, 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] Python 2.x and 3.x use survey, 2014 edition
On 2014-12-11, 14:47 GMT, Giampaolo Rodola' wrote: > I still think the only *real* obstacle remains the lack of > important packages such as twisted, gevent and pika which > haven't been ported yet. And unwise decisions of some vendors (like, unfortunately my belvoed employer with RHEL-7) not to ship python3. Oh well. Matěj ___ 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] Python 2.x and 3.x use survey, 2014 edition
Also keep in mind that not all Python libraries are on PyPI. For non-Python projects with Python bindings (think video players, OpenCV, systemd, Samba), distribution via PyPI doesn't make much sense. And since the Python bindings are usually second-class citizens, the porting doesn't have a high priority. If anyone is wondering why their favorite Linux distribution is stuck with Python 2 – well, I can only speak for Fedora, but nowadays most of what's left are CPython bindings. No pylint --py3k or 2to3 will help there... On Fri, Dec 12, 2014 at 7:24 PM, Mark Roberts wrote: > So, I'm more than aware of how to write Python 2/3 compatible code. I've > ported 10-20 libraries to Python 3 and write Python 2/3 compatible code at > work. I'm also aware of how much writing 2/3 compatible code makes me hate > Python as a language. It'll be a happy day when one of the two languages > dies so that I never have to write code like that again. However, my point > was that just because the core libraries by usage are *starting* to roll out > Python 3 support doesn't mean that things are "easy" or "convenient" yet. > There are too many libraries in the long tail which fulfill semi-common > purposes and haven't been moved over yet. Yeah, sure, they haven't been > updated in years... but neither has the language they're built on. > > I suppose what I'm saying is that the long tail of libraries is far more > valuable than it seems the Python3 zealots are giving it credit for. Please > don't claim it's "easy" to move over just because merely most of the top 20 > libraries have been moved over. :-/ > > -Mark > > On Thu, Dec 11, 2014 at 12:14 PM, Dan Stromberg wrote: >> >> On Thu, Dec 11, 2014 at 11:35 AM, Mark Roberts wrote: >> > I disagree. I know there's a huge focus on The Big Libraries (and >> > wholesale >> > migration is all but impossible without them), but the long tail of >> > libraries is still incredibly important. It's like saying that migrating >> > the >> > top 10 Perl libraries to Perl 6 would allow people to completely ignore >> > all >> > of CPAN. It just doesn't make sense. >> >> Things in the Python 2.x vs 3.x world aren't that bad. >> >> See: >> https://python3wos.appspot.com/ and >> https://wiki.python.org/moin/PortingPythonToPy3k >> http://stromberg.dnsalias.org/~strombrg/Intro-to-Python/ (writing code >> to run on 2.x and 3.x) >> >> I believe just about everything I've written over the last few years >> either ran on 2.x and 3.x unmodified, or ran on 3.x alone. If you go >> the former route, you don't need to wait for your libraries to be >> updated. >> >> I usually run pylint twice for my projects (after each change, prior >> to checkin), once with a 2.x interpreter, and once with a 3.x >> interpreter (using >> http://stromberg.dnsalias.org/svn/this-pylint/trunk/this-pylint) , but >> I gather pylint has the option of running on a 2.x interpreter and >> warning about anything that wouldn't work on 3.x. ___ 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] Python 2.x and 3.x use survey, 2014 edition
On Dec 12, 2014, at 08:07 PM, Petr Viktorin wrote: >If anyone is wondering why their favorite Linux distribution is stuck with >Python 2 – well, I can only speak for Fedora, but nowadays most of what's >left are CPython bindings. No pylint --py3k or 2to3 will help there... It's true that some of these are tough. I tried and failed a few times to port Xapian to Python 3. The issue was opened upstream 6 years ago and it's still unresolved: http://trac.xapian.org/ticket/346 OTOH, I ported dbus-python to Python 3 and that worked out much better; we've had solid Python 3 bindings for several years now, which allowed us to port many important Debian/Ubuntu tools to Python 3 and more importantly, do all our new work in Python 3. With other big toolkits like GObject introspection working on Python 3, there's a lot you can do. IME, if the underlying model is string/bytes clean, then the C extension port can sometimes be easier than pure-Python, thanks to cpp games. D-Bus's model is pretty clean, Xapian I found to be not so much (it doesn't help that Xapian is C++ ;). We're actually not terribly far from switching Debian and Ubuntu's default to Python 3. On Debian, the big blocker is the BTS code (which uses SOAP) and on Ubuntu it's the launchpadlib stack. I hope to find time after Jessie to work on the former, and before 16.04 LTS to work on the latter. Not that I disagree that there's a long tail of code that would still benefit a significant population if it got ported to Python 3. By far Python 3 is a better language, with a better stdlib, so the work is worth it. Cheers, -Barry ___ 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] Python 2/3 porting HOWTO has been updated
I have now addressed Nick's comments and backported to Python 2.7. On Sat Dec 06 2014 at 8:40:24 AM Brett Cannon wrote: > Thanks for the feedback. I'll update the doc probably on Friday. > > On Sat Dec 06 2014 at 12:41:54 AM Nick Coghlan wrote: > >> On 6 December 2014 at 14:40, Nick Coghlan wrote: >> > On 6 December 2014 at 10:44, Benjamin Peterson >> wrote: >> >> On Fri, Dec 5, 2014, at 18:16, Donald Stufft wrote: >> >>> Do we need to update it? Can it just redirect to the 3 version? >> >> >> >> Technically, yes, of course. However, that would unexpected take you >> out >> >> of the Python 2 docs "context". Also, that doesn't solve the problem >> for >> >> the downloadable versions of the docs. >> > >> > As Benjamin says, we'll likely want to update the Python 2 version >> > eventually for the benefit of the downloadable version of the docs, >> > but Brett's also right it makes sense to wait for feedback on the >> > Python 3 version and then backport the most up to date text wholesale. >> > >> > In terms of the text itself, this is a great update Brett - thanks! >> > >> > A couple of specific notes: >> > >> > * http://python-future.org/compatible_idioms.html is my favourite >> > short list of "What are the specific Python 2 only habits that I need >> > to unlearn in order to start writing 2/3 compatible code?". It could >> > be worth mentioning in addition to the What's New documents and the >> > full Python 3 Porting book. >> > >> > * it's potentially worth explicitly noting the "bytes(index_value)" >> > and "str(bytes_value)" traps when discussing the bytes/text changes. >> > Those do rather different things in Python 2 & 3, but won't emit an >> > error or warning in either version. >> >> Given that 3.4 and 2.7.9 will be the first exposure some users will >> have had to pip, would it perhaps be worth explicitly mentioning the >> "pip install " commands for the various tools? At least pylint's >> PyPI page only gives the manual download instructions, including which >> dependencies you will need to install. >> >> Cheers, >> Nick. >> >> -- >> Nick Coghlan | [email protected] | Brisbane, Australia >> > ___ 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] Python 2.x and 3.x use survey, 2014 edition
On 12/12/2014 1:24 PM, Mark Roberts wrote: However, my point was that just because the core libraries by usage are *starting* to roll out Python 3 support doesn't mean that things are "easy" or "convenient" yet. ... I suppose what I'm saying is that the long tail of libraries is far more valuable than it seems the Python3 zealots are giving it credit for. Please don't claim it's "easy" to move over just because merely most of the top 20 libraries have been moved over. :-/ I agree that we should refrain from characterizing the difficulty of other peoples' work. Conversions range from trivial to effectively impossible. What we can say is that a) each library conversion make conversion easier for the users of that library and b) the number of conversions continue to increase. I think some are trying to say that the number has reached a point where it is no longer fair to say that conversion is typically impossible. -- Terry Jan Reedy ___ 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] Python 2.x and 3.x use survey, 2014 edition
On Fri, Dec 12, 2014 at 10:24:15AM -0800, Mark Roberts wrote: > So, I'm more than aware of how to write Python 2/3 compatible code. I've > ported 10-20 libraries to Python 3 and write Python 2/3 compatible code at > work. I'm also aware of how much writing 2/3 compatible code makes me hate > Python as a language. I'm surprised by the strength of feeling there. Most of the code I write supports 2.4+, with the exception of 3.0 where I say "it should work, but if it doesn't, I don't care". I'll be *very* happy when I can drop support for 2.4, but with very few exceptions I have not found many major problems supporting both 2.7 and 3.3+ in the one code-base, and nothing I couldn't work around (sometimes by just dropping support for a specific feature in certain versions). I'm not disputing that your experiences are valid, but I am curious what specific issues you have come across and wondering if there are things which 3.5 can include to ease that transition. E.g. 3.3 re-added support for u'' syntax. -- Steven ___ 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] Python 2.x and 3.x use survey, 2014 edition
> On Dec 12, 2014, at 11:55 PM, Steven D'Aprano wrote: > > On Fri, Dec 12, 2014 at 10:24:15AM -0800, Mark Roberts wrote: >> So, I'm more than aware of how to write Python 2/3 compatible code. I've >> ported 10-20 libraries to Python 3 and write Python 2/3 compatible code at >> work. I'm also aware of how much writing 2/3 compatible code makes me hate >> Python as a language. > > I'm surprised by the strength of feeling there. > > Most of the code I write supports 2.4+, with the exception of 3.0 where > I say "it should work, but if it doesn't, I don't care". I'll be *very* > happy when I can drop support for 2.4, but with very few exceptions I > have not found many major problems supporting both 2.7 and 3.3+ in the > one code-base, and nothing I couldn't work around (sometimes by just > dropping support for a specific feature in certain versions). > > I'm not disputing that your experiences are valid, but I am curious what > specific issues you have come across and wondering if there are things > which 3.5 can include to ease that transition. E.g. 3.3 re-added support > for u'' syntax. For what it’s worth, I almost exclusively write 2/3 compatible code (and that’s with the “easy” subset of 2.6+ and either 3.2+ or 3.3+) and doing so does make the language far less fun for me than when I was writing 2.x only code. I’ve though a lot about why that is, because it’s certainly not *hard* to do so, and what I think it is for me at least is inherient in the fact you're using a lowest common denominator approach to programming. Because I can only use things which work the same in 2.6+ and 3.2+ it means I cannot take advantage of any new features unless they are available as a backport. Now this is always true of code that needs to straddle multiple versions in order to maintain compatability. However the way it "used" to work is that the newest version, with all the new features, would quickly become the dominant version within a year or two. The older versions might still command a respectable amount of use, but that tended to fall off quicker and it wouldn't be unreasonable to be more aggresive in some situations than others depending on what the new feature was I wanted to use. However when we look at today, the "new" versions are Python 3.4, 3.3, or even 3.2. However I can't really justify for most situations supporting _only_ those things because even today they are not the dominant version (or really close to it in any number I have access too). This means that if I want to take advantage of something newer I'm essentially dropping the largest part of the ecosystem. On top of all of this, I'm not sure I see a point in the near future where this tipping point might happen and the "normal" order of the newest version with the newest features rapidly becoming the dominant version gets restored. I'm sort of holding out hope that the Linux distribution switching to Python 3 as a default might push it over, but I'm also not holding my breath there. So that's basically it, lowest common demoniator programming where it's hard to look at the future and see anything but the same (or similar) language subset that I'm currently using. This is especially frustrating when you see other languages doing cool and interesting new things and it feels like we're stuck with what we had in 2008 or 2010. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ 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] Python 2.x and 3.x use survey, 2014 edition
> On Dec 13, 2014, at 12:29 AM, Donald Stufft wrote: > >> >> On Dec 12, 2014, at 11:55 PM, Steven D'Aprano wrote: >> >> On Fri, Dec 12, 2014 at 10:24:15AM -0800, Mark Roberts wrote: >>> So, I'm more than aware of how to write Python 2/3 compatible code. I've >>> ported 10-20 libraries to Python 3 and write Python 2/3 compatible code at >>> work. I'm also aware of how much writing 2/3 compatible code makes me hate >>> Python as a language. >> >> I'm surprised by the strength of feeling there. >> >> Most of the code I write supports 2.4+, with the exception of 3.0 where >> I say "it should work, but if it doesn't, I don't care". I'll be *very* >> happy when I can drop support for 2.4, but with very few exceptions I >> have not found many major problems supporting both 2.7 and 3.3+ in the >> one code-base, and nothing I couldn't work around (sometimes by just >> dropping support for a specific feature in certain versions). >> >> I'm not disputing that your experiences are valid, but I am curious what >> specific issues you have come across and wondering if there are things >> which 3.5 can include to ease that transition. E.g. 3.3 re-added support >> for u'' syntax. > > For what it’s worth, I almost exclusively write 2/3 compatible code (and > that’s > with the “easy” subset of 2.6+ and either 3.2+ or 3.3+) and doing so does make > the language far less fun for me than when I was writing 2.x only code. I’ve > though a lot about why that is, because it’s certainly not *hard* to do so, > and > what I think it is for me at least is inherient in the fact you're using a > lowest common denominator approach to programming. > > Because I can only use things which work the same in 2.6+ and 3.2+ it means I > cannot take advantage of any new features unless they are available as a > backport. Now this is always true of code that needs to straddle multiple > versions in order to maintain compatability. However the way it "used" to work > is that the newest version, with all the new features, would quickly become > the dominant version within a year or two. The older versions might still > command a respectable amount of use, but that tended to fall off quicker and > it wouldn't be unreasonable to be more aggresive in some situations than > others > depending on what the new feature was I wanted to use. > > However when we look at today, the "new" versions are Python 3.4, 3.3, or even > 3.2. However I can't really justify for most situations supporting _only_ > those > things because even today they are not the dominant version (or really close > to it in any number I have access too). This means that if I want to take > advantage of something newer I'm essentially dropping the largest part of > the ecosystem. > > On top of all of this, I'm not sure I see a point in the near future where > this > tipping point might happen and the "normal" order of the newest version with > the newest features rapidly becoming the dominant version gets restored. I'm > sort of holding out hope that the Linux distribution switching to Python 3 > as a default might push it over, but I'm also not holding my breath there. > > So that's basically it, lowest common demoniator programming where it's hard > to > look at the future and see anything but the same (or similar) language subset > that I'm currently using. This is especially frustrating when you see other > languages doing cool and interesting new things and it feels like we're stuck > with what we had in 2008 or 2010. > Oh yea, in addition to this, actually backporting things is becoming increasingly harder the further Python 3 gets developed. When the language was mostly forwards compatible if a new feature/function was added you could often times backport it into your own code in a compat shim by simply copy/pasting the code. However with all the new features being done in Python 3, it's increasingly the case that this code will *not* run on Python 2.6 and 2.7 because it's essentially being written for a different, but similar, language and requires some amount of porting. This porting process might even need to include incompatible changes because of differences in the language (see for example, Trollius). --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ 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] Python 2.x and 3.x use survey, 2014 edition
On Sat, Dec 13, 2014 at 4:29 PM, Donald Stufft wrote: > So that's basically it, lowest common demoniator programming where it's hard > to > look at the future and see anything but the same (or similar) language subset > that I'm currently using. This is especially frustrating when you see other > languages doing cool and interesting new things and it feels like we're stuck > with what we had in 2008 or 2010. That's what happens when you want to support a version of Python that was released in 2008 or 2010. Perhaps the impetus for people to move onto Python 3 has to come from people like you saying "I'm not going to support 2.7 any more as of version X.Y", and letting them run two interpreters. It's really not that hard to keep 2.7 around for what expects it, and 3.4/3.5/whatever for everything else. 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] Python 2.x and 3.x use survey, 2014 edition
> On Dec 13, 2014, at 12:40 AM, Chris Angelico wrote: > > On Sat, Dec 13, 2014 at 4:29 PM, Donald Stufft wrote: >> So that's basically it, lowest common demoniator programming where it's hard >> to >> look at the future and see anything but the same (or similar) language subset >> that I'm currently using. This is especially frustrating when you see other >> languages doing cool and interesting new things and it feels like we're stuck >> with what we had in 2008 or 2010. > > That's what happens when you want to support a version of Python that > was released in 2008 or 2010. Perhaps the impetus for people to move > onto Python 3 has to come from people like you saying "I'm not going > to support 2.7 any more as of version X.Y", and letting them run two > interpreters. It's really not that hard to keep 2.7 around for what > expects it, and 3.4/3.5/whatever for everything else. I don’t think this option is really grounded in reality. First of all, it's essentially the route that Python itself took and the side effects of that is essentially what is making things less-fun for me to write Python. Doing the same to the users of the things I write would make me feel bad that I was forcing them to either do all the work to port their stuff (and any dependencies) just so they can use a newer version of my library. It also I think is incredibly likely to backfire on any author who does it unless the thing they are writing is absolutely essential to their users AND there are no alternatives AND it's essential that those people are using a new version of that library. If all of those things are not the case, you're going to end up with a majoritity of users either just stop using your tool all together, switching to an alternative, or just sticking with an old version. I don't think I'm unique in that I like writing software that other people want to and can use. I think it also assumes that people are writing one off scripts and things like that which only use the standard library. I tend to write libraries and work on complex distributed systems. I need to either port the entire stack or nothing. I can't run half of my process in 2.7 and half in 3.4. It's also something I've never had to do in Python before, I've always been able to "follow" with the things I write. I could take a look at, or estimate, the amount of users that dropping an older version of Python and I could say that it was time to drop support for that version because very few people are actively using it and the cost of maintaining support for that version is no longer worth it. This is the same process I go through for *any* backwards incompatible change I make to the things I write and when I drop the old compatability shims. Ironically all versions of Python 3 combined are low enough that if they were the *old* versions and not the *new* versions I'd probably drop support from them for now. Really the major reasons I support them at all is because I hold out hope that maybe at some point it will become the dominant Python and because I try to be a good member of the ecosystem and not hold back the adoption. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ 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] Python 2.x and 3.x use survey, 2014 edition
On Sat, Dec 13, 2014 at 5:13 PM, Donald Stufft wrote: > First of all, it's essentially the route that Python itself took and the side > effects of that is essentially what is making things less-fun for me to write > Python. Doing the same to the users of the things I write would make me feel > bad that I was forcing them to either do all the work to port their stuff > (and any dependencies) just so they can use a newer version of my library. Ultimately, those programs WILL have to be migrated, or they will have to remain on an unsupported system. You have the choice of either continuing to do what you find un-fun (cross-compatibility code) until 2020 and maybe beyond, or stopping support for 2.7 sooner than that. All you're doing is changing *when* the inevitable migration happens. 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
