About Python 3 • Hacker News Board

Re: About Python 3

#231

Post by Pxtl » Tue, Dec 31, 2013, 12:43 AM UTC

xradionut wrote: post #185

cies wrote: post #166

Earlier quoted context omitted.

i like fast movement, i like communities that dare to break things every now and then (see semver.org for the widely accepted versioning rules and should be honoured). much do i prefer an increasingly better solution to a stable one. i'm not agueing "perfect" over "good enough"; i'm argueing "awesome" over "good enough" :)

You might be a great Microsoft developer. Use this API, no this one, nope now this one, you almost caught up, so we released a newer, more better one! Please buy Awesome Studio and RDMS 2015 or you are a loser. Here's a free version that can't do shit, the Pro version is only $2000, plus lots of your time adjusting to a newer mono/flat chrome development environment. Hot keys only for touch screen users!

No, Microsoft never breaks anything. They deprecate relentlessly and push out new libs to replace old ones, but they never have the balls to actually fix anything. It's immensely frustrating that no lib ever reaches better than 80% good. It goes "1.0broken -> 1.1usable -> 2.0baroque -> 2.1deprecated -> Replacement lib 1.0broken".

Re: About Python 3

#232

Post by donaldstufft » Tue, Dec 31, 2013, 12:52 AM UTC

saurik wrote: post #227

aidos wrote: post #217

Earlier quoted context omitted.

I'm not sure there's any substance to what you're saying. The comments on here certainly don't reflect the attitude you've suggested they should. I obviously can't speak for anyone but myself but for me the reason not to change has been that there's a critical core of libraries that weren't ported over. Now the list isn't looking too bad and it's probably time to make the switch. It's taken a long time to get to that…

So, I'm going to agree with your first comment: today things are much better than normal, and I apparently skimmed the top-level comments too quickly and didn't give them enough credit. I've taken the parts of what I said that I believe you are correct for pointing out "are in error", modified them, and will go so far as to apologize for not giving today's thread enough consideration. > I obviously can't speak for an…

Realistically there is a value to porting to Python 3, in a year and some months Python2 will no longer be receiving security updates from Python Core. This will get taken care of by third parties for awhile but I fully suspect this support to be incomplete and eventually relegated only to RHEL.

Re: About Python 3

#233

Post by Argorak » Tue, Dec 31, 2013, 1:00 AM UTC

cookiecaper wrote: post #216

Argorak wrote: post #177

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…

There's plenty of rapid iteration in the Python world, and as far as I know, there is no fundamental disagreement with the concepts behind rapid iteration. Development still occurs in the open, but releases are well-planned and well-versioned such that backward incompatibilities are clearly billed and rarely introduced if not necessary. Pyramid is an exemplary Python project that has very rapid development but still…

I didn't talk about release processes. There are lots of projects with mature release processes in the Ruby world. What I meant is that agressively replacing parts that became obsolete or turned out problematic is much more accepted.

> Python is more likely to be used by mature engineers than Ruby.

It is very sad that you waste a good post for such an ungrounded attack.

Re: About Python 3

#234

Post by jpatokal » Tue, Dec 31, 2013, 1:02 AM UTC

Argorak wrote: post #177

thatthatis wrote: post #156

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…

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…

The problem with the fast-evolving Ruby approach is the cost of staying up to date. I was intimately involved with several projects to upgrade nontrivial codebases from Rails 2/Ruby 1.8 to Rails 3/Ruby 1.9, and these consumed serious amounts of engineering time and introduced lots of obscure bugs, with the primary benefit simply being not getting pwned when the next exploit comes trundling along. Fortunately our management understood and was willing to put up with the pain, but many (most?) would not.

Now, I work primarily with Python 2.7, with migration to 3 being a distant pipe dream. After years of Rubying, I find it a bit old-fashioned, awkward and occasionally infuriating (strings default to ASCII? srsly?) -- but I do appreciate knowing that I will not have to rewrite everything anytime soon.

Re: About Python 3

#235

Post by Argorak » Tue, Dec 31, 2013, 1:15 AM UTC

jpatokal wrote: post #234

Argorak wrote: post #177

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…

The problem with the fast-evolving Ruby approach is the cost of staying up to date. I was intimately involved with several projects to upgrade nontrivial codebases from Rails 2/Ruby 1.8 to Rails 3/Ruby 1.9, and these consumed serious amounts of engineering time and introduced lots of obscure bugs, with the primary benefit simply being not getting pwned when the next exploit comes trundling along. Fortunately our mana…

The 1.8/1.9 switch was problematic and can be seen in parallel with the python 2.7/3.x switch. Rails 2/Rails 3 was a similar big jump that reengineered the whole framework. Rails 4 was a much tamer release in that regard.

