Hacker News Reader

Comment by amelius | Hacker News Reader

If they add anything to Python, it should be the ability to do functional-style programming without hassle. Right now it's almost impossible to compose functions in an inline style such as used in functional programming languages. Yes, there's lambda, but it doesn't extend into multiple lines, and applying a function to a bunch of lambdas directly leads to line-width overflow. Even JavaScript has better support for functional-style programming. Perhaps Guido should spend a year writing Haskell :)

View on HN

Haskell has always officially inspired Python tooling. But Python does things in it's own way, and they are not random, they are the result of an opinion.

First class citizen functions, short lambdas, comprehension lists, generators, map(), filter(), itertools, operator and functools are quite a rich toolbox already. But you won't have more. It's a choice.

The idea is to have enough to be productive, and not enough to be dogmatic. The experience of Guido, and it's one that I share, is that too much functional tooling drives a style that favors expressive writing at the expense of ease of reading.

It's not by chance that LISP and Haskell are considered hard languages to get into, while Python is considered easy to start with.

It has a cost, since no language is perfect, but that's the path this language follows and requesting a snake to fly will only bring you disappointments.

Python tries to strike the balance between the importance of a rich expressiveness and the non negotiable necessity of keeping the code readable: you read a line much more often that you write it, after all. It's a key philosophy of the language. It shaped and will shape numerous decisions around it.

This PEP is a perfect example : it tooks years for the concept to be integrated in Python, and the last debate about this concrete implementation took months. The result is a carefully crafted feature with a lot of details to discourage abuse and remove the needs for pondering when to use it or not.

you are right that python is an opinionated choice, but that particularly chosen philosophy is what people disagree with. the philosophy is somewhat stubborn as well.

and i think you are leaving out functional languages which share python's readability, if not surpass it, while remaining much more expressive. that's f# and ocaml.

f#, in my opinion, is superior in everyway to python and subsumes python's abilities of readability, easiness, oop, and scripting, while greatly raising the ceiling of possibility. it's criminally underused, especially in areas where python has been chosen.

and i disagree lisp is harder to get into. racket is just as easy to learn as python, if not easier, due to its regularity. the how to code / systematic program design course on edX and the book how to design programs showcases this.

I heard good things about F# and I did like C#, so I wanted to give an honest look at your arguments.

The first thing I checked is your very vocal assurance that F# is a better scripting language than Python. That seemed very weird to me, after all it's Python strong point. Since I script a lot, I looked for the most popular F# lib to parse script arguments.

Argu seems the winner, according to http://fsharpworks.com/survey.html. Their tutorial is pretty good (https://fsprojects.github.io/Argu/tutorial.html), and here is their hello world. 24 lines of, packing a dense symbology and using a lot of the specific language features:

    open Argu

    type CLIArguments =
        | Working_Directory of path:string
        | Listener of host:string * port:int
        | Data of base64:byte[]
        | Port of tcp_port:int
        | Log_Level of level:int
        | Detach
    with
        interface IArgParserTemplate with
            member s.Usage =
                match s with
                | Working_Directory _ -> "specify a working directory."
                | Listener _ -> "specify a listener (hostname : port)."
                | Data _ -> "binary data in base64 encoding."
                | Port _ -> "specify a primary port."
                | Log_Level _ -> "set the log level."
                | Detach _ -> "detach daemon from console."


    let parser = ArgumentParser.Create<CLIArguments>(programName = "gadget.exe")
    let results = parser.Parse [| "--detach" ; "--listener" ; "localhost" ; "8080" |]
    printfn "%A" results.GetAllResults();;

