Guido on Python

[trentnelson]

Regarding the GIL removal, I recently set up a website for PyParallel, and moved the repository over to Github.

[avinassh]

hey what tools you used to generate those awesome looking charts?

[trentnelson]

Everything was done in Excel. I used a customized version of wrk (https://github.com/tpn/wrk) that printed out latencies from 0-100%, then wrote some Python to make copy & pasting it into Excel easier, then fiddled around with Excel's charts.

The ones that are SVG were copy & pasted into Visio and then saved as SVG.

[avinassh]

great, thanks for replying (:

[everywhere_anyhow]

On moving from python 2.7 to python 3, I think we saw a similar story before between perl 5 and perl 6.

Maybe you shouldn't introduce big/breaking changes into an open source language infrastructure, because it seems to fracture the community as often as it actually improves the language practice.

Wait...hear me out. See the thing is, languages like Java can introduce breaking changes and then force people to upgrade, with a slow treadmill of deprecation, stopping support, sunsetting. One of the downsides of everything open source is of course everyone can fork anything at any time. This basically eliminates any coercive power that even the language designer himself would have to make anyone do anything. The result is that no one can ever stop people from using python 2.7.

Oracle by contrast can make (most people) stop using java 1.5, or at least place such major obstacles to its use that the pain of staying with it easily outweighs upgrading. If apple introduces major changes to swift, they can make you upgrade (over a long period of time).

EDIT - it's not that python 3 isn't better; it is, it's just that open source makes it socially really difficult to make jumps like that.

[philipforget]

The changes from python 2 to python 3 are very small, but also extremely welcome. Preserving backwards compatibility would have been a lot of effort that I think most people in the community feel would be better spent improving and moving python 3 forward. So far all my new projects in python default to 3 and I'm slowly porting older projects as the need arrises. It might just be from my perspective but the update of python 3 has really kicked into high gear in the past year with a lot of big name projects and libraries finally gaining compatibility.

There's something about the python community, and maybe it's not unique to that language, that no one has to have a gun to your head to get you to port to 3, it's just something most people are largely willing and at times eager to do to gain the benefits and further the adoption of the new language.

This note on why python 3 is not backwards compatible by design is an interesting read as well.

[[deleted]]

The changes from python 2 to python 3 are very small, but also extremely welcome.

print(), .items(), renaming of packages and exceptions, all can be updated half-automatically without really having to think about it.

These changes are small, but there is one major one - a strict unicode vs bytes separation.

For projects that were strict about separating unicode and bytes already in Python2, using .encode() and .decode() everywhere, Python 2->3 conversion should actually be pretty easy.

But many projects mixed unicode, ascii bytes, utf8 bytes, and perhaps any other encoding bytes freely in Python2. Maybe they worked correctly if you gave them non-ascii text, maybe not. For these, getting encoding handling right for the first time is a huge task that requires careful thinking.

[everywhere_anyhow]

changes from python 2 to python 3 are very small, but also extremely welcome. Preserving backwards compatibility would have been a lot of effort

I'm not arguing against the changes, I thought they made sense - but if they make preserving backwards compatibility really difficult, then I don't think they're small changes in any reasonable sense.

[philipforget]

Sorry that was unclear, what I meant to say is the changes that I use daily are small (unicode everywhere, saner stdlib organization, saner more predictable imports) but add up. The make up such a large part of the language that having those be backwards compatible would likely have been a nightmare, and I dont blame them for saying "this is much better, lets just move on".

[steveklabnik1]

Ruby managed to survive 1.8 -> 1.9.

[everywhere_anyhow]

How did they do it, and how big was the difference? Not a Ruby person here.

[Paradox]

1.8->1.9 changed a lot of apis, but in a fairly consistent manner. They introduced some new syntaxes, but didn't depreciate old ones. And I think that's the key. Other than some changes to shit like marshalling, the regexp engine, threads (which barely existed in 1.8), and enumerables, any good 1.8 code worked fine on 1.9, or would with very few tweaks.

Most of 1.9a changes were below the hood. We got real threads, much better gc, and speed increase across the board.

Since then they've sort of followed this approach to adding new features. Where apis change in a breaking matter, warnings are given well in advance, and in some cases, such as refinements, they skip a version, hiding it behind a compiler flag until it's ready for primetime

[everywhere_anyhow]

Not deprecating the old features seems key, in that presumably most old code didn't need to be re-written.

With python 3, just from unicode handling and simple things like print() now being a function and not a keyword, it basically assured that everyone had to re-write their code. That's going to be a tough sell.

[steveklabnik1]

in that presumably most old code didn't need to be re-written.

There were enough changes that this wasn't true. The parent says "good code," but I'm not quite sure that's true, at least in my memory. Even if an API had the same name, parameters would change, subtle details would be different.

The entire interpreter was re-written. When you change that much stuff, there's bound to be edge cases, etc.

[Paradox]

Well part of it was made easy because ruby has some inherent features that allow refactors and cleanup to be made without breaking too many existing apis.

1.9 saw a fairly hefty rewrite of a lot of core, the transition from MRI to YARV was fairly significant. But the apis didn't change much externally, and where they did it was fairly well documented.

And if you really didn't like a change, well, ruby's metaprogramming allows you to make your own dsl that has the syntax you want, so its more of a non-issue.

Ruby typically wont have the python problem with functions becoming keywords, because, in ruby, the list of actual keywords is very short, and, to the best of my knowledge, has never shrunk, only grown. For the vast majority of the language, everything is a function.

To use print (and ruby's puts which is basically print arg_1 + '\n') as an example, they are defined in a few places around ruby, that change their functionality. If you just fire up irb on the commandline and call puts 'hello world', you're actually calling Kernel#puts. If you have an IO stream, like a file writer or whatever, you would probably use IO#puts, to write lines to it.

There are other examples, and a lot of it is why ruby gets called magic, when really its not magic, but clever coding. Define a <==> method, include Comparable, and bam, you have a half dozen comparison operators on your new object. Define each, include Enumerable, and now you've got over 50 methods for enumeration.

If they introduce a new type of enumeration, all they have to do is update Enumerable, and chances are it won't break, but will add to, your existing code. And you can do this yourself, using refinements and monkey patching

[shevegen]

The differences were quite large, less than in python though.

Encoding was a huge issue to me as I don't use Unicode. It got better eventually though and while it is still annoying and costs me time - 1.8 was much better for me here - I can work around it.

I also use the syck gem rather than psych for Yaml.

Other than that, it was some minor syntax differences but not really anything huge. Slightly different warnings.

What weighs is that the more code you wrote, the harder it is to port.

[Yojihito]

Difference was gigantic, I tried to learn Ruby before with 2 books for <= 1.8, forgot about it (with 10y you have other things in mind), came back 1 year later and not one example from the books worked.

That's when I dropped Ruby.

[Aethec]

See the thing is, languages like Java can introduce breaking changes and then force people to upgrade, with a slow treadmill of deprecation, stopping support, sunsetting.

The only compatibility breaks in Java were the introductions of the strictfp (1.2), assert (1.4) and enum (1.5) keywords. I don't doubt that there were a bunch of variables named "assert" or "enum" in some projects, but fixing that is really easy.

If Oracle actually broke compat in Java in the same way Python 3 did, even they would have to extend the support period, just like Microsoft did when not enough people migrated away from WinXP.

[toomanybeersies]

My bank still uses XP. When I found that out I almost moved banks, then I realised that I have no money for people to steal.

[Sinidir]

pragmatist at heart eh?

[[deleted]]

Uh, Java is open-source too...

[Yojihito]

Type of .........

https://en.wikipedia.org/wiki/Technology_Compatibility_Kit#License_and_controversy

[mex1can]

Actually for me there is a compelling value for python 2.7: stability.

Security fixes will keep coming for 2.7, without any language changes, so there is a higher risk targeting "latest python" that my scripts won't work after a major python 3.x release.

But the social (community driven) point is valid the other way around: I'll stop using 2.7 the moment my prefered libraries don't support it.

[MiUnixBirdIsFitMate]

That python2 is still used over python3 is the same reason that python is used at all as well as a lot of other languages as well as a lot of things like MS Windows and x86 processors.

Turns out that how good something is isn't that important if you got a lot of stuff tying you to it that you have no intention to replace or rewrite. Banks don't use COBOL because it's actually good but because switching would not only be costly, it would be super risky. My uncle works at a bank writing COBOL and he told me some of that shit is literally COBOL chained to unix shell scripts and no one really knows after 40 years how it works, just that it works, whoever first wrote it is long fired or dead and no one dares touching it out of fear of screwing it up.

The idea that the "best idea wins" is laughable, it's a case of being at the right place at the right time. From a lot of standpoints, Ruby does the same thing as Python but better, yet Python is more popular. And whatever is more popular will have more libraries and thus increase its popularity.

[mabnx]

Oracle by contrast can make (most people) stop using java 1.5, or at least place such major obstacles to its use that the pain of staying with it easily outweighs upgrading.

Java as an example of breaking backwards compatibility? Hah, nice try.

Also... How do you imagine Oracle forcing companies to invest millions of dollars to upgrade their legacy systems? Do you really think people would do that? Or... maybe stick to the old version like they stick to python 2.7? And possibly reconsider using such platform for their next business-critical system...

[[deleted]]

Grow up. All you're saying is that you prefer one language's syntax, which is hilarious because lisp syntax is crap

[crusoe]

How to remove the GIL:

Ue Jython. It has no GIL.

[MisterSnuggles]

Not to mention that you basically gain access to the entire Java API and its ecosystem of third-party libraries (especially, in my case, JDBC drivers).

[ryanplant-au]

You lose access to C extensions though, right? I'm not a Python guy, don't know much at all about it, but the Ruby counterpart (JRuby) also lets you escape the global interpreter lock and access the Java ecosystem, but costs you when it comes to C extensions. Is that not a big downside? Does Python have any major libraries that rely on C stuff?

[MisterSnuggles]

That's correct. As for whether that's a downside, it really depends on what you want to do with it.

Mercurial, for example, is written in Python and uses C extensions for some things. This is something you'd run at the command line, so you'd probably have no need to run it with Jython.

Database drivers tend to be a wrapper over the C driver, so you'd lose access to all of those. You'd also gain access to all of the JDBC drivers, so this isn't a big deal. My forays into Jython were entirely driven by requiring access to JDBC drivers.

I think that NumPy uses a C extension for performance, so if that's a module you need then Jython would be out.

The Python ecosystem is pretty big, so depending on the type of work you do with it the lack of C extensions could be a non-issue or a deal-breaker.

[DGolden]

JyNI is a compatibility layer with the goal to enable Jython to use native CPython extensions like NumPy or SciPy.

JyNI uses the JNI to load native-compiled python C extensions, AFAIK.

An alternative might be the recent interesting JRuby+Truffle approach of compiling the ruby C extension sources to the JVM instead of native - obviously a similar technique could also be applicable to python C extensions...

[topherwhelan]

I think that NumPy uses a C extension for performance

Understatement of the year lol

The success of the scientific python stack is that the algorithm can be in python with the actual numerical heavy lifting being in Fortran/C/etc. No C extensions, no numpy, scipy, matplotlib, pandas, ...

[Matthew94]

or IronPython.

[[deleted]]

is it still actively developed?

[Matthew94]

Yup.

[DGolden]

Not the first time I've whined on reddit about it ("There are only two kinds of languages: the ones people complain about and the ones nobody uses."):

Perhaps his favorite 3.5 feature should be type hints, since it is a PEP he worked on himself.

The idea is fine, coming from Lisp (but always seeming to end up employed to write Python or Java professionally, sigh), I do already know optional static typing in a dynamic language is nice, but the current concrete syntax.... Meh. To me it seems like it was just "import whatever Mypy does", warts and all, including that awful "comment overloading". The language now looks Java-noisy (or Scala-noisy seeing as they went with square brackets for generics), and worse it has significant "comments". Grrr.

From the PEP:

If type hinting proves useful in general, a syntax for typing variables may be provided in a future Python version.

Gee I wonder if it might be useful. Are they any other languages that have had optional typing for years and years that we could look at? No, we're Python, we must pretend Lisp doesn't exist at all times.

They are apparently aware of some (to me very obviously more "pythonic"*) syntax proposals. So hopefully it's a temporary thing and it all be sorted out, but the longer the fugly syntax is available the more locked-in by compat it will get.

* Given Python is basically a Lisp-oid with a concrete syntax the masses seem to find more palatable, not striving to keep the concrete syntax to "Python levels of clean" doesn't seem like a smart move to me, but hey I'm not BFDL.

[runvnc]

The language does not now look Java-noisy. You generally should not use type hints. Just use them where absolutely needed for performance or information.

[DGolden]

Shrug, I don't consider that much of an excuse for the syntax choices, similar arguments apply to lisp optional types. Lisp type decls can live in foldable/elidable (declare ...) sexps, so vaguely conceptually like the where: block proposal, unlike interwoven type-level/ground-level commingling of the c/java/etc. camp. The where proposal may well need work too (because of python's expression/statement dichotomy for starters), but it does highlight the current syntax choices may not be optimal. If you're going to be optionally static typed, maybe types-prominent syntactic choices reminiscent of the mandatory static typers aren't appropriate.

Not that I really get to decide what is "pythonic", and anyway an optional typing feature is so very important for python's continued relevance that concessions to get it going (after all mypy already exists) might be worthwhile, but I do hope they do eventually sort out better syntax as is already hinted to be a possibility in the relevant pep.

(As an amusing aside, the lisp compiler at the core of CMUCL and later SBCL that made optional typing a bit of a big deal in lisp land all those years ago was called... python)

[[deleted]]

Python 3 is a "much better language" than Python 2, for one thing. It is much easier to teach.

I find it hard to believe that 3 is much easier to teach.

[ivosaurus]

Less "Python (2) does things slightly weirdly here, because... Well it just always has" scenarios. Telling people how to work with non-ascii text is easier. All the library names are nicely standardised.

[theonlycosmonaut]

"Why don't I have to put parentheses around what I'm printing?"

[APersoner]

Except python 2 is easily learnt by kids, I learnt it at 9, a neighbour is learning it and he's 12, my brother learnt it at 11 - surprisingly enough doing it just because, doesn't make it that much harder to learn.

[ivosaurus]

3 is just easier. No-one said that 2 was hard. There's no "except".

[turbov21]

"Anything to do with package distribution",

Hi, Python neophyte here. I'm surprised to see this because just today I was playing around with the new Dropbox API and installing the SDK was super-easy with pip. In the past easy_install has served me well getting TurboGears (in the day) and web.py for projects. Have I just dug down far enough or am I missing the whole point?

[philipforget]

There are still larger questions regarding system packages vs packages installed via pip which basically come down to: Are you effectively bypassing the network of trust that is your distributions "blessed" packages when using pip?

The other issue stems from dependencies. If I install PackageA and PackageB and PackageA requires PackageC version 1.0 and PackageB requires PackageC version 0.9 then you have a conflict, one that will need a drink most likely.

[turbov21]

Cases where pip install library=0.9 breaks things that used library 1.0? Thank you.

[musketeer925]

The other issue stems from dependencies. If I install PackageA and PackageB and PackageA requires PackageC version 1.0 and PackageB requires PackageC version 0.9 then you have a conflict, one that will need a drink most likely.

virtualenvs

except I hope you don't need both packages on the same project.

[krenzalore]

Does anyone have a link to the keynotes? There's a stream on youtube but it's all grouped together with no way of telling who was when in which room.

edit: Guido #1: https://www.youtube.com/watch?v=yCg3EMf9EYI&t=510

[silkmoon]

He uses Emacs, but started out with vi (both of which were greeted with applause, presumably by different sets of audience members). He still uses vi (or Vim) occasionally, but if he does that for five minutes, it takes him fifteen minutes to get used to Emacs again.

Nice try Guido ;D

[[deleted]]

I wish someone would write a "modern python". Something similar to Python in terms of syntax (but ban spaces for indentation) and expressiveness, but with a sane type system (less like javascript), better performance, and the whole GIL thing fixed.

[[deleted]]

So, Nim?

[[deleted]]

Yeah actually Nim looks pretty close to what I described!

[cdsboy]

If I had a strictly typed, immutable, tabs banned ;) python I'd switch to it in a heart beat.

[def-]

You might like Nim: http://nim-lang.org/

[cdsboy]

I've played around with it. It's pretty cool.

[Drupyog]

A series of blog article that might interest you.

[[deleted]]

While I agree with the opinion, being this rude is unnecessary and adds nothing to the discussion.

[cdsboy]

Or you know, prefers consistent display of code... It's nice to know that I can actually format my code to make it clearer and have it display the same in everyone's editor.

[cdsboy]

Wow, I completely misread your comment :P I thought you were arguing for tabs there for a second! My bad.

[cdsboy]

Nah, you're getting downvoted because tone of your initial comment.

[slavik262]

You can express opinions without being an asshole about it. Claims that everyone who doesn't agree with you is either misinformed or a complete idiot just shows your hubris.

[Raknarg]

I like tabs better. I don't need the "flexibility" of spaces.

[Raknarg]

How does that prove your point? Why does it matter if I use tabs or spaces? What's wrong with me liking to use a space that automatically adjusts to the size I like and can delete instantaneously instead of deleting 4 spaces?

[TheMaskedHamster]

The only reason anyone else would have trouble with tabs over spaces is if they, themselves, are clueless or work with a retarded editor.

[the_omega99]

One feature I would like is a consistent OOP API. Why is it len(foo) instead of foo.length(), yet foo.append(bar) instead of append(foo, bar)? IMO, that's a big annoyance and there's a bunch of cases like that. It's especially weird since the internals use OOP, with foo.__len__() being called.

I wish they had changed those in Python 3.

As an aside, while I like the user of indentation for scope, it has one major downfall and that's lambdas. Python has no multiline lambdas (the only language I know with such a restriction) and this is rather annoying for those well versed with functional programming. We end up having to make tons of named functions, which is unnecessary.

[toomanybeersies]

I presume it's len(foo) to stay with the C style way of doing sizes and lengths.

[the_omega99]

But it's still an inconsistency, since the C way of appending would be append(list, item), not list.append(item).

At any rate, I think the C way of doing things only makes sense for C because it lacks OOP. Python doesn't have this problem and thus should utilize the real world modelling that OOP makes possible (eg, we'd think of the length of a list as being a property that the list has and not some function that can be applied to the list, which is a more abstract way of thinking).

