Live data from Hacker News

About Python 3

alexgaynor.net

301–310 of 358 posts

Re: About Python 3

#301
post #214
post #208

Earlier quoted context omitted.

Torvalds didn't put the "or any later version" clause in the Kernel's GPL license. And he hasn't required copyright assignments. Because of this, the kernel simply can't be converted to GPLv3. You would never be able to contact all the individual copyright holders and have them agree with complete consensus to re-licensing.

"I think it's insane to require people to make their private signing keys available, for example. I wouldn't do it. So I don't think the GPL v3 conversion is going to happen for the kernel, since I personally don't want to convert any of my code." He's spoken out against it personally - he cleary _doesn't like it_.

That quote referred to an interpretation of the initial public draft of GPLv3, which was radically different from the final version published in June 2007, including with respect to the so-called anti-Tivoization provisions. Of an interim draft of GPLv3 in March 2007, fairly close to what ended up being final, Linus said "Unlike earlier drafts, at least it does not sully the good name of the GPL".

However, you're correct that Linus clearly does not like even the released version of GPLv3.

[edited slightly]

Re: About Python 3

#302
post #284
post #271

Earlier quoted context omitted.

> Why the hell should I worry about text encoding before sending a string into a TCP socket... A string represents a snippet of human readable text and is not merely an array of bytes in a sane world. Thus is it fine & sane to have to encode a string before sticking it into a socket, as sockets are used to transfer bytes from point a to b, not text.

Not arguing that you're wrong, but Unix/Linux is not a sane world by your definition. Whether we like it or not (I do like it), this is the world many of us live in. Python3 adds a burden in this world where none existed in Python2. In exchange, there is good Unicode support, but not everyone uses that. I can't help but wonder if good Unicode support could have been added in a way that preserved Python2 convenience w…

ASCII by default is only an accident of history. It's going to be a slow, painful process but all human-readable text is going to be Unicode at some point. For historical reasons you'll still have to encode a vector of bytes full of character information to send it down the pipe but there's no reason why we shouldn't be explicit about it.

The pain is painful [in Python 3] primarily for library authors and only at the extremities. If you author your libraries properly your users won't even notice the difference. And in the end as more protocols and operating systems adopt better encodings for Unicode support that pain will fade (I'm looking at you, surrogateescape).

It's better to be ahead of the curve on this transition so that users of the language and our libraries won't get stuck with it. Python 2 made users have to think (or forget) about Unicode (and get it wrong every time... the shear amount of work I've put into fixing codebases that mixed bytes and unicode objects without thinking about it made me a lot of money but cost me a few years of my life I'm sure).

Re: About Python 3

#303
post #296

Earlier quoted context omitted.

> Python 3 runs on operating systems older than 2013 and, while it might not be the OS default, there is no reason a non-library project can't bundle its own interpreter in the distribution and use that instead of the OS default interpreter. You are absolutely right, but the overall cost of deployment skyrockets at that point. Not to mention pernicious bugs from grabbing the wrong library & whatever other weirdness h…

Surely any new project these days is using virtualenv (with a specified version of the python interpreter) + pip.

Projects 'of a given size', yes. But there are small projects, projects for Windows, projects where the fleet is managed and deploying full venvs isn't done... etc.

The niceities of greenfield work and what ought to be done start breaking down as you get into heterogeneous systems where total system stability (lack of change ) is a big deal, and these fleets have been running for a decade or so. Imagine having to figure out deployments to a Python 2.4 environment in 2012 (I had this problem).

To misquote a famous statement, you fight the battle with the troops you have, not the troops you want, against the enemy you have, not the enemy you want. The reality is that it's often (usually?) not worth it to ship full venvs with Py3. It's often much better to ship Py 2.7 code (just your own code) and install your own libraries in the system library location.

Re: About Python 3

#304
post #257

Earlier quoted context omitted.

Its an exceptionally ambitiously project which they are in no hurry in finishing. And that is for a good reason. Way back in the early days, the goal was to release a usable 6.0 in a couple of years. The "there's no hurry" line is a post hoc justification from around 2006 or so.