The same thing with click, the Python most popular solution, is 11 lines, and it's shaped around almost only regular calls and parameters:

    import click as cli, base64, urllib.parse as url

    @cli.command("gadget.exe")
    @cli.option('--working-directory', help='specify a working directory.', type=cli.File('rb'))
    @cli.option('--listener',  help="specify a listener (hostname : port)", type=url.urlparse)
    @cli.option('--data', help='binary data in base64 encoding.',  type=base64.b64decode)
    @cli.option('--port', help='"specify a working directory.',  type=cli.File('rb'))
    @cli.option('--log-level', help='set the log level.', type=int)
    @cli.option('--detach', is_flag=True,  help='detach daemon from console')
    def hello(**kwargs):
        print(kwargs)

    hello(["--detach", "--listener", "localhost:8080"])

I have a hard time finding the motivation to look for the truth behind your other arguments after that.

this is interesting, because if i didn't read your commentary, these examples seem to favor f#. :)

what are your objections? what is the dense symbology?

discriminated unions (what the CLIArguments is) are very simple to define and understand. the usage member nearly uses the simplest possible pattern matching available. pattern matching is a staple of functional languages. it's a case statement in its simplest use but is so much more in general.

these two things are the bread and butter of f#. they may take a modicum more initial effort than simple function calls, but it pays off in readability and expandability. it seems python takes the easy route. it makes things apparently simple at first but difficult in the long run.

i know both languages, to a degree, and find the python hard to read. it's also faking types, which is kind of funny. the f# code is fully typed.

lines of code is meaningless to me here because the f# has better delineation of concepts here.

and lastly, there's actually no reason why you couldn't write an f# library to behave like the python one here. that is not true the other way around. that's the power of f#'s multi-paradigm nature.

I'm not who you replied to but I have the same reaction. The F# version doesn't even include the actual arguments, and the capitalised and underscored versions are repeated twice. There should be no need for pattern matching or discriminated unions here. The Python version doesn't seem to be faking types, but specifying constructors.

> The F# version doesn't even include the actual arguments, and the capitalised and underscored versions are repeated twice.

i don’t know what you mean. actual argumennts? do you mean like “—working directory” or the values passed by them? i am actually not familiar with this library, but it seems the former is handled by the library from the discriminated union constructor names and the latter are right there in the constructors.

and what do you mena there’s no need? that seems rather arbitrary. it’s a way to represent your data explicitly with types, i.e., is type-driven development.

i can’t further defend this library because i have never used it, but i see no confusion here and don’t even understand the complaints. it seems to be “this is different than how i think in python, so it’s no good”.

The Python version ultimately appeals to stringly-typed maps. This is often pretty challenging to debug, especially in modern environments where things tend to be launched via container managers "at a distance" with container managers.

Also, click is weird because it wants to take over traditional function syntax and "under the covers" rewrite them. Compared to a much simpler Args -> Map kind of construction, this is a great example of how Python introduces unneeded complexity and prefers to create huge spelunking expeditions into its poorly-explained function invocation syntax & semantics. The PEP we're all commenting around is another great example of that approach. It's too bad Python's community is often more interested in novel uses of Python's semantics than actually readable, reusable concepts.

The irony is other "deep in their own waters" approaches produce stuff that's much more readable than click's without also being some kind of solve-the-universe's-problems black-box. Python dooms itself to that because of its refusal to embrace more composable primitives. They'll always end up with completing big-bang projects that don't play well together. Examples available upon request.

I agree with you. I'm actually a big fan of both Haskell and F#, and use Haskell especially for a lot of my hobby projects. However the idea that either of them make a better scripting language than Python seems laughable to me.

i didn’t say haskell. f# has explicit support for scripting in the form of its fsx file format. how is f# as a scripting language laughable? f# even has access to the powershell api through .net.

      Lbbbx bv        bbbbb v

De te. Es. ::: BBC radio

Huh. I normally complain about how functional languages seem to be designed to be easy to write the first time but super hard to read and modify. However, in this case, the F# code seems very clear, significantly moreso than the Python code.

> The experience of Guido, and it's one that I share, is that too much functional tooling drives a style that favors expressive writing at the expense of ease of reading.

