Code that will break in Python 4 • Hacker News Board

Re: Code that will break in Python 4

#181

Post by [deleted] » Tue, Jan 12, 2016, 9:07 PM UTC

colanderman wrote: post #142

rogerbinns wrote: post #131

Earlier quoted context omitted.

Are you expecting the same running interpreter to have both python 2 and 3 modules at the same time, with calls between the modules working? You can easily keep things separate - python 2 executable is named python while python 3 is python3. https://www.python.org/dev/peps/pep-0397/ Sadly concurrent running in the same interpreter won't work because Python 3 has different types for strings (unicode only) and a bytes…

Yes, that is what I expect. The various flavors of C and C++ get along just fine that way. C++ is not a superset of C: http://stackoverflow.com/a/1201840/270610 C and C++ have a similar issue with strings. C code uses NUL-terminated char arrays, while C++ generally uses std::string. If you want to interface the two, you need glue code (written in C++). Surely Python 3 can work the same way: to share strings between a…

[deleted]

Re: Code that will break in Python 4

#182

Post by rjurney » Tue, Jan 12, 2016, 9:13 PM UTC

Latty wrote: post #157

vegabook wrote: post #143

Earlier quoted context omitted.

...which begs the question: why are there any differences at all!

Because the differences were important and central to the language.

print "HI" # oh my god, the horror!

print("HI") # yaaaah, order out of chaos

Unconvincing.

Re: Code that will break in Python 4

#183

Post by rjurney » Tue, Jan 12, 2016, 9:14 PM UTC

vegabook wrote: post #166

Latty wrote: post #157

Earlier quoted context omitted.

Because the differences were important and central to the language.

Only central to the pedants who wanted to "clean it up", and not central to the user base which, as anybody can see, is now cleaved into two warring factions, a result which is far worse than any of the marginal "improvements" can compensate for.

This, so much. Python 3 has failed in the market. A reboot is needed.

Re: Code that will break in Python 4

#184

Post by BuckRogers » Tue, Jan 12, 2016, 9:26 PM UTC

douchescript wrote: post #172

BuckRogers wrote: post #150

Guido has stated to not compare semver in the past.[0] Will there be a 3.10 or go to 4.0 after 3.9, per one of his core developers?[1] It's hard to tell with Python's leadership (no intentional mockery of the term leadership). My guess is that they'll indeed push onwards to Python4 as soon as possible. This being another attempt to make Python2 look as old and crufty as possible. "You're still on Python2? Wow, I'm on…

Amen! Ruby managed the transition to unicode much better as they delivered 2x performance increase at the same time AND labeled the new version 1.9 instead of two. Much the same problem. Yes python 2 is OK but it's legacy mode and people will move on. I think one of the selling points of python vs ruby is that its so often OK to just use system python(2) versus ruby where you really need to use something like rbenv.…

No breaking change was required for that. :) The PyPy guys have removed the GIL with existing Python2 code.[0] The CPython core dev team doesn't want to work that hard though- they've just created a lot of needless work for others with their decisions.

You're right though, unless someone takes on the mantle of CPython2, we're looking at being forced to move to 3 or find something else. I personally think '16/'17 will be the year(s) of Swift. With the Perfect server-side Swift framework[1], and more sure to come, it's very intriguing.

I'm a pretty conservative user myself, and dislike churn and feature bloat so I'm also fairly attracted to Go. I'm not suggesting that's Swift by any means. Go promised no breaking changes for a long time so it's a good choice to write long-lived software in (and who knows what will and won't end up being long-lived so we should always assume the latter).

[0]http://morepypy.blogspot.com/2015/03/pypy-stm-251-released.h...

[1]http://perfect.org/

Re: Code that will break in Python 4

#185

Post by Grue3 » Tue, Jan 12, 2016, 9:52 PM UTC

verbatim wrote: post #163

Grue3 wrote: post #156

Earlier quoted context omitted.

