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

About Python 3

alexgaynor.net

Post reply on HN
Print view View original

351–358 of 358 posts

Re: About Python 3

#351

Post by tungwaiyip »

maxerickson wrote: post #347
tungwaiyip wrote: post #341

Earlier quoted context omitted.

Thank you. This is good to know. I was rather frustrated to find binary data handling being changed with no easy translation in Python 3. Here is another annoyance: In [207]: 'abc'[0] + 'def' Out[207]: 'adef' In [208]: b'abc'[0] + b'def' --------------------------------------------------------------------------- TypeError Traceback (most recent call last) in () ----> 1 b'abc'[0] + b'def' TypeError: unsupported operan…

I don't have enough experience with either version to debate the merits of the choice, but the way forward with python 3 is to think of bytes objects as more like special lists of ints, where if you want a slice (instead of a single element) you have to ask for it: >>> [1,2,3][0] 1 >>> [1,2,3][0:1] [1] >>> b'abc'[0] 97 >>> b'abc'[0:1] b'a' >>> So the construction you want is just: >>> b'abc'[0:1]+b'def' b'adef' Which…

In Java, String and Char are two separate types. In Python, there is no separate char type. It is simply a string of length of 1. I do not have great theory to show which design is better either. I can only say the Python design work great for me in the past (for both text and binary string), and I suspect it is the more user friendly design of the two.

So in Python 3 the design of binary string is changed. Unlike the old string, bytes and binary string of length 1 are not the same. Working codes are broken, practice have to be changed, often it involves more complicated code (like [0] becomes [0:1]). All these happens with no apparent benefit other than it is more "coherent" in the eye of some people. This is the frustration I see after using Python 3 for some time.

Re: About Python 3

#352

Post by tripzilch »

dangayle wrote: post #219
danso wrote: post #205

Earlier quoted context omitted.

Correct me if my history is a little fuzzy, but isn't it Apple that plays the part of "move fast, worry later" so well? After all, Apple has been the front-runner when it comes to things like, "f--k your floppy/CD drive/FireWire/display-adapter, we're moving on", and that's just in hardware. Microsoft has actually done a pretty good job maintaining backwards compatibility, considering the size of their user base and…

It's not like you still couldn't plug in an old CD drive into your Mac. It will still work just fine. You can't plug in an old Python 2.x plugin into Python 3.x.

Why not. Are you familiar with SciPy's `weave` module? It's basically a plugin for plugging C++ code into your Python. In a variety of extremely cool compile-on-the-fly ways. It's really quite sweet :)

No reason you can't do that with Python 2.7. Should be easier in fact because the interface will be much thinner.

I am NOT saying this is a good idea however! Haha

Re: About Python 3

#353

Post by wilg »

q845712 wrote: post #315
userbinator wrote: post #249

Earlier quoted context omitted.

It seems that communities that mainly use programming languages for reasons of "getting stuff done" value backwards compatibility the most; they are the ones who would rather not have to spend the time "upgrading" things that used to work perfectly fine, and would rather use that time to do something more useful and related to their ultimate goals. Personally I think backwards compatibility is getting less attention…

"Imagine if [...] plugs changed every few months, with appliancemakers all adopting the newest backwards-incompatible version" like apple?

iPod/iPhone

October 2001 - Original iPod - FireWire

April 2003 - Third-Generation iPod - 30-pin Dock Connector

September 2012 - iPhone 5 - Lightning Connector

Apple Laptops

1998 - PowerBook G3 - Unnamed Circular Power Connector

2001 - PowerBook G4 - Smaller Unnamed Circular Power Connector

2006 - MagSafe

2012 - MagSafe 2

Re: About Python 3

#354

Post by agentultra »

dded wrote: post #338
agentultra wrote: post #321

Earlier quoted context omitted.

The converse problem is having to write iterator versions of map, filter, and other eagerly-evaluated builtins. You can't just write: >>> t = iter(map(lambda x: x * x, xs)) Because the map() call is eagerly evaluated. It's much easier to exhaust an iterator in the list constructor and leads to a consistent iteration API throughout the language. If that makes your life hard then I feel sorry for you, son. I've got 99…

> >>> list(b'abc') > [97, 98, 99] >That's not a list of numbers... that's a list of bytes! No, it's a list of numbers: >>> type(list(b'abc')[0]) I think the GP mis-typed his last example. First, he showed that ''.join('abc') takes a string, busts it up, then concatenates it back to a string. Then, with ''.join(b'abc'), he appears to want to bust up a byte string and concatenate it back to a text string. But I suspect…

> No, it's a list of numbers:

Well, yes. Python chooses the decimal representation by default. So? It could be hex or octal and still be a byte.