This is absolutely dead on accurate. As a Clojure developer, using one of the most expressive -- dare I say, artistic -- programming languages ever created, I can say that I am totally in the zone writing code which is elegant and terse and really packs a punch, does clever things.... and then just a few days later, it is very hard for my own brain to parse my own code and figure out what it does.

For each line of code you write once, it will be read dozens of times by you or others. Code is for reading. Languages that get this right make things a lot easier for everyone.

What other languages do you think "made it right" ?

Map, filter and a lot of the itertools contents lose most of their possible power if you let easy lambdas and function composition out.

The only dogmatic position here is the Python one, that based on opinion alone, and is leaving a lot of good structures out for no gain at all.

>It's not by chance that LISP and Haskell

It's only because Python is familiar and Haskell is not. Objectively both Haskell and Lisp are dramatically more simple to comprehend than python.

Python has explicitly discouraged functional-style for a long time, I don't think that's going to change. And frankly, the whole language is quite, I'd even say extremely, mutable; I'm not sure a functional syntax works well with that.

The problem is, python list comprehensions are very... specific. Add to that the brokenness of if...else and you get a very quirky and specific sublanguage that is hard for outsiders to read. And this is before we take into account the locals/scope/clojure discussion in the link and the PEP (which I frankly did not bother to read.)

On the other hand, you have a concept which translates easily to any language with first-class functions and lambdas. Even the syntax stays the same among languages which use "f(x,y)" for function evaluation and parameter passing.

/* This post is for those occasions when a list comprehension style is advocated over a functional style, which I know was not necessarily what you were doing in your comment. But I think the two points are valid enough on their own. */

> Add to that the brokenness of if...else

Could you elaborate on that?

> > Add to that the brokenness of if...else

> Could you elaborate on that?

It's a very opinionated statement on my part. `if COND then TRUE-CASE else FALSE-CASE` is the correct form to use, in my opinion. Python uses `TRUE-CASE if COND else FALSE-CASE`.

Conventional if statements in Python do use your preferred form of `if COND then TRUE-CASE else FALSE-CASE`.

What you are talking about is a different kind of expression, similar to a ternary operator. It is not the same as if...else

The reason it's not the same as if...else is that it's freaking backwards :D

You said:

> Python uses `TRUE-CASE if COND else FALSE-CASE`.

And this is wrong -- this is not how Python if statements work.

> > Python uses `TRUE-CASE if COND else FALSE-CASE`.

> And this is wrong -- this is not how Python if statements work.

Huh? Didn't you yourself say I was not talking about if statements:

> What you are talking about is a different kind of expression, similar to a ternary operator. It is not the same as if...else

In any case, I'm talking about the case that goes `TRUE-CASE if COND else FALSE-CASE`, as can be deduced from my typing `TRUE-CASE if COND else FALSE-CASE`.

> Even JavaScript has better support for functional-style programming.

Which shouldn't be that surprising considering originally Netscape were going to port Scheme to their browser before choosing to create a new scripting language with "Java-like syntax" (you can argue amongst yourselves just how Java-like the syntax really is).

> originally Netscape were going to port Scheme to their browser

Imagine where we'd be if they'd just done that.

Probably no better off as I cannot see many frontend developers taking to Scheme like they had with Javascript. So we'd still have eventually ended up with something nasty just to appease the lowest common denominator. Here's a horrible thought: maybe VBScript would have become the de facto standard instead?

Yeah that's true, nobody uses Clojurescript or anything.

You have to bare in mind that we - on HN - are inside a niche bubble and thus the kind of developers that read HN are very different to the kind of developers in many of the web shops outside of the big tech hubs like Silicon Valley and London. There are a hell of a lot of frontend devs who do still like to keep Javascript at arms length and a lot of "web developers" who are basically just Wordpress themers. I know this for a fact because I've worked with a great many of them before moving closer to London. These people are obviously still competent at what they do since not ever website nor development job requires "superstars" and the web framework - for all it's faults - offers a low enough barrier to entry that anyone can throw a page together. Including even those who don't do dev for a living. In fact one of the reasons the web took off was because of how easy it was for anyone to throw together a homepage.