Please elaborate. Which feature of Python 3 would be impossible to implement in Python 2? Note that Python 3 code is not guaranteed to work in Python 4, but you are guaranteed to (relatively) painlessly port it, since all Python 3 features are implemented in Python 4 in some way.

Pick a Python 3 feature and let us know how you would implement it in Python 2.

Easy.

Feature: print function.

Implementation: from __future__ import print_function

Yes, that magical, backwards-incompatible, print function has been in Python 2 all along!

Feature: unicode strings

Implementation: from __future__ import unicode_literals

Amazing! The magical, backwards-incompatible unicode strings backported to Python 2 with one single line.

I could go on and on.

Re: Code that will break in Python 4

#186

Post by andreasvc » Tue, Jan 12, 2016, 9:59 PM UTC

CamperBob2 wrote: post #170

pearjuice wrote: post #117

To be honest, I am quite surprised that even in Python 4 whitespace is still an integral part of the syntax.

Too many egos at stake, at this point. Whitespace will always be syntactic in Python because nobody with any influence wants to admit it's a mistake.

That's not an argument, you could say the exact same thing about braces in other languages. Truth is, it's something that works that really doesn't need to be debated to death like it is.

Re: Code that will break in Python 4

#187

Post by Arnavion » Tue, Jan 12, 2016, 9:59 PM UTC

gruez wrote: post #148

renata wrote: post #89

Earlier quoted context omitted.

This search turns up some quite a few results, including some OpenJDK code: https://searchcode.com/?q=if%28version%2Cstartswith%28%22win... .

that's irrelevant because Microsoft fakes version information for applications by default[1]. [1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms7...

Whether or not it's true, it's certainly not irrelevant. Application manifests only apply to applications. If an application aware of W10 loads a third-party plugin that isn't, the plugin will still get the real version.

This is a very real scenario when you consider the application is explorer.exe and the plugin is any software that installs custom context menu actions.

Re: Code that will break in Python 4

#188

Post by CamperBob2 » Tue, Jan 12, 2016, 10:07 PM UTC

andreasvc wrote: post #186

CamperBob2 wrote: post #170

Earlier quoted context omitted.

Too many egos at stake, at this point. Whitespace will always be syntactic in Python because nobody with any influence wants to admit it's a mistake.

That's not an argument, you could say the exact same thing about braces in other languages. Truth is, it's something that works that really doesn't need to be debated to death like it is.

Yet strangely, hardly anyone complains about braces. I wonder why?

Re: Code that will break in Python 4

#189

Post by hyperpape » Tue, Jan 12, 2016, 10:07 PM UTC

colanderman wrote: post #142

rogerbinns wrote: post #131

Earlier quoted context omitted.

Are you expecting the same running interpreter to have both python 2 and 3 modules at the same time, with calls between the modules working? You can easily keep things separate - python 2 executable is named python while python 3 is python3. https://www.python.org/dev/peps/pep-0397/ Sadly concurrent running in the same interpreter won't work because Python 3 has different types for strings (unicode only) and a bytes…

Yes, that is what I expect. The various flavors of C and C++ get along just fine that way. C++ is not a superset of C: http://stackoverflow.com/a/1201840/270610 C and C++ have a similar issue with strings. C code uses NUL-terminated char arrays, while C++ generally uses std::string. If you want to interface the two, you need glue code (written in C++). Surely Python 3 can work the same way: to share strings between a…

I wonder if there's even a reasonable way to do this in Python. In C, strings are data that you're explicitly passing around, but in Python, you are constantly calling __getattribute__ under the hood just to execute your code.

I don't know that it would be impossible to make that all work, but I wouldn't assume that it is.

Re: Code that will break in Python 4

#190

Post by d23 » Tue, Jan 12, 2016, 10:17 PM UTC

pricechild wrote: post #178

How come the title was changed?

The problem with changing this one in particular is that it actually makes the author look more reasonable. I wonder if this would have nearly as many upvotes with the absurd headline it was actually written with.