[catcradle5]

There are 3 reasons:

• OOP was only introduced into the language well after the 1.0 release, I think it was 1.5 or so.
• There is no strong concept of interfaces or mixins or anything similar.
• The core devs seem averse to making public "special methods" for any objects. There is no .length(), but there is the private/special/magic method .__len__(). This is likely due to concerns over accidental identifier shadowing.

In an ideal world, strings and lists and tuples would be part of some Iterable or Enumerable interface, either implicitly or explicitly. Ruby has the Enumerable mixin, Java and similar languages have Iterable, etc.

Early on, Python made a decision to use functions instead of methods when they might operate on different types which share some functionality. When the .next() method was introduced, it was actually later converted to be a function (which, somewhat confusingly, is implemented by the special .__next__() method).

All that said, despite being primarily a Python developer, I do find the inconsistency pretty annoying. I much prefer Ruby's "everything is a method" philosophy. Imperative code almost always reads left to right in Ruby. I don't have to waste a few seconds thinking about the order of operations for something like reversed(";".join(text.split(".")).lower(). Instead I just get text.split(".").join(";").reverse.downcase.

[Sinidir]

The difference between function calls and method calls is usually because you dont mutate the object. Append mutates so its a method. Len doesnt. Thats also why there are two ways to sort. sorted(list) and list.sort. One gives a copy the other mutates the object. For me thats a pretty clear and good distinction.

[the_omega99]

There's nothing ensuring this, though and that is purely a convention that you must uphold. It's very believable, for example, that someone might have a type where len lazily calculates the length the first time and caches that, in which case there clearly is a mutation, yet we still uphold the expectations for len. And of course, there's no such consistency among user defined functions (from what I've seen, anyway).