Had Scheme been Netscapes scripting language instead of Javascript then I could easily see many of the less dedicated developers and hobbyists getting frustrated at S-expressions and such like. I mean I love functional programming but even I cannot deny that the learning curve is steeper and S-expressions are less readable (at least to an untrained eye) than Javascript is.

So my point was if Javascript didn't exist then I suspect there would be enough demand to either dumbdown / bastardise Scheme, or implement another scripting language which was more hobbyist friendly (also hence the VBScript quip).

A scripting language isn't necessary if you just want to throw a page together. It's only really necessary for today's web-as-an-application-platform model. If the front-end language were Scheme we would simply see fewer (but in all likelihood, better) web apps.

That's a massive oversimplification and you know it.

+ Just because something isnt "necessary" it doesn't mean it doesn't add value. The problem is just sites that make JS a requirement rather than an optional feature enhancement.

+ Youre talking about stuff from a too recent perspective. Eg Before CSS came into its own, JS was the only reliable way to do mouse over effects (which can add a lot to usability even on regular web pages)

+ Just because JS is abused on current news sites, blogs and other sites that are really just static pages, it doesn't mean that Scheme wouldn't have been abused in the same way.

+ You also wouldn't see fewer developers writing frontend code. They would just use a transpiler (like we see with TypeScript et al) except instead of compiling from a stricter language (in TypeScripts case) it would transpile from a lazier language into a stricter one.

+ Or instead of the previous point (though more likely as well as) you'd still have a non-scheme language in the browser. Possibly even VBScript. Or maybe something derived from Perl. But I guess at least we wouldn't have a language monopoly on browser scripting languages.

Honestly though, I hate JavaScript just as much as you do. But let's not get carried away with our exaggerations :)

There would probably be a lot more people complaining about scheme!

Just need something like blocks in Smalltalk. Wikipedia page on list comprehensions says Smalltalk-80 had list comprehensions and that was ~ 40 years ago.

Smalltalk also uses ":=" for assignment and "=" for comparison. In Pharo, VA and Dolphin at least does what this Python proposal does - return the value of the last expression.

Well, if you prefer blocks, you may as well use Ruby as that language is basically what happens when you have access to blocks.

Python chose a different design trajectory - personally I can't stand it but it certainly follow some sort of internally consistent reason.

There's a whole lot of smalltalk in ruby.

Ain't going to happen. Python used to have lambdas, but removed all but the one-line variety.

The problem is that if you add blocks, then half of the added syntactic features the last decade is redundant as a block version would simply solve the problem a better. Which would create a lot of dead design, and that makes it a bad solution.

When did Python have multi-line lambdas?

Are you maybe conflating blocks with chained iterator operations? Adding blocks to Python's current functional syntax would be pretty ugly. "foo.filter(bar).map(baz)" is nice even if you can only use named functions.

Smalltalk (and for that matter Ruby) has weird feature that blocks and methods are different different concepts.

In my opinion the Python's explicit self argument is somehow cleaner approach than having distinct block and function/method types. You still need some kind of ugliness in order to implement super(), but for Python 3 that happens at compile time and the resulting syntax is reasonably sane.

As for the aforementioned method context issue CLOS/MOP takes interesting approach of macroexpanding the method definition into something like

  (lambda (args next-method)
    (labels
      ((call-next-method &args)
        ...
        (funcall next-method ...)))
      (impl (...)
        ... method body ...))
     (funcall impl args)))

Also of note is that in ST, there are no control structures, even if is implemented as method on Boolean instances which takes block argument, with true and false being instances of True resp. False with different implementations of #ifTrue: method.

There are plenty of very good functional programming languages. If you prefer Haskell to Python, just go ahead and use Haskell. Python has a very specific design philosophy which is a focus of readability and the "preferably only one obvious way of doing it".

