3 ms·

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(lamb

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 problems but a list constructor ain't one. The Python 3 bytes object is not intended to be the same as the Python 2 str object. They're completely separate concepts. Any comparison is moot. Think of the bytes object as a dynamic char[] and you'll be less inclined to confusion and anger: >>> list(b'abc') [97, 98, 99] That's not a list of numbers... that's a list of bytes! >>> "".join(map(lambda byte: chr(byte), b'abc')) 'abc' And you get a string!

itsadok 13y ago
> The converse problem is having to write iterator versions of map, filter, and other eagerly-evaluated builtins Well, in Python 2 you just use imap instead of map. That way you have both options, and you can be explicit rather than implicit. > That's not a list of numbers... that's a list of bytes! The point being made here is not that some things are not possible in Python 3, but rather than things that are natural in Python 2 are ugly in 3. I believe you're proving the point here. The idea that b'a'[0] == 97 in such a fundamental way that I might get one when I expected the other may be fine in C, but I hold Python to a higher standard.
dded 13y ago
> >>> 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]) <class 'int'> 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 he meant to type this: >>> b''.join(b'abc') That is, bust up a byte string and concatenate back to what you start with: a byte string. But that doesn't work, when you bust up a byte string you get a list of ints; and you cannot concatenate them back to a byte string (at least not elegantly).
- agentultra 13y ago
  > 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.
  - tungwaiyip 13y ago
    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.
    - agentultra 13y ago
      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 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.
- 13y ago
tungwaiyip 13y ago
What you are looking for is imap(). In Python 2 there are entire collection of iterator variants. You can choose to use either the list or the iterator variants. The problem with Python 3 is the list version is removed. You are forced to use iterator all the time. Things become inconvenient and ugly as a result. Bugs are regularly introduced because I forget to apply list(). >>> "".join(map(lambda byte: chr(byte), b'abc')) Compares to ''.join('abc'), this is what I call fuck'd. Luckily maxerickson suggested a better method.

itsadok 13y ago

> The converse problem is having to write iterator versions of map, filter, and other eagerly-evaluated builtins Well, in Python 2 you just use imap instead of map. That way you have both options, and you can be explicit rather than implicit. > That's not a list of numbers... that's a list of bytes! The point being made here is not that some things are not possible in Python 3, but rather than things that are natural in Python 2 are ugly in 3. I believe you're proving the point here. The idea that b'a'[0] == 97 in such a fundamental way that I might get one when I expected the other may be fine in C, but I hold Python to a higher standard.

dded 13y ago

> >>> 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]) <class 'int'> 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 he meant to type this: >>> b''.join(b'abc') That is, bust up a byte string and concatenate back to what you start with: a byte string. But that doesn't work, when you bust up a byte string you get a list of ints; and you cannot concatenate them back to a byte string (at least not elegantly).

agentultra 13y ago
> 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.
- tungwaiyip 13y ago
  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.
  - agentultra 13y ago
    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 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.
13y ago

tungwaiyip 13y ago

What you are looking for is imap(). In Python 2 there are entire collection of iterator variants. You can choose to use either the list or the iterator variants. The problem with Python 3 is the list version is removed. You are forced to use iterator all the time. Things become inconvenient and ugly as a result. Bugs are regularly introduced because I forget to apply list(). >>> "".join(map(lambda byte: chr(byte), b'abc')) Compares to ''.join('abc'), this is what I call fuck'd. Luckily maxerickson suggested a better method.