Hacker News Reader

Comment by bluecalm | Hacker News Reader

I think he made a right call blocking all of those. There are Pythonic ways to do all of those already and the mantra there should be one and preferably one way of doing things is important for the philosophy of the language.

With PEP 572 it wasn't like that. There wasn't a Pythonic way to do list comprehensions which used the same expensive to evaluate expression two times in it and it was I think the only glaring syntax weakness in comparison to languages which have a way to do that (like WHERE keyword in Haskell).

View on HN

Whats the pythonic way to do dependencies? pip? pipenv? virtualenv? pyproject? And how about Python 2 and 3?

</Sarcasm>

But seriously, I think there's no one way to do things anymore especially if it holds up productivity and effectiveness. Let the pattern matching begin.

pipenv for applications with module dependencies :)

You can in fact factor out expressions in list comprehensions, like:

    [foo(y, y) for x in xs for y in [f(x)]]

Is this Pythonic? Perhaps not, but mainly because multiline list comprehensions are frowned on in general. I think people tend to get too dogmatic about that.

What's the Pythonic way of pattern matching?

There is none in the language, and no proposal has gain much traction on python idea.

A dictionary of string: functions I guess? Don't think there is a decent one

That's parametrized jumping. Pattern matching is parsing a structure with variables and filling those variables from a single structured value.

Python does that with tuples:

    a, b = b, a

But it just stops there. To be fair, I don't know how much power it would gain by going further either. Never made that question.

That is more commonly known as destructuring. (in python and javascript at least, as well as a few others iirc)

Pattern matching is normally (in functional languages like Scala and Haskell anyway) defined as a way of taking a union type and handling each one safely. It's a sort of functional alternative to polymorphism.

That is, polymorphic code

    class Dog(Animal):
        def make_noise(self):
            return "bork bork"

    class Duck(Animal):
        def make_noise(self):
            return "quack"

would, with pattern matching be (in pseudo haskell I hope)

    make_noise :: Animal -> str
    make_noise Duck = "quack"
    make_noise Dog = "bork bork"

In other words, in an oop style you delegate to the object that it implements all methods. Whereas with pattern matching you can have a type delegate to each of the functions that can operate on it to handle it correctly. (This explanation is a disservice to functional styles, its a lot more elegant than what I describe if you do it correctly).

So basically Clojure protocols? As in, multimethods that dispatch on the type of their first argument?

Except that assuming Animal is a sum type (kind of like an enum), the computer will complain.

So a maybe type (equivalent to an Optional) is simply a sum over just and nothing (the two components). If you fall to handle nothing, the program won't compile.

Animal would work the same way. Add "Cow" as an animal, and your program won't compile until everything sanely handles Cow.

So more like a switch case over a set of options where the compiler prevents you from forgetting any.

Since there is no metrics for that, your entire post, much like a lot of any part of the language design process, is very opinionated.

It's why it's hard.

Reply on news.ycombinator.com