It's not easy to "just" switch languages. You also have to consider the ecosystem built around them. For example, I love NumPy and SciPy.

> preferably only one obvious way of doing it

I don't think that is true at all. Python allows you to perform many tricks, with overloading operators etc.

You should probably look into the JVM or .net platforms, where the same libraries are available through multiple languages. For example .net have F# which is a very strong functional language, and the JVM have Scala and Clojure.

Pyhton is not really that kind of language.

How a language with nested list and dict comprehensions can ever claim to focus on readability is beyond me, or look at typing and the mess that leaves behind. One obvious way of doing things while simultaneously mixing oop and functions arbitrarily in their standard library even providing camelCase and snake_case aliases(!) for parts of it. And why does the base64/b64encode return bytes and hashlib/hexdigest str?

Python is designed in such a strangly arbitrarily inconsistent, hypocritical and opinionated manner.

> even providing camelCase and snake_case aliases(!)

Sorry, but it's preposterous to bring up an implementation detail of the standard library that has long been in the process of being fixed. CamelCase was deprecated a long time ago in favour of snake_case; what is left of CC is for backward-compatibility and will eventually disappear. This is all documented.

The standard library is not the language, it's much messier and suffers from all sorts of issues that have nothing to do with the language itself.

  from toolz import compose

I wonder what would break if they started treating if as an expression. It is much nicer to do:

    def foo(X):
        if bar(foo):
            1
            False

I don’t understand what you are trying to write.

First of all you have indented 1 and False equally. Is that a typo? Or is it your opinion that the if should always consist of the if and the else branch without using the else keyword?

Secondly, if you want to return a value you need to use the return statement.

Also you wrote bar(foo) but foo was the name of the function, not the name of your parameter.

Perhaps what you are looking for is this:

    def foo(x):
        return 1 if bar(x) else False

Perhaps s/he was looking at Lisp/Scheme:

  (define (foo x)
    (if (bar x)
      1
      #f))

The returned value is the value of the last expression. No need for an else, or a return keyword.

Yeah I considered that but it doesn’t make much sense to change Python to be like that.

It’s fine like that in Scheme and the other Lisps in part because well that’s the way they always did it, but it’s quite different from how it is and has been in Python.

If they want Lisp in Python they should look into Hy.

http://docs.hylang.org/en/stable/quickstart.html

https://github.com/hylang/hy

He/she was right, I was trying to write scheme python. I have spent quite some time writing python, but my sleep deprived brain wants to make everything into scheme :)

I don't know what you would lose by having if as an expression. It is easy to notice when it is used in expression context, and there is no extra computation that needs to be done.

It was sort of addressed with the trenary operator, but that quickly becomes ugly.

> I don't know what you would lose by having if as an expression

Well, if you turn if into an expression the way that you indicated then now you will also need the equivalent of the “begin” expression in order to be able to have multiple statements and/or expressions in either branch.

So then you are breaking backwards compatibility. Which makes it a non-starter from the get go.

And like I said there is also the fact that functions need the return keyword in Python if you want to return a value.

You could have the same looks as the regular if, but have it implicitly return a value. I was just too sleep deprived to be able to type out correct syntax on my phone.

Ruby returns the last thing in a method, which I feel is pretty sane.

Thhis was exactly what I was trying to write, but wasn't able to switch to python mode on my phone :)

I once wrote a (simple) compiler for a language exactly like that, i.e. LISP-type with indentation replacing parentheses. However, I found that this style becomes too complicated, because for long functions you can't easily see which parts have the same indentation. Perhaps special editor-support would help.

Pretty much everything that has an if statement would break, besides there already exists an if expression:

    'foo' if foo else 'bar'

It feels to me that the use of lambda is pretty much discouraged in Python. The preferred way to dynamically create functions seems to be an inner def.

Reply on news.ycombinator.com