7 ms·

Wow that is horrible.

by nilved 10y ago

deleted 10y ago
[deleted]
allendoerfer 10y ago
I really hate the fact that there are now 3 ways to do it. And that it looks like PHP. To be honest, to me the "%" seems the most pythonic way to do it. Format does not seem easier to understand to me . String formatting just cannot be transformed to natural language. I at least don't think "I need to format this string", I think "this variable needs to be in there", in the in there might as well be called "%". I think ["a is %s" % a for a in all_as] just fits. Although named parameters are nicer with format. In no way should there be a third way to do it. Isn't that the basic principle of Python, to care about things like this? I mean this whole Python 3 problem was to a small extend caused by people rather having an incompatible syntax than two ways to print a string. Going through these troubles and then inflating the language with new syntax for the same thing seems like a waste.
- kbenson 10y ago
  In that respect, don't list comprehensions fall under the same category of multiple ways to do something? They didn't exist in the language until 2.0[1], and it's just a convenient way to encode a couple for loops, is it not[2]? At some point you have to accept that it's a trade-off, and the more complex the topic, the less well served it will be by only one or two ways to do it. In this case, there were actually already three ways to do it, since you could always use plain string concatenation with `+`. If python were truly about one way to do it more than anything else, that would be the only way to build complex strings from variables, but since convenience is also important, numerous shortcuts were deemed acceptable and implemented. 1: https://en.wikipedia.org/wiki/History_of_Python#Version_2.0 https://en.wikipedia.org/wiki/History_of_Python#Version_2.0 2: And for my money, significantly more confusing (and less powerful) than something like Perl's `map`.
  - allendoerfer 10y ago
    List comprehension is the one obvious way to do do a quick map, a for loop would be used for more complex stuff and side effects. A real map is more niche but probably necessary when doing eval stuff or stylisticly nicer in a module where you do several functional tasks. String concatenation has one use-case where it is the obvious way, too, namely when you have to concatenate already existing strings without modification, since "%s%s" % (a, b) is just stupid, beyond that you would use string formatting. Maybe there are unique obvious use-cases for the different formatting options as well, but I don't know them. I give you, that "%" is bad for named arguments, but why wouldn't you just improve that then? I think they do the exact same thing and are good for the exact same contexts. If somebody knows more than me, I would be very happy to be proven wrong.
    - kbenson 10y ago
      > I give you, that "%" is bad for named arguments, but why wouldn't you just improve that then? Perhaps they should. I'm not making a case specifically for the proposed strategy (interpolation), just that if they are going to implement it, that it took this long is odd, and somewhat laughable. Personally, I think the named string format is superior to this new feature in many respects except the most simplistic of cases, but I don't often write python, so my opinion may be colored by that.
  - icebraining 10y ago
    Python also has map(), but the lack of lightweight block syntax (like Perl's and Ruby's) makes it more cumbersome to use. I don't see how list comprehensions are less powerful, though.
    - kbenson 10y ago
      > Python also has map(), but the lack of lightweight block syntax (like Perl's and Ruby's) makes it more cumbersome to use. Yes. Additionally, I prefer the clear directionality of control and transform denoted by the dual capabilities of `map` and `grep` over list comprehensions, especially when chaining. Even better, IMO, is Perl 6's ability to use the feed operator to go left-to-right, so if the map block can be read the same direction as the flow of list items.[1] Having to scan back and forth to determine what is happening is a real detriment to the readability of these types of expressions, IMO. > I don't see how list comprehensions are less powerful, though. You're correct. Not strictly less powerful, just that the single expression for transforming the item may require multiple comprehensions where a single slightly more complex map block could get away with a temporary variable. Given that I dislike the way multiple list comprehensions read, this may be a bigger deal for me than most. 1: E.g. my @new = ( @original ==> grep { ... } ==> map { ... } ==> sort { ... } );

Wow that is horrible.

by nilved 10y ago

Wow that is horrible.

deleted 10y ago

[deleted]

allendoerfer 10y ago

I really hate the fact that there are now 3 ways to do it. And that it looks like PHP. To be honest, to me the "%" seems the most pythonic way to do it. Format does not seem easier to understand to me . String formatting just cannot be transformed to natural language. I at least don't think "I need to format this string", I think "this variable needs to be in there", in the in there might as well be called "%". I think ["a is %s" % a for a in all_as] just fits. Although named parameters are nicer with format. In no way should there be a third way to do it. Isn't that the basic principle of Python, to care about things like this? I mean this whole Python 3 problem was to a small extend caused by people rather having an incompatible syntax than two ways to print a string. Going through these troubles and then inflating the language with new syntax for the same thing seems like a waste.

kbenson 10y ago
In that respect, don't list comprehensions fall under the same category of multiple ways to do something? They didn't exist in the language until 2.0[1], and it's just a convenient way to encode a couple for loops, is it not[2]? At some point you have to accept that it's a trade-off, and the more complex the topic, the less well served it will be by only one or two ways to do it. In this case, there were actually already three ways to do it, since you could always use plain string concatenation with `+`. If python were truly about one way to do it more than anything else, that would be the only way to build complex strings from variables, but since convenience is also important, numerous shortcuts were deemed acceptable and implemented. 1: https://en.wikipedia.org/wiki/History_of_Python#Version_2.0 https://en.wikipedia.org/wiki/History_of_Python#Version_2.0 2: And for my money, significantly more confusing (and less powerful) than something like Perl's `map`.
- allendoerfer 10y ago
  List comprehension is the one obvious way to do do a quick map, a for loop would be used for more complex stuff and side effects. A real map is more niche but probably necessary when doing eval stuff or stylisticly nicer in a module where you do several functional tasks. String concatenation has one use-case where it is the obvious way, too, namely when you have to concatenate already existing strings without modification, since "%s%s" % (a, b) is just stupid, beyond that you would use string formatting. Maybe there are unique obvious use-cases for the different formatting options as well, but I don't know them. I give you, that "%" is bad for named arguments, but why wouldn't you just improve that then? I think they do the exact same thing and are good for the exact same contexts. If somebody knows more than me, I would be very happy to be proven wrong.
  - kbenson 10y ago
    > I give you, that "%" is bad for named arguments, but why wouldn't you just improve that then? Perhaps they should. I'm not making a case specifically for the proposed strategy (interpolation), just that if they are going to implement it, that it took this long is odd, and somewhat laughable. Personally, I think the named string format is superior to this new feature in many respects except the most simplistic of cases, but I don't often write python, so my opinion may be colored by that.
- icebraining 10y ago
  Python also has map(), but the lack of lightweight block syntax (like Perl's and Ruby's) makes it more cumbersome to use. I don't see how list comprehensions are less powerful, though.
  - kbenson 10y ago
    > Python also has map(), but the lack of lightweight block syntax (like Perl's and Ruby's) makes it more cumbersome to use. Yes. Additionally, I prefer the clear directionality of control and transform denoted by the dual capabilities of `map` and `grep` over list comprehensions, especially when chaining. Even better, IMO, is Perl 6's ability to use the feed operator to go left-to-right, so if the map block can be read the same direction as the flow of list items.[1] Having to scan back and forth to determine what is happening is a real detriment to the readability of these types of expressions, IMO. > I don't see how list comprehensions are less powerful, though. You're correct. Not strictly less powerful, just that the single expression for transforming the item may require multiple comprehensions where a single slightly more complex map block could get away with a temporary variable. Given that I dislike the way multiple list comprehensions read, this may be a bigger deal for me than most. 1: E.g. my @new = ( @original ==> grep { ... } ==> map { ... } ==> sort { ... } );