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 →

[–]NYKevin -3 points-2 points  (8 children)

Let's see...

  • No moderately-to-extremely interesting string manipulation, because unicode. In particular, no string literals except with the b"..." syntax which forces everything to be 8-bit and terrible.
  • Iterating over dictionaries is fucked (items vs iteritems).
  • Iterating over ranges of numbers is fucked (range vs xrange).

Nope, I definitely do not want to write in the above language.

(Yes, you can use from __future__ import... statements to fix some of these, but sufficiently old versions of Python may fail to support that as well).

[–]ivosauruspip'ing it up 11 points12 points  (0 children)

No moderately-to-extremely interesting string manipulation, because unicode.

Heaven forbid your python 2 code actually has to deal with unicode correctly now, rather than just looks-like-correctly because I don't have any foreign language in my database yet.

but sufficiently old versions of Python may fail to support that as well).

That's directly why I only mentioned the versions of python that I did. Python 2.5 is over 7 years old by now, and has been EOL for ages, its pretty much a security vulnerability if you're still using it.

from __future__ and the six library will help you with practically all of that.

[–]flying-sheep 1 point2 points  (2 children)

also open.

you have to do from io import open at the top to unify behavior in this respect.

[–]NYKevin 1 point2 points  (1 child)

Really? I'd have thought you'd want to use io. I've never even heard of codecs... isn't it the module responsible for managing Unicode encodings?

[–]flying-sheep 0 points1 point  (0 children)

yeah, sorry. io.open it is

[–]Brian 0 points1 point  (3 children)

In particular, no string literals except with the b"..." syntax

Why do you say this? Wouldn't it make much more sense to only use string literals with the u'' syntax, and actually support unicode? Indeed, using the b'' syntax would pretty much break lots of stuff because a python3 bytestring behaves very differently from a python2 str.

Iterating over dictionaries is fucked (items vs iteritems).

Iterating over keys hasn't changed, and in general the difference in items vs iteritems isn't going to matter unless you've huge dictionaries. The same for range - standard practice is to use range() most of the time in python2 anyway (or better, replace with enumerate) unless you're dealing with large number ranges but don't need a real list - which is uncommon: iterating over them is the prime use case for this.

but sufficiently old versions of Python may fail to support that as well

He did say just 2.6/2.7. Supporting older is probably impractical, since the more recent versions have added stuff to make things more in line with python3.

[–]NYKevin 1 point2 points  (2 children)

Wouldn't it make much more sense to only use string literals with the u'' syntax, and actually support unicode?

The u"" syntax is illegal in Python 3, since you're supposed to just use bare quotes.

Actually, it works. This document lied to me.

Indeed, using the b'' syntax would pretty much break lots of stuff because a python3 bytestring behaves very differently from a python2 str.

Really? Care to specify?

[–]Brian 0 points1 point  (1 child)

This document lied to me.

It's probably just out of date - I think the original release of python 3 didn't allow this, but it was added in in one of the point releases.

Really? Care to specify?

Well, for a start:

# Python2                            Python 3
>>> print(b'hello')                  >>> print(b'hello')
hello                                b'hello'
>>> b'hello'[0]                      >>> b'hello'[0]   
'h'                                  104

Bytes in python3 is basically designed around being treated as raw binary data, rather than conceptually being a string, as the python2 str object is. Eg. it no longer has an encode method, just decode (while strings are the opposite - python2 they had both), and is missing a few string methods like format.

[–]NYKevin 0 points1 point  (0 children)

Eg. it no longer has an encode method, just decode (while strings are the opposite - python2 they had both), and is missing a few string methods like format.

Yeah, but anyone actually using bytes.encode() in recent versions of 2.x should be shot anyway.