Re: [Python-Dev] The end of 2.7
On 4/7/2013 2:02 PM, Guido van Rossum wrote: There's not much of a point in fixing bugs that always existed in 2.7, I has been suggested that backporting bugfix patches from current 3.x to 2.7 will make it easier to port from the atest 2.7.x to 3.x. I have no idea how true that is. since must 2.7 users are by now used to working around these. An exception is Idle, where the workaround is to grit one teeth and perhaps yell 'Idle is broken' or to switch to something else. With PEP343 accepted, this is rapidly being worked on. NEWS for 2.7.5 already has 8 Idle items. Most of the credit goes to Roger Serwy. tjr ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The end of 2.7
In article cap7+vjlzb5xl8cxbmibunnig9y4+49f17vmfb9lznf0asnx...@mail.gmail.com, Guido van Rossum gu...@python.org wrote: [...] But perhaps we could change the focus for 2.7 development a bit: instead of fixing bugs (or bickering about whether something is a bug fix or a new feature) we could limit changes to ensuring that it works on newer platforms. Martin mentioned that building 2.7 for Windows with the same toolchain that was used for the 2.7.0 release is getting more and more problematic. I'm not sure, but I could imagine similar problems for future versions of OS X and even Linux (though the Linux distributions typically take care of issues themselves). That's an excellent point. In the OS X world, my sense is that OS and build tool updates are adopted more quickly by users than in less homogenous platform environments so we've tried to be be pragmatic about supporting new releases of Xcode built tools in Python maintenance branches like 2.7. For example, in 2.7.4 there were some significant changes to building Python and to Distutils to support extension module building with the latest Xcode releases. (That's not to say we are always as timely as we should be.) I don't think there has been any major disagreements that doing those kinds of limited changes for platform support are in scope. There have also been some changes to better support cross-building for platforms that have become more strategically important, like ARM. These have been more controversial but a good case can be made for considering such changes as pragmatic long-term investments. It might be a good idea to have a more formal policy in place going forward for 2.7.x. Beyond build tools is the issue of the components that Python depends on at runtime, primarily third-party libraries. Many of these are also under active development, with schedules and compatibility criteria that differ from those we use. In some cases, security issues will force the rapid adoption of new versions, in other cases, widespread adoption on the platforms we support will force this. Again, pragmatically, we'll need to continue to track these components and support newer versions as necessary in order for maintained versions of Python to remain viable. (And we need to step up the activity in some areas. Tcl/Tk 8.6 is now official and starting to be adopted. Tkinter and IDLE are intimately dependent on Tk and, AFAIK, we don't really have anyone closely following the changes there and their implications for Python. Thankfully, Serhiy has been doing some work with 8.6 already.) -- Ned Deily, n...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.3): Process DEFAULT values in mock side_effect that returns iterator.
On 7 April 2013 14:44, andrew.svetlov python-check...@python.org wrote: http://hg.python.org/cpython/rev/18fd64f1de2d changeset: 83179:18fd64f1de2d branch: 3.3 user:Andrew Svetlov andrew.svet...@gmail.com date:Sun Apr 07 16:42:24 2013 +0300 summary: Process DEFAULT values in mock side_effect that returns iterator. Patch by Michael Ford. files: Lib/unittest/mock.py | 2 ++ Lib/unittest/test/testmock/testmock.py | 4 2 files changed, 6 insertions(+), 0 deletions(-) diff --git a/Lib/unittest/mock.py b/Lib/unittest/mock.py --- a/Lib/unittest/mock.py +++ b/Lib/unittest/mock.py @@ -904,6 +904,8 @@ result = next(effect) if _is_exception(result): raise result +if result is DEFAULT: +result = self.return_value return result ret_val = effect(*args, **kwargs) diff --git a/Lib/unittest/test/testmock/testmock.py b/Lib/unittest/test/testmock/testmock.py --- a/Lib/unittest/test/testmock/testmock.py +++ b/Lib/unittest/test/testmock/testmock.py @@ -906,6 +906,10 @@ self.assertRaises(StopIteration, mock) self.assertIs(mock.side_effect, this_iter) +def test_side_effect_iterator_default(self): +mock = Mock(return_value=2) +mock.side_effect = iter([1, DEFAULT]) +self.assertEqual([mock(), mock()], [1, 2]) def test_assert_has_calls_any_order(self): mock = Mock() -- Repository URL: http://hg.python.org/cpython This was committed without a NEWS entry. Michael ___ Python-checkins mailing list python-check...@python.org http://mail.python.org/mailman/listinfo/python-checkins -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The end of 2.7
On Sat, Apr 6, 2013 at 5:02 PM, Benjamin Peterson benja...@python.orgwrote: Per my last message, 2.7.4 has at long last been released. I apologize for the long interval between 2.7.3 and 2.7.4. To create more determinism in the future, I will be soon updating PEP 373 with approximate dates of future 2.7 bugfix releases. I will be aiming for 6 month intervals. This means we need to talk about how many more 2.7 releases there are going to be. At the release of 2.7.0, I thought we promised 5 years of bugfix maintenance, but my memory may be fuddled. At any rate, 2.7.0 was released in July 2010, which currently puts us within a few months of 3 years of maintenance. Over the past year, I've been happy to see a lot of movement towards 3 including the porting of important codebases like Twisted and Django. However, there's also no doubt that 2.x is still widely used. Obviously, there will be people who would be happy if we kept maintaining 2.7 until 2025, but I think at this juncture 5 total years of maintenance is reasonable. This means there will be approximately 4 more 2.7 releases. Thoughts? Since this has ended up with roughly 50 responses, I'm going to try and summarize where things stand for my own benefit. First off, core devs almost all seem fine with declaring an end date to maintaining 2.7 and seeing these last releases happen every 6 months (since Benjamin volunteered and I think Martin and Ned said they are fine with that as well and it's really their call). The question for EOL seems to be whether to do one more release after 3.4 goes out in early 2014 or to see 2.7 through until early 2015. The other question seems to be whether we should lock down the branch so people don't think we will continue to accept patches and such (much like Georg has done with the 3.2 pre-commit hook). So those two points -- where to draw the line and whether to mothball the branch -- seem to be the only open questions. For me, I think a possible compromise might work out. What if we say python-dev will see patches backported until the release following 3.4, but after that the last two releases (which sees us into 2015 as Benjamin originally proposed) will only be patched by contributions from the community? IOW we make it very clear that python-dev considers themselves off the hook after 3.4 in terms of feeling obliged to backport any of their own code, but we are willing to examine and commit patches as provided by external contributors as long as they apply to all applicable branches. E.g. if someone wants something fixed in 2.7 after 3.4 is out they need to supply the patches for both 2.7 and 3.4 so that python-dev is doing nothing more than acting and gatekeepers on the repo and doing the commits on behalf of the patch writer. And then once the final 2.7 release is out we lock it down to make it abundantly clear that python-dev is entirely done with Python 2. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The end of 2.7
On Sun, Apr 7, 2013 at 6:53 AM, Christian Tismer tis...@stackless.comwrote: On 07.04.13 14:10, Skip Montanaro wrote: Where I work (a trading firm that uses Python as just one of many different pieces of technology, not a company where Python is the core technology upon which the firm is based) we are only just now migrating from 2.4 to 2.7. I can't imagine we'll have migrated to Python 3 in two years. It's not like we haven't seen this coming, but you can only justify moving so fast with technology that already works, especially if, like Python, you use it with lots of other packages (most/all of which themselves have to be ported to Python 3) and in-house software. I think the discussion should focus on who's left on 2.x and why, not, yeah, releases every six months for the next couple years ought to do it. when I read this, I was slightly shocked. You know what? We are pleased to announce the release of *Python 2.4, final* on November 30, 2004. I know that companies try to save (time? money?) something by not upgrading software, and this is extremely annoying. I'm in the same boat as Skip (just now moving from 2.4 to 2.7), and Python *is* a core technology for us. It has nothing really to do with saving time or money, its about priorities. The transition from 2.3 to 2.4 was actually fairly painful (don't ask me why, I don't even remember anymore), but we got stuck on 2.4 not by any specific decision -- it simply worked, and our time was always focused upon solving problems and improving our software itself. Could we have solved our problems easier if we upgraded Python and had new tools? Some, yes. (Some features we have added had me actually walking through third party code bases and backporting it -- converting with to try/finally is an amusing big one for example) For one thing, even with this relatively ancient Python, we almost never ran into bugs. It just worked and worked fine, so when we looked at our development plan the list of feature requests and issues for various customers (especially those that were potential new clients) overrode infrastructure upgrades as priorities. However, in a huge system that has many tens of thousands of lines of code, doing a platform upgrade is just a serious endeavor -- and its often not even Python's fault itself, but the reality that it means we're going to be upgrading *everything* and involves a much more involved QA cycle and often runs into third party software. We are finally upgrading now because the time to work around certain bugs in both Python and third-party libraries that no longer support 2.4 are enough for us to say, okay, we finally really do need to get this done. Migration to Python 3 ... IF it ever happens is more of a question then when. That's not a indictment of Python 3 or a problem with the current plan (for what its worth, the bugfix every 6 months until 5 years is up seems totally reasonable). Any new product we do, I'd seriously consider starting from Python 3. (Though PyPy supporting Py3 would help that argument a lot) The case for migrating existing products is a lot harder to make. But I think every employee (including you) can quite easily put some pressure on his company by claiming that Python 2.x is a dead end, and everybody is about to move on to 3.x. This does not have to be true, I just recognize that by claiming it and doing it with your projects, the movement becomes a reality. Just say that we all need to move on and cannot care about companies that ignore this necessity. The thing is, 2.7 works. Some third-party libraries we rely upon have no clear sign for when they will be ported (such as wxPython), and though we are transitioning away from certain others (omniORB for Apache Thrift for example), that process itself is planned to be a gradual thing for the next year, at least. My concern is for the health of my company, and happiness of my customers; I love Python and am an advocate for it, but in my day job, pushing things forward is just about at the bottom of my list of concerns. (Though, our migration to 2.7 is actually part of a long term strategic plan to embrace pypy) And now I go back to lurking. --Stephen ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The end of 2.7
On 08/04/2013 16:42, Stephen Hansen wrote: The thing is, 2.7 works. Some third-party libraries we rely upon have no clear sign for when they will be ported (such as wxPython), and though we are transitioning away from certain others (omniORB for Apache Thrift for example), that process itself is planned to be a gradual thing for the next year, at least. From http://wiki.wxpython.org/ProjectPhoenix WooHoo! Phoenix runs on Python 3!! --Stephen -- If you're using GoogleCrap™ please read this http://wiki.python.org/moin/GoogleGroupsPython. Mark Lawrence ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.3): Process DEFAULT values in mock side_effect that returns iterator.
On Mon, 8 Apr 2013 10:52:30 +0100 Michael Foord fuzzy...@gmail.com wrote: On 7 April 2013 14:44, andrew.svetlov python-check...@python.org wrote: http://hg.python.org/cpython/rev/18fd64f1de2d changeset: 83179:18fd64f1de2d branch: 3.3 user:Andrew Svetlov andrew.svet...@gmail.com date:Sun Apr 07 16:42:24 2013 +0300 summary: Process DEFAULT values in mock side_effect that returns iterator. Patch by Michael Ford. [...] This was committed without a NEWS entry. And I wonder who that Michael Ford is :-) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Fwd: SourceForge Project Upgrade Notification
Obviously SourceForge doesn't think the current release interval is short enough. (Emphasis mine.) :-) Skip -- Forwarded message -- From: SourceForge.net noreply+project-upgr...@in.sf.net Date: Mon, Apr 8, 2013 at 1:09 PM Subject: SourceForge Project Upgrade Notification To: nore...@in.sf.net Dear SourceForge Project Developer, We wanted to let you know that we've upgraded your project, Python, to the new SourceForge developer platform. The next time you log in, things will look a little different. *We've noticed that your project has been idle for a while. This would be a great time to come back and push out a * *new version.* Visit your project at http://sourceforge.net/projects/python/ The new platform, codenamed Allura, is a rewrite and redesign of the Open Source development tool set. It provides tighter integration between the various tools to give you a better developer experience. Allura is a project in incubation at the Apache Software Foundation, where people from many different companies are collaborating to make it even better. You can see a quick overview of the platform at http://sourceforge.net/create/#feature-holder and you can see ongoing updates to the platform on our blog, at http://sourceforge.net/blog/tag/updates/ Please let us know if there's anything we can do to make your SourceForge experience better. There's lots of ways to get in touch. You can email us at communityt...@sourceforge.net, on IRC at #sourceforge on Freenode, on our Facebook page at http://facebook.com/SourceForgeNet, on our Google Plus community at https://plus.google.com/communities/108980648585760076156, or via Twitter at @sourceforge. -- SourceForge.net has sent this mailing to you as a registered user of the SourceForge.net site to convey important information regarding your SourceForge.net account or your use of SourceForge.net services. If you have concerns about this mailing please contact our Support team per: http://sourceforge.net/support ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The end of 2.7
2013/4/8 Stephen Hansen me+pyt...@ixokai.io: On Sun, Apr 7, 2013 at 6:53 AM, Christian Tismer tis...@stackless.com wrote: On 07.04.13 14:10, Skip Montanaro wrote: Where I work (a trading firm that uses Python as just one of many different pieces of technology, not a company where Python is the core technology upon which the firm is based) we are only just now migrating from 2.4 to 2.7. I can't imagine we'll have migrated to Python 3 in two years. It's not like we haven't seen this coming, but you can only justify moving so fast with technology that already works, especially if, like Python, you use it with lots of other packages (most/all of which themselves have to be ported to Python 3) and in-house software. I think the discussion should focus on who's left on 2.x and why, not, yeah, releases every six months for the next couple years ought to do it. when I read this, I was slightly shocked. You know what? We are pleased to announce the release of Python 2.4, final on November 30, 2004. I know that companies try to save (time? money?) something by not upgrading software, and this is extremely annoying. I'm in the same boat as Skip (just now moving from 2.4 to 2.7), and Python *is* a core technology for us. It has nothing really to do with saving time or money, its about priorities. The transition from 2.3 to 2.4 was actually fairly painful (don't ask me why, I don't even remember anymore), but we got stuck on 2.4 not by any specific decision -- it simply worked, and our time was always focused upon solving problems and improving our software itself. Could we have solved our problems easier if we upgraded Python and had new tools? Some, yes. (Some features we have added had me actually walking through third party code bases and backporting it -- converting with to try/finally is an amusing big one for example) For one thing, even with this relatively ancient Python, we almost never ran into bugs. It just worked and worked fine, so when we looked at our development plan the list of feature requests and issues for various customers (especially those that were potential new clients) overrode infrastructure upgrades as priorities. However, in a huge system that has many tens of thousands of lines of code, doing a platform upgrade is just a serious endeavor -- and its often not even Python's fault itself, but the reality that it means we're going to be upgrading *everything* and involves a much more involved QA cycle and often runs into third party software. We are finally upgrading now because the time to work around certain bugs in both Python and third-party libraries that no longer support 2.4 are enough for us to say, okay, we finally really do need to get this done. Migration to Python 3 ... IF it ever happens is more of a question then when. That's not a indictment of Python 3 or a problem with the current plan (for what its worth, the bugfix every 6 months until 5 years is up seems totally reasonable). Any new product we do, I'd seriously consider starting from Python 3. (Though PyPy supporting Py3 would help that argument a lot) The case for migrating existing products is a lot harder to make. You might also think about rewriting the code so that it kind of works on both 2.7 *and* 3.3. By that I mean that your code on Python 3 should not necessarily work but neither it should raise SyntaxError. If from the start you use: - six - except exception as: - __future__ module’s from __future__ import division, print_statement, unicode_literals - fix warnings signaled by python -3 app.py ...and other similar tricks, your ported code is likely to look nicer and more modern and a future porting to Python 3 should be a lot less painful. At least, if the circumstances are right, I personally might see some value in doing so. --- Giampaolo https://code.google.com/p/pyftpdlib/ https://code.google.com/p/psutil/ https://code.google.com/p/pysendfile/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The end of 2.7
Am 07.04.2013 20:02, schrieb Guido van Rossum: But perhaps we could change the focus for 2.7 development a bit: instead of fixing bugs (or bickering about whether something is a bug fix or a new feature) we could limit changes to ensuring that it works on newer platforms. Martin mentioned that building 2.7 for Windows with the same toolchain that was used for the 2.7.0 release is getting more and more problematic. I'm not sure, but I could imagine similar problems for future versions of OS X and even Linux (though the Linux distributions typically take care of issues themselves). I would like this new focus :-) Note that for 2.7.4 we did backport the bsddb module to build with recent db-5.x versions, the embedded libffi library to build on new platforms. I would like to see a backport for #17536 too, a change to support new web browsers in an updated runtime environment. I would like to continue to backport cross build changes to 2.7.x, before all these people with Raspberry Pi's get too much annoyed about slow native builds. Support for new targets should be allowed after a review. There's not much of a point in fixing bugs that always existed in 2.7, since must 2.7 users are by now used to working around these. However, I do see a point in supporting builds targeting newer OS versions. The upcoming Ubuntu 13.04 release uses mostly Python 3.3.1 for the desktop images, but still ships with Python 2.7.4 too on the images. For now most third party modules and extensions still have to be available for both versions. For now these binary packages (in the sense of a package in a Linux distribution) are built for Python 2 and 3 from the same source package, so keeping the build procedures and support about the same way helps with this approach. Of course I can patch things locally, but would prefer to push these changes upstream. At the language summit I was surprised to hear about a common subset of backports for other vendor branches. Matthias ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python accepted as a GSoC 2013 mentoring organization!
Congratulations all; we've been accepted as a mentoring organization for Google Summer of Code 2013! Students can check out our ideas page here: http://wiki.python.org/moin/SummerOfCode/2013 If you're interested in mentoring with the PSF and aren't already on the 2013 mentors mailing list, please get in touch with me ASAP. Terri ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The end of 2.7
If from the start you use: - six ... There's the rub. We are not blessed with Guido's time machine where I work. Much of the Python code we run was written long before six was a gleam in anybody's eye. Heck, some of it was probably written before some active members of python-dev graduated from high school. :-) I'm really amazed at how many people seem to have the impression that porting to Python 3 should be no big deal. Please go back and read Guido's post in this thread from yesterday. He identified many barriers to moving between versions. This is not really a Python-specific problem. All large organizations encounter this, and wind up supporting lots of legacy code, long after its original authors are gone. Go to monster.com and search for COBOL or Ada. As I wrote in my previous message, we are only now moving from 2.4 to 2.7. If moving to Python 3 wasn't going to be much more difficult, I think we would have attempted that. 2.7 Seemed like the better step though, especially considering its compatibility with 2.4 and the fact that it has a lot of things backported from Python 3 to ease the eventual transition to Python 3. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The end of 2.7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/08/2013 04:40 PM, Skip Montanaro wrote: I'm really amazed at how many people seem to have the impression that porting to Python 3 should be no big deal. FWIW, the effort of porting the modern bits of the Zope ecosystem (the ones I still use in Pyramid apps today, meaning the component architecture, the ZODB, and a few others) soaked up basically all of my FLOSS time between the two Santa Clara PyCons. To be fair, some of that effort went into improving test coverage, docs, etc., to ensure that the apps running against the ported librarties wouldn't break, even on Python2: but is was *not* a trivial effort. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlFjMdYACgkQ+gerLs4ltQ62mACfSxdVNlTpSusR5MGMmuIw7lhf 3yIAoIJd6P8KoewUAjJnViuziWQWPHb8 =Bpul -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The end of 2.7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Apr 08, 2013, at 05:08 PM, Tres Seaver wrote: FWIW, the effort of porting the modern bits of the Zope ecosystem (the ones I still use in Pyramid apps today, meaning the component architecture, the ZODB, and a few others) soaked up basically all of my FLOSS time between the two Santa Clara PyCons. To be fair, some of that effort went into improving test coverage, docs, etc., to ensure that the apps running against the ported librarties wouldn't break, even on Python2: but is was *not* a trivial effort. I've ported a ton of stuff, most of it not written by me. The actual job of porting (not counting convincing your manager to let you do it) will either be easy and quick or painful and difficult wink. It's often hard to know before you start. It almost always comes down to bytes vs. strings, IME. Sometimes, the code you're porting has a clear model and you just have to understand it, and then the porting goes fairly smoothly. Often, the model isn't clear or there *is* no distinction, in which case your life will suck. It's important to realize that everyone doing porting work now is also making Python 3 better by helping to find the pain points in the language and stdlib. The u-prefix is a perfect example of this. .format() on bytes (issue3982) and some of the discussions around issue17445 are two examples where we're at least identifying additional pain, if not yet fixing it. Python 3.3 is easier to port to than 3.2 is. I hope that we'll be able to take all of our experiences and funnel that into 3.4 to make it a better porting target still. Then, even though people will still be using Python 2 when Orlijn is BDFL, we'll at least be making progress. We also want to make 3.4 and future Python 3 releases so compelling that starting new projects in Python 3 will be a no-brainer, and we want to make sure that the batteries, both in the stdlib and 3rd party are up to the task. Eventually Python 2 programmers will be like today's COBOL programmers (which is good for future employment prospects :), but there's more Python 3 code out there waiting to be written than there is existing Python 2 code today. :) Don't worry about what you *can't* port! - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRYz8jAAoJEBJutWOnSwa/lsQP/jyIYBzfl9eDXw81Ar4t+Uls 7JOYfQqQXhMXL2f1XLHivCplhso0YBZn2ZepXJ9kLJ4SnO7bPZbo+esD99IoAlhG QXjlvUnrSsc9mQG16HeuQLHjRmiZPg/mT+ACPuv3/ixxZggaKga7Jdcr2Xpo4KIS 89WzG2MWYhVGr3o28AAgSkSN/4fbmXRzjwmox0QjyhPdM6CWbTLO5KkF1cOLIXi/ UyYmlZAwSqVxR6cVRsGVwLStUy417UwZnc0h71IJxgRwgXOZDXzVKPvy/JqbVsK7 451aWB/mTkiaKkp+Qi0ebjZLLmSyEITS8DOurZKIy4Qfppyqy+patwazsY113zAg wdexiFfFc2W4zLFflxTScqULFJulYyL7KzSsQBHPcou1G5nDUVXBXoM+AC71EBtd TE+tyAhZWE38/mfDtOBCJCkJzevzJWF4tpGVgm1Gd5hSU7M8Yb2NQcZLYY0UxzZK weDItJUYTSYEQh6j9nBlZGaX9v62SnXPlZaV2s9/bbVFsHekwYQcEAFlpGUqeUxi KFFzS1GUl8IE8ZcHJDVW6U3YXzBSUKdSBa55IHw5hD+I730WAj8wq8aH7yFhyyzv jyFRdhtEFhapnA2zpxogFGVLPRjl9iOphfVnUR6wNuh7q+226GsqHyaMbkWBM9Cb sg39ITeWH6C0jMMxiGfx =ZAcF -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The end of 2.7
It almost always comes down to bytes vs. strings, IME. Cool, next time I have to port an extension written in C/C++ I'll be looking only for bytes vs. strings problems. I knew it was easy. Thanks ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
