Interview With Python Creator Guido Van Rossum (techrocket.com) 222
The online programming school Tech Rocket just published a new interview with Guido van Rossum, the creator of Python. "Looking back I don't think I ever really doubted Python, and I always had fun," he tells the site. "I had a lot of doubts about myself, but Python's ever-increasing success, and encouragement from people to whom I looked up (even Larry Wall!), made me forget that."
He describes what it's like being Python's Benevolent Dictator for Life, and says that the most astonishing thing he's seen built with Python is "probaby the Dropbox server. Two million lines of code and counting, and it serves hundreds of millions of users." And he leaves aspiring programmers with this advice. "Don't do something you don't enjoy just because it looks lucrative -- that's where the competition will be fiercest, and because you don't enjoy it, you'll lose out to others who are more motivated."
He describes what it's like being Python's Benevolent Dictator for Life, and says that the most astonishing thing he's seen built with Python is "probaby the Dropbox server. Two million lines of code and counting, and it serves hundreds of millions of users." And he leaves aspiring programmers with this advice. "Don't do something you don't enjoy just because it looks lucrative -- that's where the competition will be fiercest, and because you don't enjoy it, you'll lose out to others who are more motivated."
Damn! (Score:3, Funny)
I was expecting an interview with John Cleese. [thejohncleese.com]
Re: (Score:3)
He Didn't Ask the Big Question (Score:5, Interesting)
Re: (Score:2)
You obviously don't know what a "fluff piece" is or a "fluffer".
Whitespace (Score:2)
Re: (Score:3)
It's not about "a space", it's about levels of indentation.
The answer is basically that braces can match at different places on different lines and be perfectly valid; and many people write code just that way.
if condition
doThis
if otherCondition
doThisToo
else
humAF
Channels that strip spaces from lines (Score:2)
However, it's difficult to paste Python code through channels that apply the equivalent of lstrip() to each line. Slashdot's comment section is one of them: if you have your account's post mode set to "HTML Formatted", even <ecode> won't keep it from stripping spaces. (When I figured this out, I set my account's post mode to "Plain Old Text", which allows HTML tags but translates newlines to <br> elements and suppresses stripping in <ecode> elements.) At least in curly-bracket languages, y
Funnily (Score:4, Insightful)
Re: (Score:2)
Yeah I am a python programmer and the only thing I would add is that javascript is worse because it doesn't have a compiled format. Source code is directly included. If I include module B after module A, it can rename parts of A to its heart's content.
Comment removed (Score:5, Insightful)
Re: (Score:3)
Why can you not test all execution paths in Ruby?
You never can. Its the big failing of automatic unit tests. With strong typing your compiler can help with static analysis. But with weak typing you rely on unit tests to detect regression but because of the proliferation of code paths, you can't do that either.
Re: (Score:2)
Maybe it's just me, but my feeling is that objects are like salt. A little can do wonders for a bland food product. Too many can be worse than none at all. Having all file type objects behave the save and provide the same interface makes Python very easy to use -- when dealing with filish sorts of things. Defining new object types with new (often poorly described) interfaces just adds another layer of obscurity to the coding process.
BTW, it seems to me that one of Python's virtues is that it supports a
Re: (Score:2)
Having all file type objects behave the save
I couldn't agree more!
Re: (Score:2)
Interesting, and I always like hearing what people have learn from real and long experience. But I think there's a certain amount of begging the question. If you believe things should be more disciplined in an engineering sense, then sure, any or many problems which come up, can be seen to be due to lack of good engineering. Alternatively, someone could believe that problems came up due to a lack of good intuition about the nature of the project.
But whilst some languages can look more disciplined, it is har
Re: (Score:2)
I was just talking to an old Co-Worker from a C++ company I worked at a few years back. He asked "So what are you doing lately" and I told him I'm working on my thesis, which is titled "Ruby's a Terrible Programming Language, And You're A Terrible Programmer For Liking It". Then I cited a number of my complaints -- being able to add arbitrary functions to a live object, never knowing where to look for the interface definition of parameter objects, need to extensively test all execution paths of production code (Which no one ever does,) odd syntactic quirks and changes in syntax between language versions. He laughed and said he had exactly the same complaints about Python. You see, Object Oriented Programming was invented to reduce maintenance costs for completed projects, because that's where 90% of your expenses with the project will be. Ruby, at least, and apparently Python as well according to my friend's complaints, were invented to make the cheap part of the development process "easier", while at the same time letting the language fanboys pat themselves on the back about what clever programmers they are. This is exactly the opposite of software "engineering".
Well you can write terrible code in any language; C/C++ projects [viva64.com] are no [learncpp.com] different [stackoverflow.com]. The "engineering" part is between the keyboard and the chair; a fool with a tool is still a fool. That's why testing matters and, with modern automated testing, full test coverage is not difficult.
Python is a well structured, expressive, language that is suitable for many types of application. You don't even have to write OOP code if you don't want to; though if you do, Python has good OOP support. OOP is not a magic fix
Re: (Score:3)
Re: (Score:2)
Its funny. I am doing work now in python which I was doing in fortran in 1986.
Re: (Score:2)
It ... only calls functions when you stick parentheses after a function reference.
Python police: Pyhton's @property decorator allows you to call a function merely by referencing a variable.
Abstraction not always == progress (Score:2)
In computer science, abstraction means your code runs slower.
As long as that's okay, then yes, you're right. Otherwise, you're completely wrong.
Re: (Score:2)
Here's one problem: we -- individuals -- have limited time. The more efficiently it is used, which is to say, the less time we spend waiting on things to complete, the better off we are. Here's another problem: Some tasks are not fast enough. Here's another problem: computers are no longer getting faster at the same rate.
There are many classes of tasks that take significant amounts of time to complete. These are the ones that are a good case for higher speed langu
"syntax error: go to hell and hunt for it" (Score:5, Funny)
Interview With Python Creator Guido Van Rossum
Well, I tried to read it, since I'm a huge fan of Python. But one of the paragraphs was indented in a slightly different way than all the others, so I couldn't.
Re: Why in the heck should a file server need 2M l (Score:5, Insightful)
Because he understands the problem Dropbox is trying to solve better than you do.
Re: Why in the heck should a file server need 2M (Score:4, Informative)
Re: (Score:2)
His dayjob is as a senior engineer at dropbox - he did in fact build quite a lot of dropbox.
Re: (Score:3)
He joined Dropbox quite late on, they had a fully developed syncing platform for years before he joined.
He might have advanced that platform on, but its difficult to claim that he "built quite a lot of Dropbox". From what I gather, his main work is around optimising their python runtimes, compilers and interpreters.
Re: Why in the heck should a file server need 2M l (Score:5, Interesting)
I suspect a lot of that code lies in redundancy and load-sharing systems. Python is notoriously bad at multithreading (so much so that most python coders prefer a library called multiprocess that fakes multithreading by spawning new python processses entirely) - so load-balancing, load-sharing and redundancy under heavy use are problems python is particularly bad at (not the language so much as the architecture of the implementation to be fair).
So it's likely a great deal of the code is dedicated to solutions to those difficult problems. It also rather depends on how you count it. Other things that could contribute large amounts of code:
- They likely use a custom application server (in order to implement all that redundancy and load-sharing)
- There's likely a significant amount of debug logs in there, and extensive logging throughout (you need that if you're going to keep something like this maintained and find/fix problems quickly).
Finally - the comparison is not actually very fair. The Kernel is written in C - a language designed for brevity, while python is much more verbose. Python is not a language that encourages lots of one-liners, except where they can be used to avoid deep nesting (which is actively discouraged) or in purely functional calls (which are available but only encouraged for specific use-case determined algorithms where the non-functional version would actually be harder to read).
So the exact same algorithm is likely to use more lines in python than in C - and be a lot easier to read. I was not surprised to learn from this interview that a lot of his own early work was in Pascal and Algol - you can see a lot of the Wirth philosophy in Python. Python in a very real sense struck a perfect balance between readable verbosity and cruft. Java is too far to the other side, you need about 100 lines just to show a simple "exit on click" button on the screen and almost none of them have anything to do with the task at hand. The same thing in TCL/TK will take one line, in python it's about 3 lines (depending what GUI library you use).
I recently developed a fairly comprehensive GUI library in python. I was building an RPG in Pygame (need to pick that up again sometime) and pygame has no gui elements and none of the libraries are maintained, so I wrote my own. Python made this ridiculously easy for the most part. Hell at one point I actually wrote a recursive object (that is to say - an class in which one of the methods would instantiate another instance of the same class it's a method off). The class was a box containing a list of items you can select (used for things like the inventory) but when you need to add something to a box like that (say in the game editor - adding treaures into a chest) it instantiates another instance of itself, with different parameters to show you the list of possible things you can add.
That took no clever trickery whatsoever, the method just instantiated the class and operated on the object, python handled all the recursion magic entirely transparently.
That gave me (as a long time python developer) an entirely new respect for just how powerful the language really is. I also strongly suspect that in most languages that activity would have been far more complex, many languages don't even allow recursive classes after all.
Re: Why in the heck should a file server need 2M l (Score:4, Insightful)
The Kernel is written in C - a language designed for brevity, while python is much more verbose. ... So the exact same algorithm is likely to use more lines in python than in C
I dunno, YMMV, but to me the opposite seems to pretty much always be the case - for any non-trivial chunk of code, the Python version tends to require far fewer lines than the C equivalent. At several different companies we've ported various C modules to Python and it's common for the Python version to have only 20% (or fewer) LOC vs the C original. The reason is just the usual stuff: Python, being a much higher level language, introduces a lot of overhead but in exchange you get powerful built-in data types and have to do basically zero manual memory management.
This tends to show up in not just large libraries or apps, but even in small chunks of code. For example, below is a function from one of our network monitoring agents; as background, basically there are a bunch of different server clusters and a job monitor spits out an hourly file that lists on each line the IP address of each server and the number of errors it encountered (this is part of some legacy thing we're hoping to replace, it's kind of goofy). Anyway, those files get aggregated to a central monitor, that in turn looks for various conditions and alarms if e.g. the error rates are too high.
Anyway, here's a function that reads those files and tells you which servers are seeing the most errors (it returns a list of server IP address and number of errors encountered, in descending order of number of errors):
def ServerErrorRates(reportFiles):
counts = {} # ip addr --> total errors
for filename in reportFiles:
for line in open(filename):
ip, errors = line.strip().split()
counts[ip] = counts.get(ip, 0) + int(errors)
return sorted(counts.items(), key=lambda x:x[1], reverse=True)
Nothing fancy, but doing that in straight C is likely going to take far more than 7 code statements. There's just no way to perform the same work in C in anything close to 7 statements. It's not a knock on C, the two tools are just optimized for different things.
As another example, I just took a peek at our HTTP server library. The whole thing is a single file of less than 800 LOC, and that handles all HTTP request/response handling including header reading/writing, file uploads, cookies, websocket support, request routing, etc., etc. without using any of the HTTP stuff from the Python standard library. The C equivalent would certainly be several times as many lines of code.
I think you could maybe argue that individual statements in Python are more verbose than C, but it's common for each Python statement to be the equivalent of several C statements (and/or many statements in C are simply not required in Python), so on the whole Python programs end up being way more concise. Occasionally I'll see an exception, but it's just that - an exception.
Re: Why in the heck should a file server need 2M (Score:3)
Thats actually a good point I had not considered. But I do think at the level of something as close to the metal as file management that pythons verbose names and syntax would make it bigger than C. At application level the higher level of abstraction should win for python.
Re: (Score:3)
Yeah, that's a good point. I think an even better example might be low level bit twiddling of a byte stream and conversion back and forth between a struct in memory and a packed binary file format - C rules there and in Python you end up jumping through weird hoops a lot of times. The struct module helps a lot (though to your point it's more verbose than the same task in C), but only to a point.
Re: (Score:2)
I pretty much agree, but the other guy's point about threading is spot on. Python doesn't have concurrent execution of threads, but only of processes. This can lead to some fierce work-arounds and hard problems. Multi-processing requires multiple python interpreters to be loaded (one/process). Etc. So does any other approach to concurrent execution. (ZMQ comes to mind, but I generally don't use that to start another python process, except while in the process of rewriting something into a different la
Re: (Score:2)
Yeah, no disagreement there - I was addressing just the LOC aspect.
FWIW Python's threading model does have concurrent execution of threads, but only for a part of the time - it does support true OS-level threads, but a single, process-wide interpreter lock gets held when running Python bytecode or in a Python API function, so /some/ applications see benefits to using multiple threads (typically cases when you can either do lots of work in a C API or when you are waiting on I/O and just want concurrency but
Re: (Score:2)
Re: (Score:3)
He meant to say 2 million functions in one line of code.
Re:Why in the heck should a file server need 2M li (Score:5, Insightful)
He meant to say 2 million functions in one line of code.
We're talking about python, not perl.
Re: (Score:2)
> We're talking about python, not perl.
Same language pretty much. The difference being that if you have to look at your code six weeks later, you have some chance of being able to figure out what the Python code does.
Re: (Score:2)
So you've never seen Python code I take it, because there's no similarity between the languages. Effectively none.
One needs braces and semicolons, the other uses space, one allows in-line regex, the other doesn't, the one can have RSA implemented like this:
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
The other looks like this:
#!/usr/bin/python
from sys import*
from string import*
a
Re: (Score:2, Informative)
It's the "serves hundreds of millions of users" part. I know "web scale" is an overly used buzzword but it is in fact very difficult to serve huge numbers of users. There's also collaboration tools, an API for other developers to integrate Dropbox into their own software, etc.
Python community so much nicer than Rust's? (Score:2, Interesting)
What I'm most curious about is why the Python community is so much nicer to deal with than the Rust programming language's community.
I've seen so much help and compassion from the Python community. I'm not just talking about questions that I've asked, but questions and problems that I've witnessed other people ask about. The Python community is always so supportive, and in all of the right ways. They aren't smug or holier-than-thou. They don't tell you "you're doing things wrong". They may ask for more info
Re:Python community so much nicer than Rust's? (Score:5, Insightful)
What I'm most curious about is why the Python community is so much nicer to deal with than the Rust programming language's community.
In my limited experience in the VFX world it's because people using Python are focused on actually creating usable products that solve people's problems. And I use the word "people" not "developers" in this instance because a lot of them are "non-programmers" solving problems that they themselves face. Python is a tool to them to make their lives better.
Re: (Score:2)
You have to be reasonably good at programming to use python effectively. Yes, you might be able to write a hello world program in 2 lines but its not a beginners language and neither are the concepts it uses so I doubt these "non-programmers" you mention are any such thing. Sure, they might not do programming as a *profession* but they obviously have previous programming experience.
Re: (Score:2)
Well, that makes sense, and explains the attention that numPy gets (also Cython), but I have a hard time believing that it's THAT large a percentage of the developer community.
My guess is that it's largely age related, which some large effect coming from "leading from the top". Guido is rather easy-going, and he doesn't encourage others to be harsh or abrupt.
Re: (Score:2)
What I'm most curious about is why the Python community is so much nicer to deal with than the Rust programming language's community.
Damn, and I had just decided to start learning Rust as a non .Net, outside-of-work, new experience. So by the time I get enough idea of what I am doing to need to ask for help, you think I will feel neglected?
I always did enjoy Python tho, maybe I should just go back to that for my non .Net fun.
Re: (Score:2)
A big part of it probably comes down to age. Python is 25 years old now. A large part of its users will be an older, calmer and wiser audience. Rust is a relatively new language, so its userbase will consist of many younger, more hot-headed "avant-gardists" types.
Re: (Score:2)
Re: (Score:3)
Rust certainly isn't a defacto choice when thinking of how to implement a solution at this time, but it has some characteristics that do make it a very attractive consideration. I think it
Re: (Score:2)
I've seen so much help and compassion from the Python community.
The compassion comes from the shared suffering. :-)
Re: (Score:3)
Parent is being modded into oblivion, but it's a fair question: Why would a file server need 2M lines of code?
Seriously, even with all the user stuff and housekeeping, it seems like an insane amount of code.
Re: (Score:2)
Re: (Score:2)
"...the dropbox client programs, all platforms..."
Even so, perhaps I'm out of touch, but 2 million lines of code??
The Space Shuttle reportedly uses about 400K lines, and Quake 3 was about 350K lines or so....maybe this is the new 'normal', but 2 million lines of code for something like Dropbox just seems....excessive to me.
Oh well, I'm off to write my 20,000 line "Hello World!" program and sell it to the TSA for a million bucks. I'll be back after lunch!
Re: (Score:2)
Why?
Re: (Score:2)
Considering that it was a purely emotional expression with no attempt at rationalization it may have no rationally explainable reason at all. He could literally just be a guy who found Monty Python terribly unfunny and annoying (it's theoretically possible for such a person to exist) and thus got pissed off by all the MP references in the sample code and tutorials.
Re: (Score:3)
Why 2M lines? At a guess, core functionality is a few thousand lines or maybe a few tens of thousands of lines. Plus a LOT of management software -- report generators, collecting garbage at the application level, etc, etc,etc, . And it has to talk to its users through HTML which has a lot of virtues, but is extraordinarily klunky at times. It does probably email. And it replicates ftp sorta? It distributes work over a vast complex of servers. It presumably does billing, and payments, and all that stu
Re: Why in the heck should a file server need 2M l (Score:4, Informative)
I can easily see half that change coming just from gaining access to Jinja2. I've worked extensively with a huge array of templating languages in recent years, and while they all have basically the same syntax none of them are anywhere near the sheer unadulterated power that Jinja2 offers.
It took me a while to figure out just what it was that Jinja2 had that they all lacked and which made such a massive difference. I finally nailed it down. All of them have, right in the beginning of the manual guides on how to write helper functions to extend the language. Jinja2 barely mentions that. The reason is simple: it hardly ever needs them. This is because Jinja2 exposes any data you pass to it as the original python object - with all that object's methods available inside the template.
That's extremely useful. The problem with the "helper methods" approach is that you're screwed whenever the thing running the template is not code you have access to (or can afford to alter). In a corporate environment you may be using a tool like consul-template which you really don't want to maintain a local derivative off, so you can't use any functions in your templates that their derivative of golang-template did not already include. With Jinja2 even with somebody else's code you still have access to every method the data type object exposes.
So if you have to get the overlap of two lists in your template from two disparate upstream data sources you don't have to hope the template language includes the right list operators, you just use the built-in methods of the list objects directly.
Have you seen what a list-overlap seeker written in pure golang-template looks like ? It's a hellish maze of deeply nested loops and if statements and the output enmeshed inside all that gunk because golang lacks a sufficient set method to create new variables that can let you pre-construct your new list before looping over it.
I had to do just that recently, the golang template was well over 500 lines of unreadable and barely navigatable junk - I did the same thing in less than 5 lines of Jinja2.
So I can easily imagine that for a web app that's highly template driven you could end up with a huge amount of code that exists within the templates (or as helper-functions to the template library) which you can throw away if you redo it in python.
Re: (Score:3, Funny)
You had me up till you said Java.
Re:Interpreted languages should cease (Score:5, Informative)
Learn how to use a compiled language like Java.
If you have a need for speed, compile Python code to C binary with Cython.
http://cython.org/ [cython.org]
Re: (Score:2)
The guy clearly said people need something lean and fast. Like the java virtual machine, for which you compile to BYTE CODE!!!1!
Re:Interpreted languages should cease (Score:4, Interesting)
Like the java virtual machine, for which you compile to BYTE CODE!!!1!
Serpent, maybe?
Serpent is a real-time scripting language inspired by Python but completely reimplemented to support real-time garbage collection and multiple instances of the virtual machines running on independent threads.
https://sourceforge.net/projects/serpent/ [sourceforge.net]
Re: (Score:2)
That would be pypy [pypy.org].
Re: (Score:3)
You're thinking of Emacs. C-x M-c M-facebook [xkcd.com].
Re: (Score:2, Funny)
Java is a horrible language to use compared to Python. At least say something smart sounding like Go or Haskell.
Re: Interpreted languages should cease (Score:2)
I would say the opposite - interpreted languages like python are a huge problem when it comes to maintenance in the long run. I have seen many systems rendering headaches that would be figured out during compile time in a non-script language.
Re: (Score:2)
Which uses more memory: a small Python program, or a small Java program?
Also, performance isn't always important. If your program is IO-bound, you might see no real improvement moving from Python to Java, or even to C.
Re: (Score:2)
Learn how to use a compiled language like Java.
Java doesn't compile to machine code it compiles to pseudo code which is then interpreted (Not quite as slow) at runtime. If you want a proper compiler try any C, C++ etc.
Re: (Score:2)
Java also compiles critical paths to machine code. It's called HotSpot just-in-time compilation. That's the reason why Java can achieve performance comparable to C++ in some use cases.
Re: (Score:2)
Python compiles to bytecode, much like Java does. In fact, Python was doing it several years before Java was ever introduced.
Yes, one can argue that JVM bytecode then sometimes gets JIT-compiled to machine code, but by that point, the Java programming language is gone. What actually gets JIT-compiled is JVM bytecode, and this could have been compiled from any language. Like, say, Python [jython.org].
Re: Only One Question (Score:5, Informative)
Works as long as what you make in that language won't get too big.
Two million lines of code for DropBox is pretty impressive for a script kiddie language.
Would've been better in Perl (Score:2, Informative)
Re: (Score:3)
Hey I could do that in C with ten million lines of code!
Re: Only One Question (Score:5, Interesting)
Works as long as what you make in that language won't get too big.
I think that's true of all languages.
My impression (having written O(10k) line Python programs for fun) is that it's quite capable of implementing the kind of O(1m) line COBOL, PL/1 & C systems I worked on in the 80s and 90s - probably in a tenth of the size too. It's also infinitely better for "Rapid Application Development" (is RAD still a thing?) than the 4GLs and BASIC variants we used back then.
Python is one of the few bright spots in the evolution of programming languages over the past 30 years. Too bad van Rossum fucked up the transition to version 3.
Re: (Score:2)
Too bad van Rossum fucked up the transition to version 3.
If you're still running Python 2 code, you should into the mirror see where the problem lies. Python 3 is working just fine these days.
Re: Only One Question (Score:4, Interesting)
If you're still running Python 2 code, you should into the mirror see where the problem lies.
The problem lies far beyond the mirror. It lies in the dozens of libraries that I rely on that have not upgraded to Python 3 (despite pleas to the original authors). It relies on the hundreds of hours of porting, testing, and double checking that I will need to do to move my code over to Python 3. The improvements in Python 3 are real, but they are not worth the enormous burden imposed on everyone to get their code to be Python 3 compliant.
Re: (Score:3)
This has improved quite a bit recently. I still write all my stuff to run on both 2.7 or 3.x, but more and more I'm able to use 3 exclusively. Yeah, there are a few try: blocks and imports at the top of all my files, but it's not so burdensome. It's not like they are forked - 2.7 can be made to behave very similarly to 3.x. Just run your tests in both versions.
Re: Only One Question (Score:5, Informative)
Here's a list. Only 30 out of the top 360 packages aren't ready for Python 3.
http://py3readiness.org/ [py3readiness.org]
Re: (Score:2)
Only 30 out of the top 360 packages aren't ready for Python 3.
My main project relies on about 50 different libraries. I just looked through the first ten of them, and only was on your top 360 list. Even determining which libraries I need to update will be a project.
Re: (Score:2)
On the other hand - have you seen the extreme hackyness of encryption libraries in python2 - and how clean their code is in the python3 versions ? The 2.x versions are filled with horrible work-arounds to deal with python 2's lack of a proper byte-type - trying to mash things into the string type without having overflow errors. More than a few resort to rewriting every character using hex-codes on-read and then storing the hex-codes as strings - which needs (expensive) back-and-forth conversion on every acc
Python, 2to3 and retesting (Score:4, Informative)
There's probably working, and there's actually working. When you have a complex system that a business actually depends on, running 2to3 absolutely requires that everything be re-tested. The larger the system is -- and that can mean interactions with libraries, databases, other languages, etc. -- the larger that testing job is, and it gets larger in a nonlinear fashion with the amount of code as interactions multiply.
However, Python 2.x isn't going to go anywhere. If you have a substantial system or systems written in it, and it's doing what it supposed to be doing, there's actually no reason to move it over. If you want to, you can write new stuff in 3.x; no reason they both can't exist on the same machine(s), either. Either one can call the other. Nothing to it.
Personally, so far at least, I have no specific need for 3.x, and so haven't bothered with it for anything serious, but I'm not against using it if some reason arises that makes it more useful than 2.x. I can't say I really object to 2.x becoming stable because development is going towards 3.x, either. Again, it reduces the need to re-test, and it keeps the unit testing mechanisms stable as well.
Re: (Score:2)
That's a *VERY* interesting assertion. There are a couple of Python2 libraries that I'd like to call from Python3, and there's some code that would be easier to write in Python2 than in Python3...so how do you do it? Even better, got any good links?
Re: (Score:2)
A python script can control what executes it with the shebang line at the top:
#!/usr/bin/python2
So it follows that a script can also have:
#!/usr/bin/python3
at the top.
so:
#!/usr/bin/python2
import subprocess
import json
subprocess.Popen(["pythonScript", "/path"], stdout=subprocess.PIPE, shell=True)(result, err) = proc.communicate()
The called Python script can return a json result, which you can in one step parse out into a local python object such as a dictionary, etc.
You can use t
Lack of PEP 397 held Python 3 back (Score:3)
#!/usr/bin/python3
Shebang lines like that didn't work on Windows from 3.0 through 3.2. Windows determines which executable to run by examining the portion of the filename after the final period character. Only in version 3.3 did Python gain py.exe, a shebang line processor for Windows implementing PEP 397.
Python has Sqlite support and javascript does not
You were saying? node-sqlite3 [github.com]
Re: (Score:2)
Any transition takes work. ... it isn't something that's even that hard.
Think about everything that could have been accomplished if the community had not needed to focus on 2to3. We could have had a functioning JIT by now.
Re: (Score:2)
Why "unicode" strings in Python are nonsense? Simple - they are useless for pretty much anything that deals with the real world. Read and weep: https://lwn.net/Articles/68335... [lwn.net]
Re: (Score:2)
If you're still running Python 2 code, you should into the mirror see where the problem lies. Python 3 is working just fine these days.
The problem was Python 2 was never end of lifed so nobody felt any urgency in moving. Even worse, major features were backported and kludge libraries like Six appeared to paper over the cracks. The python community managed to split itself in half and confuse the hell out of everyone who ever tried to run a .py script and discovered they had the wrong Python runtime.
The correct option would have been to give a definite end of life Python 2.x, e.g. 5 years of maintenance and bug fixes before it gets shoved
The real reason py2 refuses to die. (Score:2)
If you're still running Python 2 code, you should into the mirror see where the problem lies. Python 3 is working just fine these days.
The "fuck up" the GP is referring too is that py3 broke backward compatibility, when it costs real money to manually port your code to a new version - it's a broken upgrade. For example - I have created an automated build system at work with py2, since py2 still works just fine why would I even try to justify spending time and money porting it to py3?
Re: (Score:2)
http://www.diveintopython3.net... [diveintopython3.net]
That alone makes it worth-while, at least if you give a damn about securite. Go look at any encryption library for python2 - it's a horrible ugly mess of trying to work around the limitations of python2 strings. Python3 provides the bytes type as part of the string overhaul - which makes encryption code massively cleaner and run a *lot* faster.
What the fuck? Python 3 was very well done. (Score:2, Interesting)
Actually, Guido didn't "fuck up" the transition to Python 3. It was done almost perfectly.
People using Python 2 haven't been affected by it much. They can upgrade whenever they want, and Python 2 has still seen excellent support from the Python maintainers.
Meanwhile, Python 3 has been able to resolve some serious problems with Python 2, providing a much richer and more useful language. Developers have been moving to Python 3 at their own pace, which i
Re: (Score:3)
"Now that Python 3 has proven itself, it's seeing widespread adoption within the Python community. It's what almost everyone is using for new code."
Maybe I should look into Python 3 again, then. A few years ago, I was rather turned of by the deprecation of the % interpolation operator on strings, since 75% of what I do with Python involves number crunching and then writing those numbers in ascii as "%.4g\t%.4g\t%.4g\n" strings. The other 25% involves string processing of ascii with an occasional utf8 or la
Re: (Score:3)
% interpolator is still there and still works - it is not recommended since the .format method is much more powerful and well worth the transition, but the old way should keep working (at least in part to make porting code like yours easier and allow a piece-by-piece port).
Probably the single incompatibility that causes by far the most problems is actually the deprecation of the print statement, but one could argue it should never have existed. Print has always behaved like a function, it should have been o
Re: (Score:2)
I just read that the string % operator is no longer deprecated or scheduled for removal, as of Python 3.3:
http://stackoverflow.com/quest... [stackoverflow.com]
And yes, .format() is more flexible, but it requires much more typing for my typical case of printing 5-10 float values on a line and I wouldn't say that the end result looks more clear either.
None of the error messages on my 300-line script was about the issues that you mention, except maybe that xrange() doesn't exist anymore because range() itself is an iterator in Py
Re: (Score:2)
Re: (Score:2)
Actually, Guido didn't "fuck up" the transition to Python 3. It was done almost perfectly.
So why are they releasing updates to version 3.4.x after releasing updates to 3.5.x?
Are developers now splitting into those who use the 3.4 branch and those who use 3.5? That is, all those who are not still using 2.7 something?
How perfect is it exactly?
Re: (Score:2)
So why are they releasing updates to version 3.4.x after releasing updates to 3.5.x?
For two reasons. First, to make life easier for maintainers of long-term-supported GNU/Linux distributions. Second, because minor versions of Python historically break binary compatibility with extensions, and most users of Python for Windows have no way to recompile extensions that include native code for a new minor version.
Re: (Score:2)
i still use qbasic, you insensitive clod!
Re: Php is a disaster (Score:2)
I can agree that php is a disaster. But visual basic is bad, and so is vbscript.
Java isn't verbose compared to many other languages. Ever tried to do anything in Cobol?
Re: (Score:3)
Its funny. I have heard Java described as the new Cobol. Its not so much that the java language is verbose. Its more that its ecosystem of APIs is verbose in the way you go about using them, and the scalabilty of the language seems to cause software architectures to grow out of control.
Re: (Score:2)
Perl is just right except for the multiple ways of returning an error. Is it undefined? Or zero? Or a null?
There's no null in Perl (5). Well, 'undef' is technically a null, but that's covered by your 'undefined'.
Both zero and undefined are false when evaluated in a boolean manner. So return either. It doesn't really matter most of the time.
I prefer to return an empty list: just a plain return; does that.
Re: (Score:2)
Not really. It's basically just interpreted C with classes, plus sigils ($), minus the need for variable declarations (but with C typecasting).
Re: (Score:3)
The best advice is to find work you enjoy doing that others don't enjoy doing, which is also desired by clients. At any rate, I pursued an enjoyable thing and made a success of it so your sample size is up to 2 now.
Re: (Score:3)
I think every successful programmer is probably an example of applying this advice. I've never met a successful programmer that hated programming, and most people hate programming. But the field has gotten more crowded, so perhaps many people are now doing it purely for the money.
Re: (Score:2)
I'll bite, though I wish you hadn't posted anonymously. :)
1) I don't think Twisted is that relevant because it's judging a language based on a library that some third party wrote. And Twisted was insane in part because of the callback-oriented approach to asynchronous programming it took (these days you can use e.g. gevent, which is awesome).
2) The whole whitespace issue is pretty simple, actually. In all the languages you cited (C, C++, Java, etc.) there's a problem in that in reality there are *two* syste
Re: (Score:2)
You don't even like the dead parrot sketch?