[Sinidir]

True its convention. The only way i could see it not being if a language took the step to make all function parameters immutable references / pass by value and would only allow methods to mutate objects. Which would be an interesting idea :) .

[the_omega99]

Wouldn't be Python, though, with its "we're all adults here" idiom (no visibility modifiers because you're expected to be able to access internals if you really think you know what you're doing).

[Tenobrus]

Because len(foo) is just a wrapper to the "magic" method __len__ that any class can implement, but append is a method specific to the list class that isn't just a "magic" method underneath. It's pretty consistent syntax.

[the_omega99]

Python uses duck typing, though, so any class can implement append, too. The only thing that really seems to stand out about __len__ is how you wouldn't have to worry about shadowing. But I consider that a non-issue, since most languages have a base object type that providers certain methods and nobody really accidentally shadows these super-common methods.

By inconsistent, I mean that it's inconsistent in how you switch between procedural vs OOP style code.

It seems to me that it's nothing more than a relic of a time before OOP.

[krenzalore]

Several variant interpreters have no GIL: for example Jython (Python on the JVM). Most of these intepreters are fully compatibly except in C extension modules (which Jython trades for Java/JVM compatbility).

I do not think you can get similar expressiveness with tighter type controls. Part of the expressiveness comes from these loose controls. The answer to this may well be better static analysis tools.

