6 ms·

What is this monstrosity in the tutorial ? >>> document <= 'Hello!' # write in the DOM Since when the __le__ method has any side effects? So to sum it up:

• mjburgess 6y ago
  It's still python; you can overload operators and give them side-effects in any conforming implementation. It may not be "pythonic", but there's an established tradition of operator methods and there's no requirement that python code conform to any particular tradition.
  • linkdd 6y ago
    Sorry, what I meant was: Is it the Python you want in your browser? So, this is just another implementation with its tradeoffs, just like when using Jython to have Python (without its ecosystem) and the JVM. Here you have Python with another semantic to learn.
    • VectorLock 6y ago
      I see this happening in a lot of Python libraries. It's still Python - or *ython maybe we can call it. The idiom of cutesy operator overloaded spread in from other languages; I'm personally not a fan.
  • stoksc 6y ago
    Yeah, overloading to build a little dsl over some objects sort of is something I’ve seen a lot. See airflow: https://stackoverflow.com/questions/52389105/how-operator-defines-task-dependencies-in-airflow https://stackoverflow.com/questions/52389105/how-operator-de... When it’s used that way, you’ve lost that the operation is semantically analogous to __le__. I think the assumption it has no side effects goes, too. Edit: not saying I like it, though.
    • duckerude 6y ago
      Overloading comparison operators like this is a particularly bad idea in Python, because of the "smart" behavior they have baked in. Overloading >> is comparatively safe. Unless you implement __ge__, `'Hello!' >= document` will also call __le__, which may or may not be what you want. And `'Hello!' >= document <= 10` is equivalent to `'Hello!' >= document and document <= 10`, which can lead to confusing surprises. (Brython does implement all of those pitfalls faithfully)
• red_hare 6y ago
  I will never understand python API developers obsession with overloading the operator magic methods. Apache Beam is one of the worst offenders to me. The recommended method is to connect your functional transforms when building your pipeline as if it were a series Bash commands piped together (overloading bitwise OR). Who thought “oh, you know what language and API is synonymous with ‘write a large complicated amount of business logic in me’, Bash.”
  • pyuser583 6y ago
    Your comment made me smile because Apache Beam is one of my favorite tools, but it seems nobody outside Spotify has had heard of it. The bitwise operation dunder methods have no definition outside of integers. So they’re basically freebies to do what you want with. Honestly I think the Apache Beam API makes a lot of sense.
    • pushingice 6y ago
      This is because it started out as a Google project. There is an internal time-series framework there called Monarch that does the same thing for composing operations.
    • heavyset_go 6y ago
      I have to agree with this sentiment.
    • red_hare 6y ago
      To be clear, I love Beam. It runs all of my startups stream and batch processing. I just think the Java API's version... pipeline = pipeline .apply("FirstTransform, MyFirstParDo()) .apply("SecondTransform, MySecondParDo()) is much clearer than the Python version... pipeline = ( pipeline | "FirstTransform" >> MyFirstParDo() | "SecondTransform" >> MySecondParDo() )
      • pyuser583 6y ago
        Agreed. I prefer the Java version, for a number of reasons. Scio is even better. But the bitwise operations make sense python wise.
• wenc 6y ago
  Looks like the FAQ covers this question: https://brython.info/static_doc/en/faq.html https://brython.info/static_doc/en/faq.html Quote: Q: why use the operator <= to build the tree of DOM elements? This is not pythonic! A: Python has no built-in structure to manipulate trees, ie to add "child" or "sibling" nodes to a tree node. For these operations, functions can be used; the syntax proposed by Brython is to use operators: this is easier to type (no parenthesis) and more readable To add a sibling node, the operator + is used. To add a child, the operator <= was chosen for these reasons: * it has the shape of a left arrow; note that Python function annotations use a new operator -> that was chosen for its arrow shape * it looks like an augmented assignment because of the equal sign * it can't be confused with "lesser or equal" because a line with document <= elt would be a no-op if it was "lesser or equal", which is always used in a condition or as the return value of a function * we are so used to interpret the 2 signs < and = as "lesser or equal" that we forget that they are a convention for programming languages, to replace the real sign ≤ * in Python, <= is used as an operator for sets with a different meaning than "lesser or equal" * the sign < is often used in computer science to mean something else than "lesser than": in Python and many other languages, << means left shift; in HTML tags are enclosed with < and > * Python uses the same operator % for very different operations: modulo and string formatting
  • corytheboyd 6y ago
    Not at all a Python user, but I don’t get how this is a valid argument at all: > Python has no built-in structure to manipulate trees What’s wrong with an API like appendChild etc? I know you’re just quoting the FAQ but if anyone has an answer I am legitimately curious. I have worked with Ruby for many years and loath cute DSLs but I always thought it was just the Ruby community that went overboard on that shit haha
    • dragonwriter 6y ago
      > What’s wrong with an API like appendChild etc? Verbosity vs. fluency, given the application domain, I expect is the concern. I'd rather have fluent DSL separate from the basic language runtime, though, so that adopting it is a separate decision from using the runtime.
• LockAndLol 6y ago
  Oof... yeah, that's terrible and not intuitive at all. appendChild or innerHTML = ... should be enough. That override is pretty unnecessary.
• nickthemagicman 6y ago
  I think it looks great!