bakery2k

That's right - Guido has been very much in favour of adding type hints to Python.

Are type hints Pythonic? I personally don't think so - to me, they don't match the philosophy of the rest of the language. On the other hand, one could argue that the definition of Pythonic is simply "whatever Guido likes".

Isn't Nim, like Python, a large, complex language? Looking at the documentation, it seems to include a huge number of features.

The Python equivalent of your JavaScript example is simply:

    def double(x): return x * 2

Python's `lambda` construct creates anonymous functions - its limitations mean it should only be used when anonymity is required. If a function is to be given a name, there is no reason to use a lambda over standard function syntax.

Would it be possible for Python's parser to handle the infix `->` syntax, without making it more complex than the current LL(1)?

In Australia, I've seen maps with North America in the top right.

I've heard of this - people considering Python 2.7 as an "LTS" version of the language, receiving bug fixes but otherwise remaining unchanged for many years.

I wonder, once 2.7 is EOL in a years time, whether the language developers will consider a "3.x LTS" release?

No, IMO. Don't get me wrong, Python 3 is a better language than Python 2. I just don't think it's that much better that it was worth breaking backwards compatibility and stalling the language for several years.

Python 3 did enough to break everyone's existing code, but nowhere near enough to make that worthwhile.

It's common for other language communities to consider the Python 2/3 transition as an example of "what not to do".

Is anyone using VirtualBox on the desktop? Specifically, to run Linux/macOS/Windows guests on a macOS host?

Would you recommend it? Or is the best option VMware Fusion, Parallels, or something else?

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

Your `f` is not a method, but a top-level function whose first parameter happens to be named `self`.

You can't call `f` as a method of any object, because in Python (unlike Ruby) the top-level namespace is unrelated to the namespaces of any classes.

There doesn't seem to be any interest in checking type annotations at run-time. Unfortunately, without doing so, type annotations look authoritative but are essentially just comments.

I believe Julia is an example of a dynamically-typed language which does perform such checks at run-time - including as part of its support for multiple dispatch.

You can't add methods to integers in Python, but they're still objects in the sense that you can call methods on them:

>>> i = 123

>>> i.bit_length()

7

> 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?

> indentation-as-syntax -- which I've always hated

What would you prefer? C-style syntax? Ruby-style `end end end`?

Regarding reason 3 (syntax), I don't mind significant whitespace in itself, but it has knock-on effects which can be problematic. It's the direct cause of Python's `lambda` limitations [1], and IIRC the lack of an explicit end-of-block marker is also the reason for Python not having `do-while` loops.

However, what would be the alternative to significant indentation? I really don't think C-style syntax would work for Python...

[1] https://www.artima.com/weblogs/viewpost.jsp?thread=147358

> `a.y() and do_x()`

If you're happy to write it that way round, why not just use `if a.y(): do_x()`?

I have replied to your post on /r/Python [1].

[1] https://www.reddit.com/r/Python/comments/9n18ot/ive_read_abo...

Or, of course, for British surreal comedy groups.

Python is, despite its simple appearance, a much more complex language than JavaScript. A V8 equivalent for Python is certainly possible, but would require even more work than went into creating V8 itself - who would be motivated to spend that much effort on Python?

Dropbox? They seem to be the company driving Python nowadays, but gave up trying to speed up Python in favour of writing "performance-sensitive code in other languages" [1].

PyPy uses a meta-tracing approach in an attempt to reduce the amount of work required. Its speed is impressive, but I'm sure meta-tracing leaves some performance on the table.

Another way to reduce the amount of work required would be to support only a subset of the language - for example, a V8 equivalent for MicroPython rather than for full Python. I'm sure this could be made very fast, but it would have very poor compatibility with existing Python code, so what would be the point?

[1] https://blog.pyston.org/

Doesn't Ruby essentially have a BDFL, i.e. Matz?

There are a number of these lightweight, embeddable programming languages - few are particularly innovative.

I have often wondered whether, rather than a new, very orthodox language, it would be more useful to have a lightweight implementation of (a subset of) an existing language?

However, my discussions about MicroPython have shown that many programmers would rather learn a new language than try to restrict themselves to a subset of one they already know. It's likely that programmers who don't know e.g. Python, would also rather learn a brand new language.

