7 ms·

This is one of those areas where I find Python a little contradictory. About 50% of the time it's "explicit is better than implicit" and "there should be one an

• andrepd 8y ago
  I don't really think so. It's expanding a "language-level" iterable (list, etc) into a "syntactic-level" comma-separated list of those values. does the same but turns dictionaries into syntactic `name=value, ...` constructs. It's a great little feature with loads of handy uses!
• cuchoi 8y ago
  From the Zen of Python: > (...) Although practicality beats purity. https://www.python.org/dev/peps/pep-0020/ https://www.python.org/dev/peps/pep-0020/
  • jakevn 8y ago
    Essentially, then, expressiveness (language complexity for the sake of flexibility), beats ease of learning or "one right way to do things".
• anothergoogler 8y ago
  It wouldn't be HN if the top comment weren't critical of asterisks in Python.
• pavlov 8y ago
  This is one of the things that gets me about Python. It makes this big noise about being a super-friendly form of executable pseudocode, but then you open any code example and the first thing you see is two asterisks and the mysterious word "kwargs" (a Swedish dessert perhaps?). I wouldn't mind except for all the haughty pretense about Python being a language that doesn't do this sort of thing. Dear Python, get a grip, you're just another ASCII-abusing interpreted monstrosity like Perl, you just decided to make programmer life suck with whitespace instead.
  • deleted 8y ago
    [deleted]
  • thx4allthestuff 8y ago
    Key word arguments. And I would consider the pythonic approach to be more pragmatic than anything. The language isn't haughty, it just does what it's told. That being said, you've provided a perfect example of what haughty looks like.
    • weberc2 8y ago
      In the parent’s defense, people write a lot more cryptic Python than they do other languages. There are no metaclasses in Go nor abused operator overloads or half-baked DSLs. People don’t use dictionaries as structs to hang off whatever they like. It’s kind of a penny wise and pound foolish approach. Arguably it’s not python’s fault, but that’s a poor consolation for folks who have to deal with these messes.
      • olavk 8y ago
        Is that really true? Sure you can write cryptic code using operator overloads, but the convention is to only use them in cases where they improve readability. For example numpy code would be a lot less maintainable without operator overloading IMHO. I haven't written numerical code in Go but I am skeptical it will be as maintainable without operators. The lack of a particular feature does not in itself make code more maintainable. I can't speak to metaclasses, since I have never had to maintain code using them. In my experience they are pretty rare.
        • weberc2 8y ago
          It's been true in my experience. Operator overloads are marginally beneficial and for some reason they're prone to be abused. Put differently, `Add(x, y)` isn't any less maintainable than `x + y`, but the former is pretty much never abused, while the latter is a popular abuse target. I've been writing Python and Go extensively for the last 10 and 5 years respectively. I really recommend giving Go a shot; you can pick it up in an afternoon and it really complements Python well since it excels at a lot of Python's weaknesses (parallelism, performance, static typing, static compilation, dependency managmenet, etc). For example, if I have to write a CLI tool, I almost always use Go since it's so much easier for coworkers to install a single binary than a Python program + dependencies + make sure you have the right version of the interpreter installed.
• jacobolus 8y ago
  Which part do you think is inexplicit? What do you think is the equally clear different way of doing it? How much Python experience do you have? I find that in places where it is applicable, this syntax is clear, unambiguous, easy to read, overall much nicer than alternatives.
• Alex3917 8y ago
  > This is one of those areas where I find Python a little contradictory. It's not contradictory. You should never use args and kwargs unless you need them. Usually they're only needed in relatively rare situations, like A) when you're building a dictionary dynamically without knowing what the key names will be in advance B) when building a library where you want to allow people to subclass a parent class, but also reserve the right to change method signatures in the parent class without breaking the user code. If developers are just using args and kwargs when calling one normal function from another then you should absolutely should not merge their pull requests until this gets removed.
  • bunderbunder 8y ago
    They absolutely do solve a problem. But I can't help but wonder if it would have been possible to find a way to let people solve that problem in a more explicit manner. The specific solution the Python team chose smells to me like one that was optimized for the convenience of the language's implementors more so than its users.
