Hacker News Reader

> Take lists: some operations are methods, some are functions, some mutate the list, some make a copy, some are global, some are in a module.

Let's take the list type, the public methods are: 'clear', 'copy', 'count', 'extend', 'index', 'insert', 'pop', 'remove', 'reverse', 'sort'

Obviously as the names imply `copy` returns a new list, and `count` returns an integer. Neither mutate the list.

For the rest of it: methods mutate the list. There are some builtin functions that do similar things, but those always a new object (sorted, reversed)

OK, fair point. I misremembered the list interface.

`set` is a better example: `set.union`, for example, returns a new set, while `set.add` updates in place. (To be fair, this is with Python 2.7, maybe Python 3+ is more uniform?)

What would you expect it to do differently in those cases? That seems like the API is following how most people would think about those operations as you'd expect in a language which isn't trying to be immutable.

I thought it was interesting that Ruby, by convention, used an exclamation mark to convey that a function would mutate. I haven't used Ruby all that much to see how well that works at scale.

Many libraries don't use it. Another convention uses it for methods that might raise an exception.

> I've always thought there's a much simpler language struggling to get out of Python

I agree, although I suspect we have different ideas as to which parts of Python would be included in that simpler language. For example, I quite like the consistency of "everything-is-an-object".

FWIW some of the Python core developers have started to express a similar sentiment. Especially in the last few versions, where Python has got much more complex with the addition of type annotations and multiple `async/await` features. I wonder whether the retirement of the BDFL will slow down Python's rate of growth, or accelerate it?

> nested generator comprehensions behave differently than nested list conprehensions

I haven't come across this - could you give an example?

Sure:

  >>> [[x*y for y in xrange(1,5)] for x in xrange(1,5)]
  [[1, 2, 3, 4], [2, 4, 6, 8], [3, 6, 9, 12], [4, 8, 12, 16]]
  >>> list([x*y for y in xrange(1,5)] for x in xrange(1,5))
  [[1, 2, 3, 4], [2, 4, 6, 8], [3, 6, 9, 12], [4, 8, 12, 16]]
  >>> [list(l) for l in ((x*y for y in xrange(1,5)) for x in xrange(1,5))]
  [[1, 2, 3, 4], [2, 4, 6, 8], [3, 6, 9, 12], [4, 8, 12, 16]]
  >>> [list(l) for l in [(x*y for y in xrange(1,5)) for x in xrange(1,5)]]
  [[4, 8, 12, 16], [4, 8, 12, 16], [4, 8, 12, 16], [4, 8, 12, 16]]

