Slashdot Mirror
Interview With Python Creator Guido Van Rossum (techrocket.com)
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."
of code? Seriously, WTF.
Why isn't Python as cool as Perl? Now that Perl is no longer trendy, we're guerrillas using Perl to reform a web wasted by the financial ambitions of Silicon Valley dweebs.... when will Python catch up?
Because it's written in Python.
Because he understands the problem Dropbox is trying to solve better than you do.
So he created Python AND Dropbox? I don't think so.
I was expecting an interview with John Cleese.
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
When we replaced our PHP inventory system with one written in Python, it only requires 11 lines of Python on average versus PHP. 2M sounds like they're doing something wrong.
"He describes what it's like being Python's Benevolent Dictator for Life"
I'd rather be Python's Benevolent Dictator for the School of Sillywalks for Life.
He meant to say 2 million functions in one line of code.
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
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.
You had me up till you said Java.
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/
"seen built" didn't say he built it himself.
Website Just Down For Me? Find out
Java is a horrible language to use compared to Python. At least say something smart sounding like Go or Haskell.
There are lots of excellent compiled, statically typed languages. Java isn't one of them: it's a programming language design disaster.
No, no, no! Not that compiled-to-machine-code crap!
The guy clearly said people need something lean and fast. Like the java virtual machine, for which you compile to BYTE CODE!!!1!
I wanna see facebook rewritten in perl. I bet it would be faster. No, I'm not a sadomasochist, why do you ask?
C|N>K
Well php is a programming language disaster. Java is just too verbose. Python uses invisible whitespace for closures and JavaScript has an addon jump table for functions and class methods.
Perl is just right except for the multiple ways of returning an error. Is it undefined? Or zero? Or a null?
Ruby has the strangest use for the pipe character. Haskell decides to monadify your code like monogamous monks. No extraneous print statements for you.
Decorators anyone? When has preprocessor code suddenly become a valid addition to a language spec?
Rant over. Let's stick to visual basic.
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/
He meant to say 2 million functions in one line of code.
We're talking about python, not perl.
#DeleteChrome
I know this article was focused on Guido's softer side, but would have liked them to mention the elephant in the room: the move from Python 2 to 3. This been a huge resource drain on the entire community and many (including me) remain unconvinced that it was the right decision. It would have been nice if the topic was broached.
Fast Federal Court and I.T.C. updates
QED. Search your feelings, Luke. You will see that Perl is the path to enlightenment.
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 information, but then they always provide a helpful response without resorting to snark or a bad attitude. They're friendly and pleasant people to deal with.
Then there's the Rust community. In my opinion and experience, it's so much worse than the Python community to deal with. The smugness is pretty extreme from them. They will often tell you that you're "doing it wrong", even when you're doing something a certain way for a very good reason that they just don't/can't comprehend. It's almost like they're more concerned with their own feelings than with helping somebody who is in needed. And you'd better hope that you don't say the wrong thing at a site like Hacker News or reddit, because the Rust downvote squads will take you out quite rapidly! The last thing they want to hear is legitimate criticism of Rust. All of the emphasis that the Rust community places on the Rust Code of Conduct and the Rust Moderation Team apparently doesn't do any good, because the Rust community is not one that I like to deal with!
Maybe it's a maturity/age thing that causes the Python community to be so much nicer to deal with? The Python community members are generally older and more experienced. The Rust community members are typically much younger, with some of them not even being out of high school yet. Maybe the Python community is better to deal with because the Python community members have more professional real-world experience, while Rust community members often have none at all? The Python community members are more laid back and confident with providing help, while the more immature Rust community members are on a quest to inflate their sense of self worth?
That doesn't make any sense.
Wrong : because he's an old-school thinker : more lines = more impressive.
He could as well have argued that his Python language served more cat pictures than any other language.
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 is exactly how it should be!
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.
If you want to see an example of a real fuck up, look at Perl 6. That's a real disaster! Here we are, over 15 years later, and there's still so little to show. Rakudo is an awful joke. Even the Perl 6 logo is goddamn childish.
Another example of a really fucked up programming language is Rust. They kept promising Rust 1.0, and then it kept getting pushed back again and again. But while this was happening the language was changing significantly almost every day. So code you wrote on a Monday often wouldn't compile at all by the following Wednesday, and would need significant reworking by the following Friday! The first impression a lot of people got about Rust was a lack of stability and having to rewrite their code every week. Even the 1.0 release was pathetic. Despite being "stable" releases, it took them up until Rust 1.6 to get their libcore stable!
Man I hate Python with a passion
people need something lean and fast. Like the java virtual machine, for which you compile to BYTE CODE!!!1!
Like C object code, or LLVM object code, or WebAssembly object code, or JIT compiled Java code...
Even ASM.js is faster than Cython output.
He is a good programmer. People like that are real programmers not only got crazy about the C standards stuff... But because created a computer language (good useful one, not only bonkers). I think this guy should be taken and tortured with a plastic back until he tell us the secrets behind Apple. Trust me guys, it's reading a porn mag.
It can probably be made as a one-liner.
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".
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Man I passion a Python with hate
Why?
http://michaelsmith.id.au
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.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Comment removed based on user account deletion
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 stuff -- 500 million users is a few more than I'd entrust Intuit's off the shelf software to do. (Actually, 1 account may be more than I'd trust to Intuit). And it tries to be secure which means you can multiply the complexity of even the simplest undertaking by a factor of about seven.
But you're right. 2M lines is a lot of code.
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
> 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.
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
Linux has ~10M lines of code and it's one fo the most used piece of software in the world. File management is a tiny portion of those lines with the file system called ext4 being just 30K lines. To say you need 2M lines of code to implement a Dropbox-like service properly (including the frontend and similar) is lying to oneself about how efficiently it was made.
I know I'm probably going to be modded a troll, but this post is serious.
I really do hate Python. From the stupidity that was "twisted" to insanity that whitespace should be used to define code blocks.
I have yet to look at a Python App I have to extend / modify / maintain etc and think to myself "ya know what, Python is an alright choice for this".
I've used C / C++ , Java, Go, Javascript, Clojure, Perl, PHP, Lua, even Ada and Pascal. I've still never had the same gut churning reaction to code that I get everytime I know I'm going to be dealing with Python.
What the heck is the attraction? I have never seen anything written in Python that would not have been more concise, performed better and been far more maintainable in pretty much any other language save perhaps Perl.
Please clue me in. My 20+ years experience is sadly lacking in any Python enthusiasm.
captcha: syntax
Only if you use perls bells and whistles all at the same time.
If you use it like c (and the is easy because the syntax is very c like) and comment the odd bits like pattern matching which generally needs a comment in whatever language. Then it is pretty readable and eliminates an awful lot of boiler plate.
I'm currently generating pdfs from a sqlite db in a couple of hundred lines of code, all readable because I use sensible function names that describe what is happening.
I find closures and functors much more akin to goto abuse when trying to follow old code.
Is there somewhere I can learn how to write fast Haskell?
Because all my attempts end up being extremely slow and spending all their time allocating and freeing memory.
The cognitive biases invoking when the successful examine the reasons for their success are so huge you'd be better off tossing a coin.
"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."
Sounds logical, but it's completely wrong. Enjoyable work is overcrowded; lucrative but boring work is so fantastically well avoided by people (because it's boring, and because of nonsense soundbites like the above) that people can sew markets up for years with a product it took them six months to write.
Van Rossum with his sample size of 1 has pursued an enjoyable thing and made a success of it. I can list 99 people who have pursued an enjoyable thing and predictably made no money from it because lots of other people are pursuing similar things. But people who look for opportunities and work towards them without regard for how much "fun" it is seldom even fail.
"Where there's muck, there's brass" as they used to say in England. Dirty jobs (which to us means boring jobs) pay extremely well, and they are reliable.
His dayjob is as a senior engineer at dropbox - he did in fact build quite a lot of dropbox.
Unicode killed the ASCII-art *
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.
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.
Unicode killed the ASCII-art *
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.
Unicode killed the ASCII-art *
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.
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.
Unicode killed the ASCII-art *
That would be pypy.
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.
Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.
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.
Like the java virtual machine, for which you compile to BYTE CODE!!!1!
Well, there's Iron Python, which compiles to .NET, and Jython, which compiles to Java. If you want to modify your code a little, there's Cython, which compiles to machine code. In addition, if you need CPython compatibility for libraries, PyPy can run 5-10x faster and has Py3 support now.
The vast majority of people use CPython, which is the *reference implementation*. Those are not made to be fast, they are made to be a reference.
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.
This space intentionally left blank
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.
As opposed to a new-school thinker: newer = more impressive?
Thanks Guido, for the steaming pile of hot garbage that is Python. You can take your whitespace scoping and stick it.
Go had a flag package and the Python programmers brought use 8 more before they started replacing the OS/exec package. They are half way thru replacing the net/http libraries with idiotic Python syntax and should have pythonG ready soon.
Obviously he never had to fight old make scripts. Any language that depends on tabs/spaces/line position is a primitive pos and is basically glorified RPG.
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.
You might be one of the people targeted by the templating changes made in the new go release. I don't work with them, so the new features were lost on me, but your complaint brought the talk to mind.
uhm, you can compile java to machine code. It's just most of the time it doesn't make a big difference. Also it's not pseudo code, it's Bytecode. Which is the equivalent of machine code for a machine that doesn't exit.
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.
Just cruising through this digital world at 33 1/3 rpm...
-- What’s one piece of advice you can give to young people interested in a career in programming? Find something you enjoy doing. You’ll spend more time doing it, so you’ll become better at it, and then you’ve got a competitive edge. Plus, having fun doing it means you’ll have more fun! 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. -- Great answer. Very wise. Good job.
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.
Unicode killed the ASCII-art *
And this is my actual comment.
Seriously, WTF dude, stop splitting your comment between the title and the body.
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.
You don't even like the dead parrot sketch?
Speaking of Dropbox and Python, Guido gave an excellent talk on the History of Python at one of their techtalks. You can view it online:
Guido van Rossum on the History of Python
remove nospam. to email!
Writing C code to do file management is a chore compared to Python. I like and use C but have always found Python results in less code.
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.
I also hate Python. I've learned that any dynamic languages cost me more frustration than any productivity gains.
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.
I've fallen off your lawn, and I can't get up.
I've fallen off your lawn, and I can't get up.
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.
I've fallen off your lawn, and I can't get up.
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?
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
You're thinking of Emacs. C-x M-c M-facebook.
Check out my sci-fi/humor trilogy at PatriotsBooks.
The fun part is you can do that in even fewer lines of Python if you wanted to ...
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=argv;[s,p,q]=filter(lambda x:x[:1]!='-',a);d='-d'in a;e,n=atol(p,16),atol(q,16);l=(len(q)+1)/2;o,inb=l-d,l-1+d
while s:s=stdin.read(inb);s and map(stdout.write,map(lambda i,b=pow(reduce(
lambda x,y:(x>8*i&255),range(o-1,-1,-1)))
Even super-short highly optimized Python with semicolons for whitespace removal looks nothing like perl.
All due credit to http://www.cypherspace.org/rsa... for sources.
- Michael T. Babcock (Yes, I blog)
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 language so that I *don't* need to start up another python process.)
Still, that's a huge number of lines of code, and I don't see the reason. But, of course, I haven't studied the problem.
I think we've pushed this "anyone can grow up to be president" thing too far.
It doesn't say what the 2M figure actually covers. If that includes the dropbox client programs, all platforms, then that doesn't seem as bad considering the large amount of boilerplate that usually ends up in graphical applications.
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 aren't necessarily CPU bound), but often that is not the case and/or the app has trouble using all available CPU. On the upside, it's really great in that you can't corrupt Python's internal state and crash with threads, but that's a pretty minor upside. :)
The multiprocessing library is pretty nifty - at my current job we run a Python request handler process on each CPU core and use pipes to talk to a "controller" process (ends up being message inter-thread communication, so a lot like if you use ZMQ), but it's still a far cry from normal threads. And if you just need concurrency and aren't CPU bound, then gevent is pretty spectacular.
But despite all of this, I think Python's threading model is still one of the big design decisions that can make it a difficult choice in some environments - for our current system, we settled on Python despite this and decided that the cost of dealing with it is offset by the other benefits of Python, but it'd sure be notice to avoid that.
Long term, I'm keeping an eye on pypy+STM (http://doc.pypy.org/en/latest/stm.html) - it's nowhere near ready and may not ever be, but it's cool in that it's taking a radically different approach to the problem.
"...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!
Just cruising through this digital world at 33 1/3 rpm...
of course, the funny part here is that to the non-programmer, both of those snippets are identical.
True, Python multithreading is only useful to avoid locked windows or the like, it has no speed benefit. Multiprocess works much better but although it is usually more beneficial on Linux than windows; the overhead of the spawn is so egregious in Windows that you need to have processes lasting several seconds to make it worthwhile, not to mention the horrors of getting a multiprocess logging system to work. The real beauty of python is to allow complex structures to be treated by high level commands yet to perform the heavy lifting in C or Fortran using either python's multiprocessing or openmp via f2py.
"Our opponent is an alien starship packed with atomic bombs," I said. "we have a protractor"
#!/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
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, you can pass the code through GNU Indent or a similar tool to restore indentation.
What were you smoking? Really. Why? So bad.,
Comment removed based on user account deletion
Yeah, but last I checked pypy only handled python2, not python3. (They were either working on it, or planning to work on it, I don't remember which.)
Unfortunately, what I need isn't exactly speed, but binary mapping of structs (no pointers allowed) to disk blocks. So python is out. The GIL would make using it a headache anyway. (Again, not speed exactly, but simultaneous execution of different threads. Processes could be made to do in a pinch, so I could use multi-processing, but it would be a headache. ZMQ & C++ looks easier, even with the headaches that causes when handling unicode.)
I think we've pushed this "anyone can grow up to be president" thing too far.
I avoid Windows. This provides another reason why. Sometimes I forget Windows is even out there. Those are good times. :)
Not every desktop user has the money to buy a Mac and KVM switch to run your app. Nor does every desktop user have the money to buy extra RAM to run your app inside a Xubuntu virtual machine. Or perhaps you avoid developing desktop apps or offline-capable web apps.
inasmuch as I have to use Javascript in web pages to get that level of interactive capability, this is the way I choose to go about it -- write the parts that have to be Javascript in js, and the rest in Python.
But then how do you make JavaScript in the browser communicate with the Python program on the client? Or do you run Python solely on a server on the other side of the Internet from the client, which adds noticeable latency in many cases and destroys any possibility of offline use?
Apparently, but you don't seem to have any reason for your opinion. I'm torn between whether you're a particularly stupid chatbot, or an inept troll.
I think we've pushed this "anyone can grow up to be president" thing too far.
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.
I think we've pushed this "anyone can grow up to be president" thing too far.
Python's file management is actually seriously primitive, in fact it's almost identical to C - but with longer commands.
One of the big debates ongoing in the python development community right now is about that issue in fact. Notable parts include making pathlib support more integrated (pathlib - by not treating paths as strings is much better able ot deal with the nuances of OS requirements - but also unusable by most file management tools, even the ones in the standard library, without a cast), and about whether or not to create a string.write_to_file style mechanism as is found in many other more specialized languages.
Looks like the consensus was to not do the latter but to provide some equally simple approaches to file access, storage and safe pickling of data - but these are not yet in python.
It's kind of odd that you would make this claim in an area where, right now, the python mailing lists are busy debating how to improve the fact that python's file management is essentially identical to that of C.
Unicode killed the ASCII-art *
>The multiprocessing library is pretty nifty
Oh yes, I absolutely LOVE multiprocess.Pool.map ! It is, by far, the easiest parallel execution setup I've ever done.
Python itself seems to be seriously embracing concurrent processing, which is very powerful and very useful for a lot of jobs - though not the ones where parallelism really shines (or anything that's embarrassingly parallel) , the async/await model is a really clean and pythonic way to do powerful concurrent generators - it's still very new, but I think it will replace multithreading almost entirely. For everything MT does well, await/async can do it better and with less code, for the rest MP will generally work better.
Unicode killed the ASCII-art *
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.
So he's re-writing those in c++ then?
Comment removed based on user account deletion
Comment removed based on user account deletion
Not knowing much but openbsd has been burdened with the "one lock that rules them all" and it is painful to watch them getting rid of it. I expect Gido gets quite a bit of choice in where he works and solving that problem would be a job draw. Then Dropbox is supposed to be secure. That is generally an interesting problem. As best I know, python exploits are rare, whatever that means in a language, but I expect that is also true for the libraries.
Well I don't know about you, but I've never written a complete distributed fileserver that runs across thousands of VM instances and serves costumised webviews and APIs to thousands of clients worldwide. I've never written code that manages deduplication, which is quite a bugger to do because one slip and you could accidentally have people deleting each other's files. So I don't really know how many lines it would need in reality.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
Comment removed based on user account deletion
Comment removed based on user account deletion
The first release of pypy (well, technically pypy3) that supported Python 3 was over a year ago (February 2015). However it is still Python 3.2.5 (they're working on 3.3+ support).
Regarding the rest of your post, a common approach is to write the low-level access code in C and everything on top in Python. The C code can release the GIL (only need to reacquire it if calling back into the Python subsystem).
Have a look at cffi.