5 ms·

Having just spend the last few weeks writing Python, this comment will come off as bitter, but - really? Out of all the shitty syntax things, this sort of thing

• isoprophlex 8y ago
  Can you elaborate what other syntax decisions you find shitty? In general I find the syntax of python to be very clean and easy to understand
• vanderZwan 8y ago
  It would be more constructive if you added explanations of what other (in your opinion) "shitty syntax" things you prefer to see addressed and why. EDIT: also, I'm mentioning "in your opinion" because adding that to your own statements indicates that you're open to discussion. It's also good to use it as a reminder to yourself (speaking as a former physics student, and most people who know physics students will agree how "absolute" and unintentionally arrogant they tend to be in their claims until they learn otherwise). I'm sure your coding experience was frustrating, and I'm sorry to hear that, and I understand that we all need to vent sometimes, but trying to staying open to other viewpoints is better for your own sanity, wisdom, and social connections in the long run.
  • mehrdadn 8y ago
    Not the OP, but the inability to write sorted(enumerate([('a', 1), ('b', 2)]), key=lambda (i, (k, v)): (k, i, v)) in Python 3 drives me nuts. They could fix this. It worked in Python 2.
    • fredley 8y ago
      I love writing python, but the lack of decent map/reduce/etc. (that are really good in Javascript - the other language I mainly write) hurts. Stuff like your example really feels burdensome and inelegant in comparison.
      • pxndx 8y ago
        Python list comprehensions _are_ map/reduce.
        • mehrdadn 8y ago
          I think you mean map/filter.
          • pxndx 8y ago
            Yes, thanks for correcting me.
        • yxhuvud 8y ago
          Sure, but they compose really bad.
          • vanderZwan 8y ago
            Why? Just assign to a variable, then do another list comprehension on the next line, no?
            • yxhuvud 8y ago
              And that is a pretty sad state of affairs compared to ways that do compose well, like the one in Ruby which you can easily chain.
    • icebraining 8y ago
      Yeah, PEP 3113 was quite weak. It didn't even explore alternatives (like fixing the introspection without breaking the syntax).
    • msluyter 8y ago
      Seems that the goal here is to sort via the letters 'a', 'b', etc combined with capturing the original ordering? You could do this, although it's admittedly uglier than your example: In [1]: sorted(enumerate([('b', 1), ('c', 3), ('a', 2)]), key=lambda x: (x[1][0], x[0], x[1][1])) Out[1]: [(2, ('a', 2)), (0, ('b', 1)), (1, ('c', 3))] However, if you're flexible about the ordering of the resulting tuples, this seems clearer and reasonably painless: In [1]: sorted((x, i) for i, x in enumerate([('b', 1), ('c', 3), ('a', 2)])) Out[1]: [(('a', 2), 2), (('b', 1), 0), (('c', 3), 1)] I know that doesn't address your underlying complaint. This is mainly to note that the flexibility of Python tends allow a variety of approaches and that sometimes finding the clearest one takes some effort. ("There should be one obvious way to do it..." often does not hold, IMHO.)
      • zb 8y ago
        > this seems clearer and reasonably painless but gives the wrong answer, as you'll see if you try to sort [('a', 2), ('a', 1)]
        • msluyter 8y ago
          Sure; it wasn't clear to me whether the letter fields could be repeated.
          • mehrdadn 8y ago
            Why would I have included the indices for sorting if the letters were guaranteed to be distinct...
• hyperbovine 8y ago
  Like what? Python generally has pretty good syntax.
• icebraining 8y ago
  You're right, it does come off as bitter, but worse, it's not a good conversation starter. People who like Python and forced occasional Python developers tend to have different ideas about what is a "shitty syntax thing" and what is a core feature of the language. Is there a better example of something that is generally agreed to be "shitty" yet could be fixed in a clean way, without breaking backwards compatibility?