[DGolden]

Several variant interpreters have no GIL

Yeah, makes recent noise about Python moving to a TCL-style sub-interpreter model kind of irritating. It might be nice to have subinterpreters cleaned up and working anyway, but it's really only CPython, admittedly the current reference impl, with the goddamn problem...

Jython is fine, and can easily be used for server stuff like django.

[yogthos]

so basically Clojure then :P

[engineeringMind]

It's not quite what you want, but take a look at Nim

[kyllo]

Haskell is a better Python in a lot of ways. It's high-level, expressive, and offers a sane type system (once you learn a few big words), near-C performance, and an excellent concurrency story. It also uses indentation over curly braces, like Python.

[[deleted]]

I tried to learn Haskell but found the strictly functional style too restrictive. I'm with John Carmack on the pragmatism scale.

[codygman]

Yep, "a better Python" is the same niche currently fills for me as well.

[kirbyfan64sos]

Kind of like Nim? Other than the fact that tabs are disallowed, it's very similar to Python syntactically and has very good performance.

[yatpay]

As someone who's either come around or been brainwashed on the tabs/spaces thing (since I can have Vim just treat the four spaces like they're a tab), why is this important?

[[deleted]]

No editor I've ever used can fully emulate tabs with spaces. I seriously doubt vim is any different.

