Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New features you can't use unless you are in Python 3

asmeurer.com

Post reply on HN
Print view View original

141–150 of 264 posts

Re: New features you can't use unless you are in Python 3

#141

Post by worldeight »

rsj_hn wrote: post #76
Fej wrote: post #20

Does anyone use 2.x by choice? I've only seen it required as to not break legacy code.

Most people who use a language are actually working on code that existed before yesterday. I work on a codebase that was written in python 2, and when we looked at the cost of upgrading it to python 3 versus adding new features, it was a no brainer. I have no desire to switch to python 3, nor do I anticipate ever doing so, at least for the projects I'm working on now. If you are maintaining a large or important codeb…

As an independent contractor maintaining large Python 2 codebases, your comments really hit home for me. I only have a portion of my time each month to maintain and develop features for them. If the Python 2 floodgate ever breaks, I am more likely to rewrite the system in a statically typed language. Even today, I am tempted.

I know that a sibling mentions the ridiculousness of the situation, but a forced depreciation of the Python 2 runtime (see also, Windows) is a billable, justifiable, reason to do the work of refactoring parts of the system. I do not expect those billable hours to happen in the next decade, however.

Re: New features you can't use unless you are in Python 3

#142

Post by coldtea »

iak8god wrote: post #90
rsj_hn wrote: post #76

Earlier quoted context omitted.

Most people who use a language are actually working on code that existed before yesterday. I work on a codebase that was written in python 2, and when we looked at the cost of upgrading it to python 3 versus adding new features, it was a no brainer. I have no desire to switch to python 3, nor do I anticipate ever doing so, at least for the projects I'm working on now. If you are maintaining a large or important codeb…

> if we are forced to stop using python 2, we'll probably need to switch the project over to Java. This is just silly. It will take at least 100x more effort to rewrite the project in Java than it would to upgrade to Python 3. > at least the java community doesn't force developers to rewrite their source code when a new JVM comes out Yes, that was an unfortunate, one-time thing for Python that happened almost a decad…

>This is just silly. It will take at least 100x more effort to rewrite the project in Java than it would to upgrade to Python 3.

Yes, but in return it will bring a 10x performance improvement in lots of areas, and the option of a whole lot more sturdy statically checked code.

Re: New features you can't use unless you are in Python 3

#144

Post by dragonwriter »

jacquesm wrote: post #138
dragonwriter wrote: post #129

Earlier quoted context omitted.

> Overloading operators for cute purposes is usually a misfeature Whether a function for which an operator is overloaded is “cute” or “fundamental to clarity” depends on the context in which it is used. > There was a fad for this in the early C++ days. Yeah, like overloading the bitwise shift operators as stream insertion/extraction operators. > Python's classic overload problem comes from using "+" for concatenate.…

> Whether a function for which an operator is overloaded is “cute” or “fundamental to clarity” depends on the context in which it is used. The fact that it requires context other than the language spec is where the problem resides. The cognitive overhead of reading code is high enough without having to alias common operators.

> The cognitive overhead of reading code is high enough without having to alias common operators.

The cognitive overhead of reading code is, IME, often lower with context-approprate operator overloading (just as it is with well-chosen vs. poorly-chosen method names.)

There is a reason human languages (and, yes, even the notation of mathematics) develops context-specific dialects, and it is to reduce the cognitive overhead of communication. Code switching with clear contextual boundaries is often far more efficient than using a one-size-fits-all notation that is context-insensitive.

Re: New features you can't use unless you are in Python 3

#145

Post by lottin »

morinted wrote: post #74

I really like the format strings in Python 3.6: https://docs.python.org/3/whatsnew/3.6.html#whatsnew36-pep49... Seems that this set of slides (which were very informative!) is for up to 3.5

How many format strings does Python have already?

Re: New features you can't use unless you are in Python 3

#146

Post by baq »

lottin wrote: post #145
morinted wrote: post #74

I really like the format strings in Python 3.6: https://docs.python.org/3/whatsnew/3.6.html#whatsnew36-pep49... Seems that this set of slides (which were very informative!) is for up to 3.5

How many format strings does Python have already?

https://pyformat.info/ should know, ask it

Re: New features you can't use unless you are in Python 3

#148

Post by baq »

coldtea wrote: post #142
iak8god wrote: post #90

Earlier quoted context omitted.

> if we are forced to stop using python 2, we'll probably need to switch the project over to Java. This is just silly. It will take at least 100x more effort to rewrite the project in Java than it would to upgrade to Python 3. > at least the java community doesn't force developers to rewrite their source code when a new JVM comes out Yes, that was an unfortunate, one-time thing for Python that happened almost a decad…

> This is just silly. It will take at least 100x more effort to rewrite the project in Java than it would to upgrade to Python 3. Yes, but in return it will bring a 10x performance improvement in lots of areas, and the option of a whole lot more sturdy statically checked code.

if performance is a problem, then start rewriting the critical pieces right now because python 2 also isn't for you.

mypy is a much better type system than Java, btw, if that's what you're after.

Re: New features you can't use unless you are in Python 3

#149

Post by dagw »

matthewmacleod wrote: post #14

Ruby's 1.8 to 1.9 transition seemed to go much smoother - I'm curious what the difference is. Just down to what is essentially better source comparability I guess.

Ruby managed to get their major libraries ported to 1.9 much much quicker. RoR basically worked from day 1. Python 3 was without both numpy as django for well over a year. Also the first few releases of python 3 weren't very good. It wasn't before 3.2 before you could really use python 3 in production and not before 3.5 before most of the interesting features where in place. Basically a lot of early momentum was lost due to this and and it never really regained it.

Re: New features you can't use unless you are in Python 3

#150

Post by saghm »

mahyarm wrote: post #147

It's funny how the differences between python 2.7 & 3.x is less than swift 2 to 3, yet python stays in 2.7 land forever.

Probably because there was a lot less Swift code than Python in the wild at the respective times each came out with the new version, so having everyone upgrade all the old, incompatible code was less daunting.
Post reply on HN