• tomtimtall 8y ago
  Just curious, which pep would you prefer they do first? Or do you have a grudge with something not addressed in existing peps?
  • roel_v 8y ago
    Oh but I can find grudges in anything :) (as to your first point, if you'll allow me to be even more snarky and cynical as I already have been in this thread (might as well go all out now), the fictional 'pep' I would like to see most is 'method and apparatus to instill some realism and humility in the average Python advocate's conception and description of the language'. But here too I will freely admit that I'm probably susceptible to significant observation bias and/or bad luck, and that others could have radically different experiences from myself.)
• heavenlyblue 8y ago
  This comment will also come off as bitter - but why don't you just go and write your code in whatever you have been writing it in before? Just leave it to those who have used Python for a while now and actually know what it's missing.
• roel_v 8y ago
  OK you're all right, I should've included some examples, here's just some from the last few days (I guess some of these are arguably not purely 'syntax', but to me they mostly come down to that, and I guess most can be explained away with 'different philosophy', and I'm sure someone will come out and say 'oh but if 'only' you had just done this and this', but still...) : - Instantiating an object from a name in a string. Like instantiate a 'Foo' when you have a string variable that contains 'Foo'. I can't remember the syntax even though I looked it up two days ago, and I never will because it's such a shit show. Not to use PHP here as and example of a great language, but there at least the intuitive '$obj = new $var' works as you expect it. Or, in C++ you have to do it manually, which is also fine - at least be consistent. - The weird sort-of typing of variables. Variables have types, but you can assign a different value of a different type to them, and the actual types usually doesn't matter except when it does. So you do print "Hey " + var but now you need to know what type var is because you might need to str() it. - The whitespace-is-important-except-when-it-isn't. OK so braces are the devil's work, but when it's inconvenient, we're not that strict on white space (when initializing lists, when having expressions that span several lines, ...) so now everything can still look out of whack. - .iteritems(). Really? - super(ClassName, self).__init__(argument). Wut? Yes when I parse it token by token I understand, but why? Maybe the other magic methods are in this category too, but probably to a lesser degree. - (I had some other things here about primitive OO capabilities, shitty package system/versioning, and some more, but those were all so far away from 'syntactic sugar' that they didn't fit this list no matter how hard I twisted the argument) Look, I do understand why they are this way. For each of them, there is a reason that any reasonable person would say 'yeah that makes sense' to, possibly after some explanation of the history or context or whatever. But then at least be honest and stop promoting the language as so 'intuitive' or 'beginner-friendly' or 'much more clean than other languages'. Sure, it's not as bad as R, but it's still just like any other 20+ year old language in wide spread use - crufty, idiosyncratic in many respects, and in general requiring a bunch of frustrating head butting before you can be productive in it. And to tie it to the OP - it seems this new syntax is promoted as being for 'beginners' or to make it 'easier to teach'. Well good luck with that, I say.
  • eesmith 8y ago
    "Instantiating an object from a name in a string. Like instantiate a 'Foo' when you have a string variable that contains 'Foo'. I can't remember the syntax even though I looked it up two days ago, .." Python doesn't have specific syntax for that. It can be as simple as: obj = globals()["Foo"]() That assumes "Foo" is in your global namespace. If you don't care about security then you can do: >>> import math >>> s = "math.cos" >>> eval(s)(3) -0.98999249660044542 If you care about security then you might not want to allow arbitrary objects, like "os.unlink" to be referenced. There are third-party packages which provide different models of how to get objects, like Django's "import_string" at https://docs.djangoproject.com/en/2.0/ref/utils/#django.utils.module_loading.import_string https://docs.djangoproject.com/en/2.0/ref/utils/#django.util... . "The weird sort-of typing of variables. Variables have types," Variables have only one type, "reference to Python Object". An expression like 'var = "Hey " + var' may change the type of the value that var references, just like how 'var = var * 234.567' may change the type of the value that var references from an integer/long to a float, or "var = var * "Hey"', if var == 2, causes var to be a reference to the string "HeyHey". ".iteritems(). Really" This was for a transition phase. It no longer exists in Python 3, where items() returns an iterator instead of a list. "super(ClassName, self).__init__(argument). Wut?" In Python 3 this is: "super().__init__(argument)", as in: >>> class A: ... def __init__(self, s): ... print("A says", s) ... >>> class B(A): ... def __init__(self, t): ... super().__init__(t*2) ... >>> B("hello?") A says hello?hello? <__main__.B object at 0x10b201630> "but it's still just like any other 20+ year old language in wide spread use - crufty, idiosyncratic in many respects" A reason for the oft-bemoaned backwards-incompatible changes to Python 3 was to remove some of the crufty, idiosyncratic language features that you rightly pointed out. You are still using Python 2.7, so cannot take advantage of those changes.