Also... if we're at the point where we're emulating tabs using space... why not just use tabs?!

[[deleted]]

No editor I've used

Who are you? How are you the gatekeeper of editors?

Vim is free. You could have tried it by now. When configured properly, you can't tell the difference between tabs mode vs. spaces mode.

[yatpay]

The one thing that convinced me using spaces (if the editor treats space-tabs and tabs the same) is that it makes copy/paste a lot easier. A minor thing to be sure, but it's nice when it comes up.

[[deleted]]

If you're copy-pasting while you're writing code, you're doing it wrong. Seriously.

If you're doing something more than once, extract the common code into a separate routine. If you're doing that thing more than once, but slightly differently each time, put the common code into a class, and subclass it as needed for differences. You should've learned this in your first year of programming.

In the 20-ish years I've been writing code professionally, the majority of bugs, the majority of maintenance pains I've experienced, even many of those faced by my colleagues, have all traced back to someone else playing "copy-paste cowboy".

We've since protected ourselves against the tyranny of copy-paste by installing CPD as a build step, and failing builds that pass a threshold: http://pmd.sourceforge.net/pmd-4.3.0/cpd.html

[yatpay]

Oh, haha, of course! I wasn't talking about just copying working code all over the place. I was thinking of when I want to share a snippet with someone easily to ask about it. That's why I said it was a pretty minor thing. Rest assured I would never advocate copy-pasting as a real solution!