The problem is that the `x` in the inner comprehension gets somehow linked to the variable `x` in the outer comprehension, rather that the value of `x`. (This matches Python's similarly bizarre closure semantics.) So, the results are "as expected" when either (a) the inner comprehension is evaluated eagerly (first and second example), or (b) the outer comprehension is evaluated lazily (second and third examples). But if both the inner and outer comprehensions are evaluated lazily, the inner comprehensions just see whatever the "last" value of `x` was, which I think to many people is surprising. (No less so than mutable default arguments, at least.)

You're right, this is the same problem that Python has with closures, for example:

    >>> l = []
    >>> for i in range(10):
    ...     l.append(lambda: i)
    ... 
    >>> for j in range(10):
    ...     print(l[j](), end=' ')
    ... 
    9 9 9 9 9 9 9 9 9 9

The issue isn't really closing over the variable instead of the value, but the fact that Python re-uses the same variable for each iteration of the loop. C# used to behave the same way, but its designers considered this bad enough that they made a breaking change to the language to fix it [1].

Unfortunately, C#'s solution (creating a new variable for each execution of the loop body) isn't really an option for Python. It would conflict with the rest of the language, which only uses variables scoped to whole functions.

Note that Go makes the same mistake as in earlier versions of C# [2].

[1] https://ericlippert.com/2009/11/12/closing-over-the-loop-var...

[2] https://play.golang.org/p/Pt6BN2Mj-WL

Is python really meant to be a beginner-friendly language? I tend to think of it as lisp-without-parens, and lisp is not very beginner friendly.

It is usually the "first language" of choice these days, when teaching programming.

That does not mean beginner-friendliness is one of its design goals.

It was though

https://www.artima.com/intv/pyscale.html

"So I never intended Python to be the primary language for programmers, although it has become the primary language for many Python users. It was intended to be a second language for people who were already experienced programmers, as some of the early design choices reflect. On the other hand, intuitively I probably stuck to many of ABC's design principles. Because although I had my criticisms of ABC, I borrowed many of its valuable elements, which eventually made Python a great language for people who aren't ace programmers or who are just learning. We now have a large community of people using Python as an educational language, teaching Python in schools. These people aren't and may never be professional programmers, but they still find some programming skills useful." -GvR

The very quote you linked explicitly contradicts you...

"It was intended to be a second language for people who were already experienced programmers, as some of the early design choices reflect. "

This has more to do with who has what teaching resources pre-made to sell than something any thought about the merits of a programming language.

Sort of. Maybe. When python was gaining momentum in university settings though, the one main argument I read from a professor more than a decade ago, is that the python implementation was near identical to their pseudocode. So they stopped using whatever language they were using in their textbooks, and started using python, since it made it easier to convey the knowledge they were trying to convey (and probably greatly decreased the amount of editing and typos).

Basically, don't discount a text book where every algorithm is executable code, without first having to translate it into some other language.

I think that's how it got so popular. It gets taught in school as a first language because it's "simple, beautiful", etc. and people stick with their first language as people do.

It's not a beginner language, but it is beginner-friendly.

It's actually a huge problem if you end up trying to hire people to build enterprise software in Python, because everyone and their mother has "5 years of Python experience", but "scripting on your own" is miles apart from "building well designed systems".

What would you consider a beginner language then?

I don't think the term has much value. Maybe Scratch.

"Language for people who are not programmers but who need to instruct computers to do things" is the definition I work with. Scratch, BASIC, etc., aren't really suited to that role. No-one who's just trying to munge some files wants to be told "OK first learn this language that isn't useful for you, and then you can learn a language that is". Hence why practically, Python tends to fill the "beginner" role, which is unfortunate due to its complexity.

Python is for people who are programmers, so it doesn't fall under your rule.

Also that rule is tautological.

Basic is much easier for a complete novice to get into.

It's true Basic was designed to be a beginner's language; but in practice, what exactly is easier in Basic? (Even disregarding Dijkstra's assertions that Basic "mutilates the mind", because I suspect he would have held the same opinion of Python!)

The "immediacy" is there in both languages (well, in Python and modern Basic without line numbers): you can just type code without any rituals or mumbo jumbo and it will do more or less what you tell it to.

I would chose C due to its simplicity and ubiquity.

Pascal was designed for teaching.

It was heavily influenced by ABC, a language meant to be used for teaching:

So, I decided to design a language of my own which would borrow everything I liked from ABC while at the same time fixing all its problems (as I perceived them).

http://python-history.blogspot.com/2009/01/personal-history-...

In practice, snippets of Python look very similar to pseudocode. A lot of the idiosyncrasies I see people bring up I consider "intermediate" or "advanced" Python. For the first 5 years I used Python I never wrote a class or a module (I was familiar enough to know when I saw one), let alone cared what a meta-class was.

Simple things are easy, complicated things are possible, though may be awkward. Better situation than many/most languages.

I think most beginners learn languages to solve some particular thing. Python has a lot of great libraries and tutorials for learning. It doesn’t matter if Python has a lot of idiosyncrasies—new Pythonistas are copy/pasting and mad-libbing their way to a basic understanding of coding.

Learning to program from first principles is hard, but I reckon Racket, a lisp, with it’s wealth of teaching materials and well thought out design is about as good a way to start as any. It’s small and consistent enough to actually learn from the ground up rather than by pulling on one thread.

> I've always thought there's a much simpler language struggling to get out of Python [...]

I tend to assume that about all languages now, and when I need to use a new language I try to just learn that simpler language initially. I skim the documentation for the rest, but don't learn it until I actually need it (either because the functionality is necessary, or it can make the code better).

It can take a surprisingly long time to need more than the simple language.

A great "simple beginner language" would be Lua, if only it had a decent standard library.

I think a simpler language would also have more potential for speedup. The effort PyPy has invested is herculean! Grumpy, Cython, Unladen Swallow, etc.

Python has fallen to my second or third most commonly used language now and speed is definitely a reason.

The C++ standard library is (mostly) an exemplary work, but that is despite the language's complexity, with pointers and lvalue, rvalue and forwarding references, just to get started...

Oh completely agreed. C++ the language is as or more complex/overcomplicated as Python. (Hence my example of Erlang as a simple language.)

"I wouldn't have to recommend Python to beginners any more, and be on the hook for explaining e.g. why default values are mutable, or why nested generator comprehensions behave differently than nested list comprehensions."

Maybe those scoping gotchas are not beginner topics?

> Maybe those scoping gotchas are not beginner topics?

They are the second one of your beginners trips over them. Especially the first one is fairly easy to encounter and really vexing.

That said, Python in my experience is an excellent beginner language, and I'd still recommend or teach it.

Believe this is largely due to history, ie. the agile manifesto point of not knowing enough until it is done.

I'd also welcome a simplified Python, from scratch as it were, but that is a giant undertaking and bigger than the 2 to 3 chasm.