• jacobush 8y ago
  I feel you, however I also love https://github.com/Knio/dominate https://github.com/Knio/dominate - a Python library to generate HTML. Generating HTML always felt awkward for me in many languages. From PHP where you sprinkle PHP between HTML or HTML between PHP, to frameworks in various languages where you populate variables and HTML is magically generated. Somewhere in between there are template languages. "Dominate" uses Python itself as the template language - this means there never is that "disconnect" where you have to validate your output, neither is it that disconnect coming from generators, nor do you have to learn and use a separate template language. Dominate can look like this: return hr(), p( a( 'Start', href = '/start' ), style = 'text-align: center;' ) If the Python is valid, so is the HTML. For me it hit a sweet spot. Dominate uses kwargs. I discovered this and (a?)bused kwargs when I wanted to add some tags of my own.
  • sevensor 8y ago
    Oooh, that's nice. Thanks for sharing this. I like how it merges your mental model for HTML with Python in what feels like a very unsurprising way.
    • jacobush 8y ago
      Exactly. And regarding the kwargs I had this feeling first of oh no "what is this!?" I have been programming Python since 2000 and I never used kwargs before. I knew they were there somewhere but I never bothered with them. I was at first a bit annoyed, but I really wanted to add my own tags and discovered it was actually quite nice if I could intercept arguments in my own tags. You don't have to use kwargs to add your own tags, but you can make the tags more powerful and composable that way. But kwargs are really only worth it to me if there is a strong component of, "write once, use many times" to it. You don't have to use kwargs to add your own tags to Dominate, you can just return tuples of building stone tags if you want to.
• olavk 8y ago
  True, Python allows a lot of crazy hacks like monkeypatching, dynamically creating classes and so on. It is there if you need it. It is not like in Java where those things are simply impossible. The Python culture on the other hand discourages obscure hacks and unreadable cleverness, and the language is generally designed to encourage the straightforward and readable solution. I don't really see a contradiction in that. You cannot prevent people from doing stupid things anyway. What you can do is encourage good style, and making the "right way" the path of least resistance. You can write readable code in any language, even Perl, if you use enough effort and discipline, but Python tries to make readable code the easy default. The "quote" you made up is not representative of the Python culture or the article here, although I'm sure you can find some blogger somewhere with that attitude. They seem to have mostly migrated to other more hip languages though.
  • aptwebapps 8y ago
    GP's quotes are paraphrased from PEP 20 and I think _are_ put of Python culture, at least as I've experienced it. https://www.python.org/dev/peps/pep-0020/ https://www.python.org/dev/peps/pep-0020/
    • zazen 8y ago
      I'm afraid you've misunderstood olavk's point. 'The "quote" you made up' certainly refers to > "here's this cool feature for doing something you could do a different way that looks like hieroglyphics and nobody understands but you should totally use it because it's awesome!" not to > "explicit is better than implicit" and "there should be one and only one good way"
      • aptwebapps 8y ago
        Doh, I think you're right!
      • olavk 8y ago
        Yeah that is what I meant, sorry for being unclear.
  • 8y ago
• zimablue 8y ago
  How would you approach decorating /any/ function without args, kwargs or something very similar? def decorator(f): def new_f(*args, **kwargs): do_something() return f(*args, **kwargs) return new_f
• baruchel 8y ago
  You are right, but sometimes, I don't see how you can easily achieve the same task without using the asterisk. For instance, if you want to plot a list of (x,y) coordinates which is likely to happen quite often, you can do : plot(*zip(*L)) What do you usually do? (Probably creating two intermediary lists with a loop?)
• BerislavLopac 8y ago
  The Zen of Python clearly states: There should be one-- and preferably only one --obvious way to do it. I think that "obvious" is the key word here -- it says nothing about the non-obvious ways, nor about which ones are better. The problem here is not with Python itself, but with people looking for a silver bullet which will solve all their problems. In Python, this is presently very obvious with async programming, and people insisting on using it for everything; however, async is useful for only a certain subset of problems one might encounter (and in a few cases it's incredibly useful) while in most situations it adds avoidable complexity. However, this approach is definitely not limited to Python, and every language has its own examples (classes vs prototypes in Javascript is one example). My advice is: use what you're comfortable with; don't be afraid of learning new techniques, but don't feel obligated to use them at all costs; ignore the Kool Kidz™ pushing fads.