But has the goal of Perl 6 as a project remained static? I'm relatively new to the Perl community. I know you are around since a very long time. But I think the goal has changed from "Let's fix Perl 5" to being a more bigger goal of developing a language what Perl 5 would likely look after say 3 decades of iterations. I can't say if that is good from a purely practical perspective. But it does sound like worthwhile g…

But has the goal of Perl 6 as a project remained static?

The idea that it would be a series of incremental improvements to Perl 5 ended around 2001, and certainly by 2002 at the latest:

http://www.perl.com/pub/2000/11/perl6rfc.html

The grand unification of runtimes (Ponie) had failed long before the announcement of its demise in 2006:

http://www.nntp.perl.org/group/perl.ponie.dev/2006/08/msg487...

I suspect but can't entirely prove that the appearance, rapid ascent, and even more rapid burnout of Pugs made a lot of people realize that this would be a long slog. Even so, if you look back at mailing list messages or conference talks or blog posts in 2006, 2007, 2008, whenever, you'll see that the party line has always been "It's only a year or two away."

Re: About Python 3

#305
I'll be honest. I'm waiting until Guido says it's time.

The phrase that I have stored at the moment is "Python 3 is the future of Python." Fine. Great. But that's not good enough.

This page needs to be updated: https://wiki.python.org/moin/Python2orPython3

It should be shortened to read, in its entirety, "Python 3."

Re: About Python 3

#306

Earlier quoted context omitted.

This is where the Ruby and Python communities fundamentally disagree. The Ruby community is great at moving fast and replacing bad things, while the Python community takes a much slower approach to the whole thing. I wouldn't say any approach is better or worse, it has to fit your personal style. I like the Ruby approach, others love the Python approach. This means that Ruby breeds a lot of interesting stuff, but wit…

Differences in userbases could be part of it. Scientific computing is an increasingly important part of the Python community, for example, and they tend to be averse to backwards-incompatible changes. In part that's because you have many good but very lightly maintained libraries that stick around forever, so people prefer if they stay working when nobody touches them, rather than bitrotting and needing constant upda…

Furthermore, with scientific computing, it's important that code you publish in a journal (fossilizing it) can still be at least near-usable to others over time horizons of years to decades.

Re: About Python 3

#307
post #284

Earlier quoted context omitted.

Not arguing that you're wrong, but Unix/Linux is not a sane world by your definition. Whether we like it or not (I do like it), this is the world many of us live in. Python3 adds a burden in this world where none existed in Python2. In exchange, there is good Unicode support, but not everyone uses that. I can't help but wonder if good Unicode support could have been added in a way that preserved Python2 convenience w…

ASCII by default is only an accident of history. It's going to be a slow, painful process but all human-readable text is going to be Unicode at some point. For historical reasons you'll still have to encode a vector of bytes full of character information to send it down the pipe but there's no reason why we shouldn't be explicit about it. The pain is painful [in Python 3] primarily for library authors and only at the…

I was careful to say "Unix strings", not "ASCII". A Unix string contains no nul byte, but that's about the only rule. It's certainly not necessarily human-readable.

I don't think a programming language can take the position that an OS needs to "adopt better encodings". Python must live in the environment that the OS actually provides. It's probably a vain hope that Unix strings will vanish in anything less than decades (if ever), given the ubiquity of Unix-like systems and their 40 years of history.

I understand that Python2 does not handle Unicode well. I point out that Python3 does not handle Unix strings well. It would be good to have both.

Re: About Python 3

#308

I'm going to go against the grain here and say that moving slowly is one of my absolute favorite features about python and its libraries. Rails and django were released about the same time, rails is on version 4, django is on 1.6. Moving slowly means I can spend more of my time writing code and less of my time upgrading old code. More importantly, every release requires a perusal: did the API change, what's new, are…