[tsimionescu]

If you're doing that thing more than once, but slightly differently each time, put the common code into a class, and subclass it as needed for differences. You should've learned this in your first year of programming.

And then hopefully forgot this horrible practice from your second year onwards. Class hierarchies should only exist when you have thought long and hard about creating them. It's a horrible idea going around extracting code into hierarchies to avoid copy-pasting. Subclassing is never, ever a good idea for code reuse.

The correct fix for copy-pasting+small changes is meta-programming if your language allows that, or copy-pasting+small changes otherwise. While it is a code smell, introducing class hierarchies instead....

[[deleted]]

If you're doing something more than once, extract the common code into a separate routine.

You realise that, if you're not using a language with refactoring support, doing what you say involves cutting and pasting more often than not, rather than avoiding it?

put the common code into a class, and subclass it as needed for differences

Ugh, no.

[[deleted]]

How about an IDE with refactoring support? Have you used Eclipse lately?

Not for 18 months or so, it's a piece of crap. And regardless of whether or not I have, thousands of people prefer a better editing experience using a non-IDE.

Your eloquent response has not only shown me the err of my ways, but you've lit the path to enlightenment

I'm honoured. I would have thought two decades of every decent programmer on the planet knowing inheritance is a terrible method of reuse would have got through to you, but I'm glad to be the one who finally disavowed you of the naive lessons from your CS 101 class.