So, the number of lightweight, very orthodox languages continues to increase.

MicroPython is a subset of Python intended for resource-constrained embedded devices, unlike Gravity which is designed to be embedded in applications. This is a significant difference - a while back I considered embedding MicroPython in an application (the Lua/Gravity/Wren scenario), but the Python programmers I discussed this with generally disliked the idea.

It seems those who already know Python want either the whole Python language, or not Python at all. I guess it's easier to learn a whole new language, than to use a language you already know but where some parts are suddenly off-limits?

Is it possible to embed Gravity in my C/C++ project and safely run untrusted Gravity code?

The Lua implementation supports the creation of sandboxes to run untrusted scripts, but this is a feature that other embeddable languages (e.g. Wren, Python) don't seem to support.

I feel like this would be a basic requirement - or is it common to embed a scripting language without limiting what scripts are able to do?

> LWN.net deserves our support.

Agreed. I subscribed a few months ago, in part because LWN.net seems to be the only publication providing significant coverage of the Python Language Summits.

Guido has written a blog post explaining "Why Python's Integer Division Floors" [1].

Python also uses floor division, and the corresponding "sign-of-modulo matches sign-of-divisor", for floating-point numbers. The blog post claims that this can be problematic in certain cases (compared to C's "sign-of-modulo matches sign-of-dividend"), but does not give any concrete examples.

[1] http://python-history.blogspot.com.au/2010/08/why-pythons-in...

> Python being designed as a systems language rather than a scripting language

Interesting - I hadn't really noticed how pronounced this dichotomy within dynamic languages is. On the one hand there are small languages designed for embedding and sandboxing (e.g. JavaScript, Lua, Tcl) and on the other hand, larger, more general-purpose languages (Perl, Python, Ruby).

I always assumed that a dynamic language could work well in both contexts, but in fact, most lie fundamentally on one side of the divide or the other. Only JavaScript, due to its immense popularity, has really managed (with Node.js) to expand from the first category into the second.

If Python were to be embedded in Excel, it would be expanding from the second category into the first. As you mention, to do this safely it may be necessary to create a special (subset) version of the language. Matz, the creator of Ruby, is trying to take his language in this direction with mruby [1] - a "lightweight implementation of Ruby complying to (part of) the ISO standard".

But, will these subset versions ever be popular? They necessarily leave the majority of the language's ecosystem behind - and knowledge of the full language will not necessarily transfer directly to the subset. Can a subset of an existing general-purpose language, even a widely-known one, compete against other languages that are specifically designed for safe embedding?

More generally, is it possible for a dynamic language to work well on both sides of the divide, or must all (even brand-new) languages choose one side or the other?

[1] https://github.com/mruby/mruby

One issue with embedding Python is that it's difficult to sandbox - to securely limit what the embedded runtime, and hence (potentially malicious) custom functions, can do:

> [The Python developers'] standard answer to "How do I sandbox Python code?" has been "Use a subprocess and the OS provided process sandboxing facilities" for quite some time. [1]

JavaScript, OTOH, is designed to support secure in-process sandboxing. Other languages with such support do exist (e.g. Lua), but JavaScript is by far the most widely known.

[1] https://mail.python.org/pipermail/python-dev/2013-November/1...

Spoiler: V8's default array implementation holds pointers to boxed objects [Questions 5 & 6], but there are special-case implementations for arrays of doubles [1] and 16-bit integers [9] (and presumably others). However, adding a single string to an array of doubles violates the special-case and requires every double to be boxed, significantly increasing memory footprint [2].

It's interesting to compare this to a "NaN-boxing" approach, which allows pointers and doubles (and other simple values) to all exist in a single "namespace" of 8-byte values. In the (uncommon?) case of a heterogeneous array, this can save memory by avoiding the need to box simple values. The downside is that NaN-boxing prevents the use of full 64-bit pointers.

Thanks. I suspected as much for LuaJIT because, like a JavaScript engine, it supports JIT compilation of untrusted code. It's interesting to hear that PUC Lua also needs these mitigations even though it's only an interpreter.

As for implementations of Python and Ruby, they might not worry about these attacks - because AFAIK they do not try to support secure execution of untrusted code.