1. 11
  1.  

  2. 20

    As a long-time pythonista, I hope this stays in a niche somewhere. This is probably labor of love, but it would only confuse the matter more if a distro actually shipped it.

    1. 5

      I doubt they could ship it (at least with the name it currently has) due to trademark issues: https://github.com/naftaliharris/python2.8/issues/47

      1. 0

        As a long-time pythonista

        … I can’t wait to package this baby for my distro and start using it in production. May Python3 die a terrible death in the recycling bin of history!

        Seriously, though, why would you be afraid of some proper competition? Did you also hope that pypy would “stay in a niche somewhere”?

        1. 8

          Python 2 Unicode story sucks. Most ASCII-only developers totally ignore the difference and mix strings and bytes freely, leading to horrible failures when you attempt to use their applications anywhere else in the world. I have had a decent load of issues related to Unicode handling in CKAN and having the sensible defaults of Python 3 would basically prevent all of that.

          1. 2

            the sensible defaults of Python 3

            See http://lucumr.pocoo.org/2014/5/12/everything-about-unicode/ or my favourite comparison - Django’s force_text() function:

                        if six.PY3:
                            if isinstance(s, bytes):
                                s = six.text_type(s, encoding, errors)
                            else:
                                s = six.text_type(s)
                        elif hasattr(s, '__unicode__'):
                            s = six.text_type(s)
                        else:
                            s = six.text_type(bytes(s), encoding, errors)
            
            1. 4

              about force_text: you speak of a function which is only necessary because the python 2 confusion between bytes and strings ?

              about armin ramblings : do you really think that sticking with posix madness which treat erroneous input as acceptable input and propagate to all dark corner of your program to crash randomly is a super good idea ?

              1. 3

                It’s interesting that you point to Armin Ronacher’s blog post, given his later writing on the subject

                1. 1

                  What is wrong with Django’s force_text function? This function is a short-hand for doing things like forcing translation strings.

                  1. 1

                    It’s production-quality code showing that Unicode handling in Python 3 is not any cleaner than in Python 2. That code is written in a Python subset that runs in both languages and uses a special wrapper library to make things easier, so it’s the perfect setting to do a comparison.

                    1. 9

                      You can do the “right thing” in Python 2 and Python 3. But you can also do the wrong thing in Python 2, but not in Python 3:

                      from sys import argv
                      with open(argv[1], 'rb') as f:
                          json.loads(f.read())
                      
                      >>> cat in.txt
                      "Hello World"
                      
                      >>> iconv -f SHIFT-JIS -t UTF-8 in-shift-jis.txt
                      "月曜日"
                      

                      In python 2 , this program will work when receiving in.txt but not when receiving in-shift-jis.txt, because there’s implicit bytes to text conversion. The program is broken in Python 2, but you will not find this out unless you properly test files with different encodings. Bytes are not text, and Py2’s implicit conversion hides many bugs

                      In python 3, this program will blow up when receiving in.txt as well as in-shift-jis.txt, because there is no more implicit bytes-to-text conversion, and json.loads expects text, but got bytes from the file handle.

                      Python 3 helps me catch these bugs (type errors, really). Python 2 not only hides these errors, but encourage almost cargo-cult level spurious .encodes everywhere that will inevitably lead to data corruption.

              2. 6

                May Python3 die a terrible death in the recycling bin of history!

                You do realize it’s a work of people who (presumably) provide you with something you can build upon without lock-in and for free? And I mean Python in general, not any particular version. Show some respect at least, even if you disagree on technical matters.

                1. [Comment from banned user removed]

                  1. 3

                    So they are assholes because they don’t provide you with (more) free work that would save you from doing free work for people who actually do pay you (but not for this)?

                    Some classy act you are.

                2. 3

                  What are you motivations for packaging this? Why is this such a big deal for you?

                  1. 1

                    I use Python2 and I hate it that it only gets bug fixes, threats of discontinuation and slander from the core Python devs.

                    I have no intention of switching to Python3, so any project taking over from where those morons left off is a bloody godsend.

                    1. 3

                      Seriously: What do you think got worse in Python 3? Is this just about the transition cost (perfectly valid reason!), or do you think there’s some more fundamental issues.

                      1. 0

                        You should demand they refund every red cent you’ve paid for it.

                        1. 4

                          You’re under the impression that you can only criticize what you bought?

                3. 2

                  related - link

                  1. 1

                    anyway the ship is already landed and pretty much zero new development will target this flavor of python (either they will stick with python 2.7 functionalities or they will jump to use python 3) ten years ago it would be a threat to python 3.

                    1. 0

                      Nice work, but perhaps making a new fork that might result in code incompatible with both of the existing versions is not the best way to solve the problem of having two incompatible versions?

                      https://xkcd.com/927/