4 ms·

I'm glad Guido considers this a toy. Anyone interested in helping out the github repo is here: https://github.com/naftaliharris/placeholder https://github.com

by daveguy 10y ago

I'm glad Guido considers this a toy. Anyone interested in helping out the github repo is here: https://github.com/naftaliharris/placeholder https://github.com/naftaliharris/placeholder

didibus 10y ago
He's right though. Backporting features will be hard, and it looks like the wrong move. If you wanted to fork just fork, and evolve python 2.7 on its own. Why try to create an inferior python 3? I could see security fix releases be useful. Giving people more time to transition is going to benefit some projects. But in terms of feature, it does sound toyish. Appart from that, it actually doesn't look like there's any problem here. The maintener agreed to change the name. I don't expect this project to exist for very long unless it breaks free, but if it tries to just bring 3 features back to 2, I'm not sure it'll make sense for very long.
- unixhero 10y ago
  The problem is some of the massive python modules that cannot be ported from 2.7 to 3 .x
  - viraptor 10y ago
    Which ones specifically? Many massive ones that held out for a long time are either done or in the process of porting. (twisted, openstack, almost all web frameworks, etc.) PS. https://python3wos.appspot.com/ https://python3wos.appspot.com/ now shows only few packages not marked as compatible from the most popular ones. One group (carbon, graphite, supervisor) are not libraries so they don't really affect others. The other is specific moz* libraries - and they're for Mozilla's internal testing, so nobody else should care that much.
    - unixhero 10y ago
      Yes I was thinking about twisted
  - Tenobrus 10y ago
    Sure there are some, but several lists (for example, http://py3readiness.org http://py3readiness.org) show that over 95% of very popular packages support Python 3, and some only support Python 3. At this point while you might need 2 for some very specific purposes, 3 has the majority of important packages and new development.
    - unixhero 10y ago
      I stand corrected. I realize that it was 4 years ago, since I tried to learn Python ... And at that point in time key libraries, which I for instance read books to learn, twisted, was 2.7 only ...
  - chx 10y ago
    As I mentioned elsewhere, my go-to example was PCSC-Lite support. I thought it so old and obscure it will never happen. But look, https://pypi.python.org/pypi/pyscard/1.9.4 https://pypi.python.org/pypi/pyscard/1.9.4
- Orangeair 10y ago
  I agree. What exactly is the point of backporting features, when the main reason people give for wanting to use Python 2 is for legacy applications? What 8-year-old codebase is going to be updated to use `async`? And if you're starting a new project, why not write it in Python 3, which has first-party support?
  - hueving 10y ago
    >And if you're starting a new project, why not write it in Python 3, which has first-party support? Because you're importing big legacy python2 libraries.
- daveguy 10y ago
  > Why try to create an inferior python 3? I think the point is -- it will not be an inferior python 3. It will be a python 2 with the best non-code-breaking parts of python 3. Sane byte handling + bug fixes - breaking changes. That will make it a superior python 3.
  - rcthompson 10y ago
    How do you get sane byte handling without breaking backward compatibility? I thought that was the original reason for breaking compatibility in Py3k.
    - daveguy 10y ago
      Sane is py2. Default is bytes not some Unicode string. If you want Unicode use u"". If you want what is usually needed in algorithms (aka bytes) use "".
      - mfukar 10y ago
        > what is usually needed in algorithms Depends what you're working with, obviously.
      - cthalupa 10y ago
        If you think py2 is the sane one, then you must work on a project where everything is written and communicated in bone standard roman characters. For the vast majority of the actual planet, this simply isn't the case.
      - rcthompson 10y ago
        So you admit that byte strings and Unicode strings are different data types, yet you claim that Python 2 is the sane one for choosing to both using exactly the same class?
- naftaliharris 10y ago
  (I'm the primary author of this interpreter). > Backporting features will be hard It's actually pretty straightforward: I just find the relevant changes in the Python 3 history, and apply them to Python 2. Usually a handful of things have changed between 2 and 3, so I typically can't just pipe the diff to "git apply -3", but frankly backporting features is more tedious than difficult. If you're interested, for example, here's my recent implementation of the "nonlocal" keyword; you can see the commit messages reference the Python 3 commits: https://github.com/naftaliharris/placeholder/pull/60 https://github.com/naftaliharris/placeholder/pull/60 > Why try to create an inferior python 3? The ultimate goal is to build an interpreter that can run both Python 2 and 3 code. Unfortunately, there is some code that runs and has different behavior under Python 2 and Python 3 (e.g., 'print("a", "b")' ), so anyone who wants to write an interpreter that can run both kinds of code will need to decide what to do there. I decided to defer to Python 2 behavior in those cases, since most of my code is in Python 2 and I don't want to change it. :-)
  - ktRolster 10y ago
    The ultimate goal is to build an interpreter that can run both Python 2 and 3 code. That is a great goal, I fully support you. so anyone who wants to write an interpreter that can run both kinds of code will need to decide what to do there Even if the interpreter has to decide, "this file is python2, it will do it one way.....that file is python3, it will do it another way" that is good enough. As long as you can call functions and such between the two files.
  - dekhn 10y ago
    Thanks for working on this. I like some of the stuff in Python 3, but I don't see any compelling reason to switch to it; I'd much rather see the vast majority of features in 3 moved back to a 2 series interpreter. That most of the features can be moved back is, in itself, an important statement on whether 3 was necessary at all.
- MattConfluence 10y ago
  > Giving people more time to transition is going to benefit some projects. Python 3 was released in December 2008. Python 2.7 was released in July 2010, and was given 5 years of support which was then extended to 10. Those people who have not transitioned yet have not done so because of lack of time. They might have valid reasons for delaying, but time is not one.
  - TylerE 10y ago
    I disagree. When your dev team is totally busy working on features that customers are actually paying for, there is less than no business case for porting to Py3.
    - gspetr 10y ago
      In 2017 you may be right. In 2020? There will certainly be a business case once you get hit with an RCE in 2.7 because there will be no new security patches.
sametmax 10y ago
It is. You see, Python 2.8 cannot be compatible with 2 and 3 because some changes are mutually exclusive: - you need to choose either bytes or str, you can't have both. And Python 2 API have many functions accepting and returning bytes while Python 3 have many ones with unicode. - the C ABI and the byte code changed. - built-in changed. So you will have to choose between one behavior or the other and deal with it. This is what you do with the excellent six or Python-future libs. They let you write 2/3 compatible code, but the first thing they do is making you choose either the 2 or the 3 behavior.

by daveguy 10y ago

I'm glad Guido considers this a toy. Anyone interested in helping out the github repo is here: https://github.com/naftaliharris/placeholder https://github.com/naftaliharris/placeholder

didibus 10y ago

He's right though. Backporting features will be hard, and it looks like the wrong move. If you wanted to fork just fork, and evolve python 2.7 on its own. Why try to create an inferior python 3? I could see security fix releases be useful. Giving people more time to transition is going to benefit some projects. But in terms of feature, it does sound toyish. Appart from that, it actually doesn't look like there's any problem here. The maintener agreed to change the name. I don't expect this project to exist for very long unless it breaks free, but if it tries to just bring 3 features back to 2, I'm not sure it'll make sense for very long.

unixhero 10y ago
The problem is some of the massive python modules that cannot be ported from 2.7 to 3 .x
- viraptor 10y ago
  Which ones specifically? Many massive ones that held out for a long time are either done or in the process of porting. (twisted, openstack, almost all web frameworks, etc.) PS. https://python3wos.appspot.com/ https://python3wos.appspot.com/ now shows only few packages not marked as compatible from the most popular ones. One group (carbon, graphite, supervisor) are not libraries so they don't really affect others. The other is specific moz* libraries - and they're for Mozilla's internal testing, so nobody else should care that much.
  - unixhero 10y ago
    Yes I was thinking about twisted
- Tenobrus 10y ago
  Sure there are some, but several lists (for example, http://py3readiness.org http://py3readiness.org) show that over 95% of very popular packages support Python 3, and some only support Python 3. At this point while you might need 2 for some very specific purposes, 3 has the majority of important packages and new development.
  - unixhero 10y ago
    I stand corrected. I realize that it was 4 years ago, since I tried to learn Python ... And at that point in time key libraries, which I for instance read books to learn, twisted, was 2.7 only ...
- chx 10y ago
  As I mentioned elsewhere, my go-to example was PCSC-Lite support. I thought it so old and obscure it will never happen. But look, https://pypi.python.org/pypi/pyscard/1.9.4 https://pypi.python.org/pypi/pyscard/1.9.4
Orangeair 10y ago
I agree. What exactly is the point of backporting features, when the main reason people give for wanting to use Python 2 is for legacy applications? What 8-year-old codebase is going to be updated to use `async`? And if you're starting a new project, why not write it in Python 3, which has first-party support?
- hueving 10y ago
  >And if you're starting a new project, why not write it in Python 3, which has first-party support? Because you're importing big legacy python2 libraries.
daveguy 10y ago
> Why try to create an inferior python 3? I think the point is -- it will not be an inferior python 3. It will be a python 2 with the best non-code-breaking parts of python 3. Sane byte handling + bug fixes - breaking changes. That will make it a superior python 3.
- rcthompson 10y ago
  How do you get sane byte handling without breaking backward compatibility? I thought that was the original reason for breaking compatibility in Py3k.
  - daveguy 10y ago
    Sane is py2. Default is bytes not some Unicode string. If you want Unicode use u"". If you want what is usually needed in algorithms (aka bytes) use "".
    - mfukar 10y ago
      > what is usually needed in algorithms Depends what you're working with, obviously.
    - cthalupa 10y ago
      If you think py2 is the sane one, then you must work on a project where everything is written and communicated in bone standard roman characters. For the vast majority of the actual planet, this simply isn't the case.
    - rcthompson 10y ago
      So you admit that byte strings and Unicode strings are different data types, yet you claim that Python 2 is the sane one for choosing to both using exactly the same class?
naftaliharris 10y ago
(I'm the primary author of this interpreter). > Backporting features will be hard It's actually pretty straightforward: I just find the relevant changes in the Python 3 history, and apply them to Python 2. Usually a handful of things have changed between 2 and 3, so I typically can't just pipe the diff to "git apply -3", but frankly backporting features is more tedious than difficult. If you're interested, for example, here's my recent implementation of the "nonlocal" keyword; you can see the commit messages reference the Python 3 commits: https://github.com/naftaliharris/placeholder/pull/60 https://github.com/naftaliharris/placeholder/pull/60 > Why try to create an inferior python 3? The ultimate goal is to build an interpreter that can run both Python 2 and 3 code. Unfortunately, there is some code that runs and has different behavior under Python 2 and Python 3 (e.g., 'print("a", "b")' ), so anyone who wants to write an interpreter that can run both kinds of code will need to decide what to do there. I decided to defer to Python 2 behavior in those cases, since most of my code is in Python 2 and I don't want to change it. :-)
- ktRolster 10y ago
  The ultimate goal is to build an interpreter that can run both Python 2 and 3 code. That is a great goal, I fully support you. so anyone who wants to write an interpreter that can run both kinds of code will need to decide what to do there Even if the interpreter has to decide, "this file is python2, it will do it one way.....that file is python3, it will do it another way" that is good enough. As long as you can call functions and such between the two files.
- dekhn 10y ago
  Thanks for working on this. I like some of the stuff in Python 3, but I don't see any compelling reason to switch to it; I'd much rather see the vast majority of features in 3 moved back to a 2 series interpreter. That most of the features can be moved back is, in itself, an important statement on whether 3 was necessary at all.
MattConfluence 10y ago
> Giving people more time to transition is going to benefit some projects. Python 3 was released in December 2008. Python 2.7 was released in July 2010, and was given 5 years of support which was then extended to 10. Those people who have not transitioned yet have not done so because of lack of time. They might have valid reasons for delaying, but time is not one.
- TylerE 10y ago
  I disagree. When your dev team is totally busy working on features that customers are actually paying for, there is less than no business case for porting to Py3.
  - gspetr 10y ago
    In 2017 you may be right. In 2020? There will certainly be a business case once you get hit with an RCE in 2.7 because there will be no new security patches.

sametmax 10y ago

It is. You see, Python 2.8 cannot be compatible with 2 and 3 because some changes are mutually exclusive: - you need to choose either bytes or str, you can't have both. And Python 2 API have many functions accepting and returning bytes while Python 3 have many ones with unicode. - the C ABI and the byte code changed. - built-in changed. So you will have to choose between one behavior or the other and deal with it. This is what you do with the excellent six or Python-future libs. They let you write 2/3 compatible code, but the first thing they do is making you choose either the 2 or the 3 behavior.