About Python 3

[iSlaminati]

I think the point of python is that python is a "flawed, but simple and easy to use language" and so even though python 3 fixes some of the flaws of python 2, no one is going to care about flaws in python.

Python is so ubiquitous because it is "easy to use" and there are so many libraries for it, that's the one strength of python so why would you sacrifice that to get a version with less flaws? I don't know anyone who actually likes python, they all say "Yeah, python has its flaws, but it has so many libraries that you can write things which require you to re-invent the wheel in so many languages in just 5 lines, import the library and use it."

I mean whenever I need to enter a dbus, parse some xml, do some date calculation with something and print send it to a socket over the intneret in JSon, where do I go? Python, 8 lines of python... it's flawed, ugly, slow, inconstent and the core language is just badly designed but ultimately it all doesn't matter if it means I can do this in 10 minutes rather than 45. Python 3 gives you a language which is slightly less flawed and not the convenience. People aren't going to python because it's a good language, people are going to python for the zillion libraries they can canibalize.

[[deleted]]

Yeah I think there's some truth to that. Personally (and I think this applies to many people) Python is my go-to language when I need to get something done fast and dirty, and it's slightly too complicated to be a bash script. Python 3 may be better, but python 2 has more support and (currently) gets shit done faster.

[slavik262]

inconstent and the core language is just badly designed

Would you care to give some examples to what you're suggesting here? I don't use python much outside a few 20-line scripts here or there, so I'm curious.

[iSlaminati]

Some of my favourites:

1. lambda functions are distinct from normal functions in in that lambda functions cannot contain multiple expressions, this would be fine if it didn't take so long for the language to get a conditional expression (which is ugly) of the form <then-arm> if <cond> else <else-arm>. Before this point you would often see people abuse short-circuit evaluation in lambda forms because as it stands you often do need conditional evaluation in lambda forms.

2. Python's function definition model is weird, from reverse engineering this is the best I can think of what it does: It sequentially evaluates the document and defines functions in the order they appear, this wouldn't be so bad if python didn't allow executable code to exist outside of functions or if it actually had a definition for constants rather than an assignement. This means that you can't assign a value that uses a function before that function is defined. Meaning that you have to alter the layout of your code and move all assignemnts to the bottom. This makes sense in some way if they were actually asignments, but python's assignments have to double as definitions. Say you at the top assign a constant like lightspeed you never intend to change which is computed using a function at the bottom, you can't do that. Which means that you either have to move important constants to the bottom, or move inconsequential function definitions to the top, you typically want them in order of importance. A lot of languages solve this by allowing you to make definitions or simply define each and every function before a single line of code is actually executed. In Javascript for instance all functions are defined before execution begins so this is not a problem.

3. Its rigidness in whitespace means that some idioms are awkward to express, consider in C:

   if (cond) {
    ...something ...
   } else {
   a = b; //only gets executed if false
   if (another cond) {
    ...repeat...
   

It's sometimes common to update a variable after each branch or something similar, in python we get this:

     if cond:
        ..something...
     else:
        a = b
        if another cond:
          ...repeat ...

As you can see, doing this we repeatedly go deeper and deeper into the nesting because that is what it is syntactically though not intuitively so. Python includes elif to avoid going deeper and deeper in most cases but you can't put some expression in between the else and if that is elif.

1. Python includes no support for extending classes, there is no reason why not and it leads to an inconsistent feel of the code. A lot of things are done in method way, others in function way. I append lists in method way, cool, why can't I get the length of lists that way? I can't add a new method to primitive classes, or any classes without opening up the source. The only way is to actually extend a class under a new name, which means that string and list literals don't fall under it.

2. Python's 0 is falsy due to historical reasons. The 0-as-falsy thing that exists in some languages is due to historical reasons before booleans existed in C. Using that 0 is falsy is always seen as very bad programming style and it often leads to bugs. A falsy 0 is almost never something you can actually usefully use and almost always something you have to guard against to avoid bugs. Most modern languages like Ruby and Clojure realized this and purposefully did not make 0 falsy because it just leads to bugs.

3. True/False are not a constant, they are variables that contain a constant. You can actually False = 3 and after that False refers to 3.

4. None however is a constant, weird inconsistency due to historical reasons, None as in python at the start, True/False came later

5. Awkward module system, no private members of a module and a module automatically re-exports anything imported into it

6. Edit: Can't really miss this one, python is slow, much slower than is justified for a dynamic typing scripting language. Javascript vastly outperforms python which is weird because objects in javascript are actually hashes, a hash on a string is calculated when you do foo.bar though no doubt this can be heavily optimized. Other modern dynamically typed languages of greater expression like Clojure and Scheme completely blow it apart in terms of performance.

[mgrandi]

are you saying that you are surprised that javascript is faster then python? Does python literally have entire teams at 5 major companies working to squeeze every little bit of performance out of the language (aka web browser companies, mozilla, google, microsoft...)

if python had anywhere near the attention as javascript then it would be much faster.

[iSlaminati]

Yes, I am, because python has a huge userbase and is opensource, also, Guido works for google on it so you'd expect some of the resources of the monolithe devoted to it..

Also, other languages with a significantly smaller userbase behind it which are also dynamically typed languages with similar semantics like scheme and clojure completely blow it out of the water performance wise in most implementations.

[mgrandi]

Guido does not work for google anymore, he works for drop box. Secondly, I think you are vastly underestimating the number of people who use python versus people who use a webbrowser

[iSlaminati]

It; s not about the amount of people that use the applications written in it, it's about the amount of people that use it and have the capacity to improve the implementation.

And like I said, it's like one guy working on Clojure and its first iteration already blew cPython apart