There's plenty of value to the going-slow approach and Python should embrace that identity and the value that comes with it. However, having two incompatible versions of the language itself--and all of the confusion that comes along with that--is a major barrier to adoption and improvement of the language.

The mistake here was breaking backwards compatibility to begin with. But since that's long past us now, the problem that needs to be solved is how to reconcile the two versions. It's unrealistic to keep both 2.7 and 3.3+ around forever. How do we get to a single version of Python to keep the language and its community healthy?

Re: About Python 3

#309
post #147

I like Python 3. I prefer it. It is better to program in than 2.x. Iterators everywhere, no more unicode/encoding vagueness, sub-generators and more. It is a much better language and it's hard to see how it could have evolved without a clean break from its roots. However it has been interesting to follow over the last five years. It has been a sort of, "what if p5 broke the CPAN," scenario played out in real-life. Br…

I don't like Python 3. Iterators everywhere are incredibly annoying, especially with my development workflow, where I don't put a line of code into a file before I run it manually in the interpreter. When I run a map over a list, I just want to see the freaking results. Default unicode strings are obscenely annoying to me. Almost all of my code deals with binary data, parsing complex data structures, etc. The only "h…

Keyme, you and I are the few that have serious concern with the design of Python 3. I started to embrace it in a big way 6 months ago when most libraries I use are available in Python. I wish to say the wait is over and we should all move to Python 3 then everything will be great. Instead I find no compelling advantage. Maybe there will be when I start to use unicode string more. Instead I'm really annoyed by the default iterator and the binary string handling. I am afraid it is not a change for the good.

I come from the Java world when people take a lot of care to implement things as streams. It was initially shocking to see Python read an entire file into memory, turn it into list or other data structure with no regard to memeory usage. Then I have learned this work perfectly well when you have a small input, a few MB or so is a piece of cake for modern computer. It takes all the hassle out of setting up streams in Java. You optimize when you need to. But for 90% of stuff, a materialized list works perfectly well.

Now Python become more like Java in this respect. I can't do exploratory programming easily without adding list(). Many times I run into problem when I am building complex data structure like list of list, and end up getting a list of iterator. It takes the conciseness out of Python when I am forced to deal with iterator and to materialize the data.

The other big problem is the binary string. Binary string handling is one of the great feaute of Python. It it so much more friendly to manipulate binary data in Python compare to C or Java. In Python 3, it is pretty much broken. It would be an easy transition I only need to add a 'b' prefix to specify it as binary string literal. But in fact, the operation on binary string is so different from regular string that it is just broken.

  In [38]: list('abc')
  Out[38]: ['a', 'b', 'c']
  
  In [37]: list(b'abc')       # string become numbers??
  Out[37]: [97, 98, 99]
  
  In [43]: ''.join('abc')
  Out[43]: 'abc'
  
  In [44]: ''.join(b'abc')    # broken, no easy way to join them back into string
  ---------------------------------------------------------------------------
  TypeError                                 Traceback (most recent call last)
   in ()
  ----> 1 ''.join(b'abc')
  
  TypeError: sequence item 0: expected str instance, int found

Re: About Python 3

#310
post #147

Earlier quoted context omitted.

I don't like Python 3. Iterators everywhere are incredibly annoying, especially with my development workflow, where I don't put a line of code into a file before I run it manually in the interpreter. When I run a map over a list, I just want to see the freaking results. Default unicode strings are obscenely annoying to me. Almost all of my code deals with binary data, parsing complex data structures, etc. The only "h…

Keyme, you and I are the few that have serious concern with the design of Python 3. I started to embrace it in a big way 6 months ago when most libraries I use are available in Python. I wish to say the wait is over and we should all move to Python 3 then everything will be great. Instead I find no compelling advantage. Maybe there will be when I start to use unicode string more. Instead I'm really annoyed by the def…

  >>> bytes(list(b'abc'))
  b'abc'
  >>>
That is, the way to turn a list of ints into a byte string is to pass it to the bytes object.

(This narrowly addresses that concern, I'd readily concede that the new API is going to have situations where it is worse)

Post reply on HN