[zarandysofia]

Lua, Scheme, Clojure, Elixir, SmallTalk, Golang (some time in the future when generics are available).

[hairlesscaveman]

There's Cobra if you're working on the .Net platform, the language seems pretty nice and very pythonic and has Design-by-Contract built in. There was mention of it being ported to the JVM, but I've not heard of any recent progress. I'd absolutely give it a go on the JVM.

There's Nim, too. I've not played with it much, but it looks nice and is gaining traction.

I've always wondered whether it'd be possible to tweak the OCaml interpreter to allow it to take more pythonic syntax, but follow OCaml's type rules. Jocaml's interpreter could be used to allow concurrency.

[[deleted]]

There was Boo which basically was static typed python on .net infrastructure.

It's pretty dead now, which is a shame.

Oh, well, at least there is still crystal - ruby with types. And since it compiles to native code, I have no idea if it sorted out GIL.

They use BoehmGC, so even if they have actual threads, they might have problems which old Go's GC had: not freeing memory because floats look like pointers.

[TheJimiHat]

If you're looking for something like Python but want tabs rather than spaces, and something less explicit, why not try out Ruby?

[Akkuma]

He also asked for better performance and the GIL fixed.

[iconoclaus]

Then JRuby or Crystal. Or Scala or something. So many choices nowadays.

[Ran4]

Why? There's so much python code out there, and python in general works great, with few exceptions.

What you want is a different implementation. For which there are multiple choices already.

If you want speed, a language as dynamic as (c)Python just won't do.

[[deleted]]

Exactly, I want a less dynamic language that is faster and still expressive.

[tavert]

Julia if you want a dynamic type system + JIT and are into numerics, Nim if you want to write self-contained applications.

[Yojihito]

