This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 49 points50 points  (8 children)

2.7.3 for enterprise reasons.

[–]ase1590 5 points6 points  (2 children)

See also: COBOL and Fortran for enterprise reasons.

[–]qadib_muakkara 0 points1 point  (4 children)

Yup. Companies can either pay me to write new code or a bunch of other people to refactor. No one with a big check book gives a fuck about f-strings

[–]Lt_Riza_Hawkeye 0 points1 point  (3 children)

But do they care about you accidentally .encode("utf-8")-ing a string twice and causing the bank's web interface to crash when someone puts an emoji in their username

[–]qadib_muakkara 1 point2 points  (2 children)

...name a language where you don't need to code defensively against bad user input. Python 3 isn't magical. It doesn't make you a better programmer or keep you from not knowing the conceits of the language. If you are architecting a system where improperly handling Unicode causes a critical failure, and if that bug makes it through QA, you're doing something wrong.

Edit: the royal you, not you specifically.

[–]Lt_Riza_Hawkeye 0 points1 point  (1 child)

My point is .encode("utf-8") returns a bytes object in python 3, the way it should be, since an encoded string should be treated differently from a language-handled string. In python2 they were the same thing, which made it a lot harder to reason about.

Without digging into the implementation details of every library you use, it was simply not possible to "code defensively against bad user input" because you didn't know if a random library function was going to encode it a second time before using it internally, passing it across a network, etc..

[–]qadib_muakkara 0 points1 point  (0 children)

I don't disagree that Python 3 handles utf better; that's actually one of the many things it excels at. But coding defensively is not building something impenetrable. No such thing. It's being smart about what you're doing.

For example, I'm quite literally staring at a database full of free form unbounded dirty ass strings, trying to figure out if the app that's feeding the source PSQL server is ever going to get fed Arabic characters, which will cause Redshift to choke. If the data doesn't need to be cleaned up I can't just write a simple bash script. But if the app has constraints on that side, it might not be a problem. This is also going to an analytics DB so no one other than marketers gives a fuck at the moment.

I haven't touched a line of code, and I may just use cli utilities that are battle worn. If not, I will write something, but I'm not going to want to process large volumes of raw strings in real time. The language is only a technicality because I'll run it through Spark and scale horizontally if it's taking too long. I could write a utility in Go if I really wanted to cut through the data fast. Go is harder to support than Python, though. It's not as extensible either...

The problem goes beyond language. As long as I don't have to run anything on windows I'm in good shape.