My example was merely meant to be illustrative and not an example of real code. The byte object is simply not a str; so I don't understand where this frustration with them not being str is coming from. If you use the unicode objects in Python 3 you get the same API as before. The difference is now you can't rely on Python implicitly converting up ASCII byte strings to unicode objects and have to explicitly encode/decode from one to the other. It removes a lot of subtle encoding bugs.

Perhaps it's just that encoding is tricky for developers who never learned it in the first place when they started learning the string APIs in popular dynamic languages? I don't know. It makes a lot of sense to me since I've spent years fixing Python 2 code-bases that got unicode wrong.

Re: About Python 3

#355

Post by tungwaiyip »

agentultra wrote: post #354
dded wrote: post #338

Earlier quoted context omitted.

> >>> list(b'abc') > [97, 98, 99] >That's not a list of numbers... that's a list of bytes! No, it's a list of numbers: >>> type(list(b'abc')[0]) I think the GP mis-typed his last example. First, he showed that ''.join('abc') takes a string, busts it up, then concatenates it back to a string. Then, with ''.join(b'abc'), he appears to want to bust up a byte string and concatenate it back to a text string. But I suspect…

> No, it's a list of numbers: Well, yes. Python chooses the decimal representation by default. So? It could be hex or octal and still be a byte. My example was merely meant to be illustrative and not an example of real code. The byte object is simply not a str; so I don't understand where this frustration with them not being str is coming from. If you use the unicode objects in Python 3 you get the same API as before…

You are not making useful comment because you don't understanding the use case. Python 2 is very useful in handling binary data. This complain is not about unicode. This is about binary files manipulation.

I'm thrill about the unicode support. If they only add unicode string and leave the binary string alone and just require an additional literal prefix b, it will be an easy transition. Instead the design is changed for no good reason and the code are broken too.

Re: About Python 3

#356

Post by agentultra »

tungwaiyip wrote: post #355
agentultra wrote: post #354

Earlier quoted context omitted.

> No, it's a list of numbers: Well, yes. Python chooses the decimal representation by default. So? It could be hex or octal and still be a byte. My example was merely meant to be illustrative and not an example of real code. The byte object is simply not a str; so I don't understand where this frustration with them not being str is coming from. If you use the unicode objects in Python 3 you get the same API as before…

You are not making useful comment because you don't understanding the use case. Python 2 is very useful in handling binary data. This complain is not about unicode. This is about binary files manipulation. I'm thrill about the unicode support. If they only add unicode string and leave the binary string alone and just require an additional literal prefix b, it will be an easy transition. Instead the design is changed…

I have a hard time believing that the design was arbitrarily changed.

The request to add string-APIs to the bytes object have been brought up before [0]. I think the reasoning is quite clear: byte-strings are not textual objects. If you are sending textual-data to a byte-string API, build your string as a string and encode it to bytes.

[0] http://bugs.python.org/issue3982

For working with binary data there's a much cleaner API in Python 3 that is less prone to subtle encoding errors.

edit: I realize there is contention but I'm of the mind that .format probably isn't the right method and that if there were one it'd need it's own format control string syntax.

Re: About Python 3

#357

Post by maxerickson »

dded wrote: post #338
agentultra wrote: post #321

Earlier quoted context omitted.

The converse problem is having to write iterator versions of map, filter, and other eagerly-evaluated builtins. You can't just write: >>> t = iter(map(lambda x: x * x, xs)) Because the map() call is eagerly evaluated. It's much easier to exhaust an iterator in the list constructor and leads to a consistent iteration API throughout the language. If that makes your life hard then I feel sorry for you, son. I've got 99…

> >>> list(b'abc') > [97, 98, 99] >That's not a list of numbers... that's a list of bytes! No, it's a list of numbers: >>> type(list(b'abc')[0]) I think the GP mis-typed his last example. First, he showed that ''.join('abc') takes a string, busts it up, then concatenates it back to a string. Then, with ''.join(b'abc'), he appears to want to bust up a byte string and concatenate it back to a text string. But I suspect…

join will work fine on a list of bytes, and the bytes object is available for converting a list of ints:

  >>> b'a'.join([b'b',b'e'])
  b'bae'
  >>> bytes([119, 104, 101, 101, 33])
  b'whee!'
  >>>

Re: About Python 3

#358

Post by dangayle »

tripzilch wrote: post #352
dangayle wrote: post #219

Earlier quoted context omitted.

It's not like you still couldn't plug in an old CD drive into your Mac. It will still work just fine. You can't plug in an old Python 2.x plugin into Python 3.x.

Why not. Are you familiar with SciPy's `weave` module? It's basically a plugin for plugging C++ code into your Python. In a variety of extremely cool compile-on-the-fly ways. It's really quite sweet :) No reason you can't do that with Python 2.7. Should be easier in fact because the interface will be much thinner. I am NOT saying this is a good idea however! Haha

That's interesting. I'll look it up.
Post reply on HN