But one has to realize that 1.8 was the series of Ruby that was started _before_ Ruby even got popular (I started Ruby using 1.6, which was even more problematic). So being aggressive in breaking stuff with the next iteration (basically, to do it proper, with more manpower and data to work on) also opened up a lot - for example, Ruby 1.9 to 2.0 is a much simpler switch and I have many clients running 2.0 now and testing on 2.1.

The fear I always have with python 2.7 is the distant future. It just irritates me to have a huge migration in front of me. The Rubyist in me wants to keep up with the current state of things.

Re: About Python 3

#236

Post by sly010 » Tue, Dec 31, 2013, 1:18 AM UTC

martincho wrote: post #94

What is needed is a very high quality Python 2.x to 3.x migration or conversion tool to make library conversions trivial. If developers knew they could convert any 2.x code to 3.x code with no effort at all and with absolute certainty of proper operation they would probably migrate to the latest 3.x release en-masse. How difficult would something like this be? This might be really naive on my part. I haven't really t…

TBH i never understood the reason for 2to3. Wouldn't a 3 to 2 compiler would be much better? Then people could start using python3 as intended, and simply compile back to python2 if they need to. I doubt there is anything it python3 that would be impossible to emulate with machine generated python2. And no one would care how the compiled python2 code looks, because it would be temporary.

Re: About Python 3

#237

Post by deathanatos » Tue, Dec 31, 2013, 1:19 AM UTC

keyme wrote: post #212

Flimm wrote: post #178

Earlier quoted context omitted.

> Default unicode strings are obscenely annoying to me. Almost all of my code deals with binary data, parsing complex data structures, etc. The only "human readable" strings in my code are logs. Why the hell should I worry about text encoding before sending a string into a TCP socket... If your Python 3 code is dealing with binary data, you would use byte strings and you would never have to call encode or touch UTF-8…

> you would use byte strings and you would never have to call encode or touch UTF-8 before passing the byte string to a TCP socket. I'll start by adding that it's also incredibly annoying to declare each string to be a byte string, if this wasn't clear from my original rant. Additionally, your advice is broken. Take a look at this example, with the shelve module (from standard library). s=shelve.open('/tmp/a') s[b'ke…

> Additionally, your advice is broken. Take a look at this example, with the shelve module (from standard library).

His advice was sound, and referred to your example of TCP stream data (which is binary). Your example regards the shelve library.

> So in this case, my byte string can't be used as a key here, apparently.

shelve requires strings as a keys. This is documented, though not particularly clearly.

> so your advice about "just using byte strings" is invalid.

Let me attempt to rephrase his advice. Use bytestrings where your data is a string of bytes. Use strings where your data is human-readable text. Covert to and from bytestrings when serializing to something like network or storage.

> Conversions are inevitable.

Absolutely, because bytestrings and (text)strings are two different types.

> And this annoys me.

There is no real alternative though, because there is no way to automatically convert between the two. Python 2 made many assumptions, and these were often invalid and led to bugs. Python 3 does not; in places where it does not have the required information, you must provide it.

> when implementing existing protocols, or reading file formats that don't use Unicode.

I'm afraid it's still the same. A protocol that uses unicode requires you to code something like "decode('utf-8')" (if UTF-8 is what it uses), one that does not requires "decode('whatever-it-uses-instead')". If it isn't clear what encoding the file format or protocol stores textual data in, then that's a bug with the file format or protocol, not Python. Regardless though, Python doesn't know (and can't know) what encoding the file or protocol uses.

Re: About Python 3

#238

Post by _delirium » Tue, Dec 31, 2013, 1:22 AM UTC

Argorak wrote: post #177

thatthatis wrote: post #156

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…

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 updating by thinly stretched maintainers. Heck, old Fortran stuff is still in regular use, some of which hasn't been touched in years.

Re: About Python 3

#239

Post by brownbat » Tue, Dec 31, 2013, 2:11 AM UTC

As a beginner, not a professional developer, python 3 always made more sense to me. Print is a function, 1/2 is not 0.

I've heard the counterargument about backwards compatibility.[1] That hasn't ever been just a 2 vs. 3 thing though. pyOpenSSL works with 32-bit 3.2, but dies with errors out of the box on Win-64 py 3.3. Last I checked, the PaiMei debugger works on 2.4, breaks on 2.7.

There are several projects that work with a specific deprecated subversion... it'd be weird if that were a common argument to keep everyone on 3.2, or 2.4 or something.

[1] http://help.codecademy.com/customer/portal/articles/887853-w...

Re: About Python 3

#240

Post by coldtea » Tue, Dec 31, 2013, 2:24 AM UTC

steveklabnik wrote: post #92

greenlakejake wrote: post #90

Earlier quoted context omitted.

> Is it 100% feature complete or fast? No. If it's not feature complete it's vaporware.

By that definition, basically all software is vaporware.

Well, if they are programming languages, are still unstable 10 years late, have near zero adoption and are missing half of the promised features, then yes.