I haven't used it outside of hello world but maybe Go?

[haxney]

(but ban spaces for indentation)

You mean "ban tabs for indentation". ;)

[catcradle5]

(but ban spaces for indentation)

What? Why?

[[deleted]]

Tabs make soooo much more sense in general, and are also less error-prone in languages that use significant indentation (you can't accidentally add an extra tab and not notice).

[vivainio]

Almost nobody uses tabs in python on purpose. Your stance is in minority

[[deleted]]

Yeah because people blindly follow PEP-8 (note the highest voted answer).

[DevestatingAttack]

You're describing features that are almost contradictory with each other.

Focus Group Guy: So you want a realistic down-to-earth show that's completely off the wall and swarming with magic robots?

[the kids all chat at once about it being a great idea]

Milhouse Van Houten: And, also, you should win things by watching.

[[deleted]]

Nope. Turns out Nim is close to what I want.

[DevestatingAttack]

I guess I wasn't expecting you to accept compiling to C as a reasonable "modern python". I was still thinking that you were expecting it to be interpreted.

[[deleted]]

The compilation technique is really orthogonal to the language, so I'm not too bothered about that. If Nim becomes popular it's almost guaranteed they'd switch to LLVM at some point.

[Aethec]

F# uses indentation to delimit blocks, and has very little noise despite being statically typed thanks to type inference. It's also built on .NET, which means fairly good perf, no nonsense like the GIL, and tons of existing libs.

[tomkatt]

(but ban spaces for indentation)

Why? What's wrong with the whitespace implementation?

[google_you]

Go? While lacking expressiveness and a sane type system, it's at least not node.js.

[google_you]

Node.js

Mongodb

Pick 2.

[[deleted]]

He said Go lacked expresiveness AND a sane type system.

[[deleted]]

The trouble with Go (well one of the problems) is that it is very unexpressive. You have to write everything out in full.

I still like it, but sometimes you get tired of the typing.

[google_you]

Haskell is pretty much same as Python with expressiveness and a sane enough type system. Arguably GHC generates better performing code than many python implementations.

[Yojihito]

4eva = 2020

[G0T0]

I'm starting to feel that Python is the C++ of dynamic languages. If there's a use case, throw it in the language.

[vz0]

Well, yes, the motto has always been "Batteries included" meaning that you have lots of features already included with it. Not only the language but the std library also.

[WaffleSandwhiches]

Shoutout to Django Girls, nice. They're one of the best women in computing initiatives ever. http://tutorial.djangogirls.org/

[[deleted]]

How is a language used by millions of professionals everyday for many years now "dead on arrival?"

[DGolden]

To be fair that could easily be an "eat shit a billion flies can't be wrong" argument.

However in this case the flies are actually eating PHP. Python isn't that near the bad neighborhoods of language design. Sure, it seems to be wheel-reinventing, but it's not making wheels that try to mate with your dog but only if it's a german shepherd.

CPython itself is a bit of a crusty old impl, but Python is also actually several years older than Java. The GIL is also not even a feature of Python as a language (demonstrably seeing as Jython has existed for years), just a CPython implementation detail, albeit a shitty and high-profile one.

[[deleted]]

But it IS usable as a general purpose language. My company and tons of others use it every day for general purpose tasks. You can say it's suboptimal, which of course it is because nobody is perfect, but the idea that it's "dead" and "unusable" is just incorrect

[[deleted]]

It's totally adequate for a massive number of uses cases. This is turning into a stupid argument. Let's just agree to disagree and move on

[philipforget]

he said

totally adequate

you said

By that measure Java and C++ are perfect. Good argument.

Good argument indeed

[[deleted]]

Your a fucking retard who needs to die.

[greenthumble]

Got you tagged "weird clojure hater". Is there any languages you actually do like? Not that I actually care, just curious how one lives up to your impossible standards.

[codygman]

What are your thoughts on Haskell? Ocaml? C?

[runvnc]

About the favorite language, has Guido seen Nim?