Slashdot Mirror
Interviews: Guido van Rossum Answers Your Questions
Last week you had a chance to ask Guido van Rossum, Python's BDFL (Benevolent Dictator For Life), about all things Python and his move to Dropbox. Guido wasted no time answering your questions and you'll find his responses below.
From Google to Dropbox
by nurhussein
Hi, What prompted the move from Google to Dropbox? What did you do at Google, and what are you going to do at Dropbox?
Guido: After seven years at Google I was just ready for some change in environment, and then the Dropbox offer came along. At a high level, my job hasn't changed much: I still
- spend 50% of my time on whatever I want to do for Python in my BDFL role
- am a regular engineer in the organization (not a manager or even TL)
- do a lot of code reviews, architecture and design work
- handle a lot of email
- do a lot of actual coding for my job, in Python
The specifics differ of course. I really did only two things at Google: the first two years I worked on one of the first online code review tools Mondrian, which itself was never open-sourced but begat Rietveld, which did, and is used amongst others, by the Python, Go and Chromium communities. After that I joined Google App Engine where I did a lot of different things, almost all of them in Python. My last big project there was a new Python database API, NDB.
I've been at Dropbox for 7 months and my main project has been the design of the Dropbox Datastore API . It's ironic but not my fault that this also uses the "datastore" moniker -- there's little overlap between Dropbox Datastores and the Google App Engine Datastore.
What's even more ironic is that even though I did much of the design, and wrote two prototypes in Python, the SDKs we released last month only support Java, Objective-C and JavaScript. But I am working on a fix, this interview is just slowing me down. :-)
Why did Python avoid some common "OO" idioms?
by i_ate_god
Interfaces, abstract classes, private members, etc... Why did python avoid all this?
Guido: I can think of two reasons: (a) you don't really need them, and (b) they are hard to do if you have no compile-time type checking. Python started out as a skunkworks project (not endorsed or encouraged by management but not actively prevented), and I wanted results quickly. This led me to remove features that weren't actually needed or urgent; it also led me to do all type checking at run time, which gave me natural constraints on what features Python could support. I also had no religious OO ax to grind -- I just wanted an easy language, and it became OO more or less by accident.
In modern Python there are rough equivalents for all of these, but they don't necessarily work all that well, or they cause a lot of execution overhead, so they are often avoided, but they have their uses and their fans.
functional programming
by ebno-10db
Some people claim that Python is, at least partly, a functional language. You disagree, as do I. Simply having a few map and filter type functions does not make for a functional language. As I understand it those functions were added to the libraries by a homesick Lisper, and that several times you've been tempted to eliminate them. In general it seems you're not a fan of functional programming, at least for Python.
Question: do you feel that the functional programming approach is not very useful in general, or simply that it's not appropriate for Python? It would be nice to hear your reasons either way.
Guido: I'm not a fan of religiously taking some idea to the extreme, and I try to be pragmatic in my design choices (but not *too* pragmatic, see the start of this sentence :-). I value readability and usefulness for real code. There are some places where map() and filter() make sense, and for other places Python has list comprehensions. I ended up hating reduce() because it was almost exclusively used (a) to implement sum(), or (b) to write unreadable code. So we added builtin sum() at the same time we demoted reduce() from a builtin to something in functools (which is a dumping ground for stuff I don't really care about :-).
If I think of functional programming, I mostly think of languages that have incredibly powerful compilers, like Haskell. For such a compiler, the functional paradigm is useful because it opens up a vast array of possible transformations, including parallelization. But Python's compiler has no idea what your code means, and that's useful too. So, mostly I don't think it makes much sense to try to add "functional" primitives to Python, because the reason those primitives work well in functional languages don't apply to Python, and they make the code pretty unreadable for people who aren't used to functional languages (which means most programmers).
I also don't think that the current crop of functional languages is ready for mainstream. Admittedly I don't know much about the field besides Haskell, but any language *less* popular than Haskell surely has very little practical value, and I haven't heard of functional languages *more* popular than Haskell. As for Haskell, I think it's a great proving ground for all sorts of ideas about compiler technology, but I think its "purity" will always remain in the way of adoption. Having to come to grips with Monads just isn't worth it for most people.
(A similar comment applies to Scala. It may be the best you can do trying to combine functional and OO paradigms in one language, but the result isn't all that easy to use unless you're really smart.)
Multi-line lambdas
by NeverWorker1
One of the most common complaints about Python is the limitations of its lambdas, namely being one line only without the ability to do assignments. Obviously, Python's whitespace treatment is a major part of that (and, IIRC, I've read comments from you to that effect). I've spent quite a bit of time thinking about possible syntax for a multi-line lambda, and the best I've come up with is trying to shoehorn some unused (or little used) symbol into a C-style curly brace, but that's messy at best. Is there a better way, and do you see this functionality ever being added?
Guido: Really? I almost never hear that complaint except from people who submit questions to Slashdot interviews. :-)
There is indeed a better way, and that is using the 'def' keyword to define a regular function in a local scope. The defined function object becomes a local variable that has exactly the same semantics as a lambda except that it is bound to a local variable, and it doesn't have any of the syntactic constraints. For example, there is *no* semantic difference between
def make_adder(n):
__def adder(x):
____return x + n
__return adder
and this equivalent using lambda:
def make_adder(n):
__return lambda x: x + n
(except that when you introspect the lambda asking for its name, it will say '' instead of 'adder').
Andrew Koenig once pointed out to me that there's one pattern where lambdas are really much more convenient, and that is if you have a long list or dict (perhaps some kind of switching definition) containing lots of lambdas, since if you wanted to do that without lambda you'd end up first having to define lots of little functions, giving them all names, and then referencing them all by name from inside the list or dict. But in that pattern the lambdas are usually simple enough to be lambdas, and if you have a few exceptions, using 'def' before starting the list or dict is a fine compromise.
PyPy
by Btrot69
Do you see PyPy as the future? Or do you remain unconvinced, and -- if so -- why ?
Guido: I'm still unconvinced, for two reasons: (a) they don't support Python 3 (well) yet, and (b) there are lots of extension modules (both third party and in the standard library) that they don't support well. But I hope they'll fix those issues. I think it's competition from projects like PyPy, Jython and IronPython that keeps the CPython project honest and on its toes.
Python in the browser ?
by Btrot69
Over the years, there have been several attempts to create a sandboxed version of python that will safely run in a web browser.Mostly this was because of problems with Javascript. Now that Javascript works -- and we have nice things like CoffeeScript -- is it time to give up on python in the browser ?
Guido: I gave up on it in 1995, so yes. And please don't try to compile Python to JavaScript. The semantics are so different that you end up writing most of a Python runtime in JavaScript, which slows things down too much. (CoffeScript's strength is that it is designed to map cleanly to JavaScript, and the two are now co-evolving to make the mapping even cleaner.)
Python 3
by MetalliQaZ
How do you feel about the current state of the migration to Python 3 (Py3k)? From a user perspective it seems that the conversion of popular libraries has lagged far behind, which has impeded the transition. In my professional capacity, nearly every single system I use lacks an installed 3.x interpreter. In fact, 2.7 is a rarity. I'd like to get your thoughts.
Guido: Curious where you work. I agree that Python 3 migration will still take a long time, but if your systems don't come with Python 2.7 they must be pretty ancient! When I left Google they were about done with the internal transition to Python 2.7 (having successfully migrated from 2.4 to 2.6 over the past few years) and here at Dropbox both the client and the server are using Python 2.7. Both companies are already thinking about Python 3 too.
Back to Python 3 migration, I am actually pretty optimistic. Lots of popular libraries have a working port or are working on one. (The Python Software Foundation also occasionally funds projects to port libraries that are widely used but don't have enough of a community to do a port.) It will take a long time, but I see a lot of progress, and in a few years I expect most new code will be written in Python 3. Totally eradicating Python 2 usage will probably take much longer, but then again, Windows XP isn't quite dead yet either. :-)
Key question for any language designer
by dkleinsc
Have the prospects of Python in any way improved since you grew a beard? To what degree does language success correlate to beard length?
Guido: It is absolutely essential. Just look at Perl's fate -- Larry Wall is just too clean-shaven. :-)
by nurhussein
Hi, What prompted the move from Google to Dropbox? What did you do at Google, and what are you going to do at Dropbox?
Guido: After seven years at Google I was just ready for some change in environment, and then the Dropbox offer came along. At a high level, my job hasn't changed much: I still
- spend 50% of my time on whatever I want to do for Python in my BDFL role
- am a regular engineer in the organization (not a manager or even TL)
- do a lot of code reviews, architecture and design work
- handle a lot of email
- do a lot of actual coding for my job, in Python
The specifics differ of course. I really did only two things at Google: the first two years I worked on one of the first online code review tools Mondrian, which itself was never open-sourced but begat Rietveld, which did, and is used amongst others, by the Python, Go and Chromium communities. After that I joined Google App Engine where I did a lot of different things, almost all of them in Python. My last big project there was a new Python database API, NDB.
I've been at Dropbox for 7 months and my main project has been the design of the Dropbox Datastore API . It's ironic but not my fault that this also uses the "datastore" moniker -- there's little overlap between Dropbox Datastores and the Google App Engine Datastore.
What's even more ironic is that even though I did much of the design, and wrote two prototypes in Python, the SDKs we released last month only support Java, Objective-C and JavaScript. But I am working on a fix, this interview is just slowing me down. :-)
Why did Python avoid some common "OO" idioms?
by i_ate_god
Interfaces, abstract classes, private members, etc... Why did python avoid all this?
Guido: I can think of two reasons: (a) you don't really need them, and (b) they are hard to do if you have no compile-time type checking. Python started out as a skunkworks project (not endorsed or encouraged by management but not actively prevented), and I wanted results quickly. This led me to remove features that weren't actually needed or urgent; it also led me to do all type checking at run time, which gave me natural constraints on what features Python could support. I also had no religious OO ax to grind -- I just wanted an easy language, and it became OO more or less by accident.
In modern Python there are rough equivalents for all of these, but they don't necessarily work all that well, or they cause a lot of execution overhead, so they are often avoided, but they have their uses and their fans.
functional programming
by ebno-10db
Some people claim that Python is, at least partly, a functional language. You disagree, as do I. Simply having a few map and filter type functions does not make for a functional language. As I understand it those functions were added to the libraries by a homesick Lisper, and that several times you've been tempted to eliminate them. In general it seems you're not a fan of functional programming, at least for Python.
Question: do you feel that the functional programming approach is not very useful in general, or simply that it's not appropriate for Python? It would be nice to hear your reasons either way.
Guido: I'm not a fan of religiously taking some idea to the extreme, and I try to be pragmatic in my design choices (but not *too* pragmatic, see the start of this sentence :-). I value readability and usefulness for real code. There are some places where map() and filter() make sense, and for other places Python has list comprehensions. I ended up hating reduce() because it was almost exclusively used (a) to implement sum(), or (b) to write unreadable code. So we added builtin sum() at the same time we demoted reduce() from a builtin to something in functools (which is a dumping ground for stuff I don't really care about :-).
If I think of functional programming, I mostly think of languages that have incredibly powerful compilers, like Haskell. For such a compiler, the functional paradigm is useful because it opens up a vast array of possible transformations, including parallelization. But Python's compiler has no idea what your code means, and that's useful too. So, mostly I don't think it makes much sense to try to add "functional" primitives to Python, because the reason those primitives work well in functional languages don't apply to Python, and they make the code pretty unreadable for people who aren't used to functional languages (which means most programmers).
I also don't think that the current crop of functional languages is ready for mainstream. Admittedly I don't know much about the field besides Haskell, but any language *less* popular than Haskell surely has very little practical value, and I haven't heard of functional languages *more* popular than Haskell. As for Haskell, I think it's a great proving ground for all sorts of ideas about compiler technology, but I think its "purity" will always remain in the way of adoption. Having to come to grips with Monads just isn't worth it for most people.
(A similar comment applies to Scala. It may be the best you can do trying to combine functional and OO paradigms in one language, but the result isn't all that easy to use unless you're really smart.)
Multi-line lambdas
by NeverWorker1
One of the most common complaints about Python is the limitations of its lambdas, namely being one line only without the ability to do assignments. Obviously, Python's whitespace treatment is a major part of that (and, IIRC, I've read comments from you to that effect). I've spent quite a bit of time thinking about possible syntax for a multi-line lambda, and the best I've come up with is trying to shoehorn some unused (or little used) symbol into a C-style curly brace, but that's messy at best. Is there a better way, and do you see this functionality ever being added?
Guido: Really? I almost never hear that complaint except from people who submit questions to Slashdot interviews. :-)
There is indeed a better way, and that is using the 'def' keyword to define a regular function in a local scope. The defined function object becomes a local variable that has exactly the same semantics as a lambda except that it is bound to a local variable, and it doesn't have any of the syntactic constraints. For example, there is *no* semantic difference between
def make_adder(n):
__def adder(x):
____return x + n
__return adder
and this equivalent using lambda:
def make_adder(n):
__return lambda x: x + n
(except that when you introspect the lambda asking for its name, it will say '' instead of 'adder').
Andrew Koenig once pointed out to me that there's one pattern where lambdas are really much more convenient, and that is if you have a long list or dict (perhaps some kind of switching definition) containing lots of lambdas, since if you wanted to do that without lambda you'd end up first having to define lots of little functions, giving them all names, and then referencing them all by name from inside the list or dict. But in that pattern the lambdas are usually simple enough to be lambdas, and if you have a few exceptions, using 'def' before starting the list or dict is a fine compromise.
PyPy
by Btrot69
Do you see PyPy as the future? Or do you remain unconvinced, and -- if so -- why ?
Guido: I'm still unconvinced, for two reasons: (a) they don't support Python 3 (well) yet, and (b) there are lots of extension modules (both third party and in the standard library) that they don't support well. But I hope they'll fix those issues. I think it's competition from projects like PyPy, Jython and IronPython that keeps the CPython project honest and on its toes.
Python in the browser ?
by Btrot69
Over the years, there have been several attempts to create a sandboxed version of python that will safely run in a web browser.Mostly this was because of problems with Javascript. Now that Javascript works -- and we have nice things like CoffeeScript -- is it time to give up on python in the browser ?
Guido: I gave up on it in 1995, so yes. And please don't try to compile Python to JavaScript. The semantics are so different that you end up writing most of a Python runtime in JavaScript, which slows things down too much. (CoffeScript's strength is that it is designed to map cleanly to JavaScript, and the two are now co-evolving to make the mapping even cleaner.)
Python 3
by MetalliQaZ
How do you feel about the current state of the migration to Python 3 (Py3k)? From a user perspective it seems that the conversion of popular libraries has lagged far behind, which has impeded the transition. In my professional capacity, nearly every single system I use lacks an installed 3.x interpreter. In fact, 2.7 is a rarity. I'd like to get your thoughts.
Guido: Curious where you work. I agree that Python 3 migration will still take a long time, but if your systems don't come with Python 2.7 they must be pretty ancient! When I left Google they were about done with the internal transition to Python 2.7 (having successfully migrated from 2.4 to 2.6 over the past few years) and here at Dropbox both the client and the server are using Python 2.7. Both companies are already thinking about Python 3 too.
Back to Python 3 migration, I am actually pretty optimistic. Lots of popular libraries have a working port or are working on one. (The Python Software Foundation also occasionally funds projects to port libraries that are widely used but don't have enough of a community to do a port.) It will take a long time, but I see a lot of progress, and in a few years I expect most new code will be written in Python 3. Totally eradicating Python 2 usage will probably take much longer, but then again, Windows XP isn't quite dead yet either. :-)
Key question for any language designer
by dkleinsc
Have the prospects of Python in any way improved since you grew a beard? To what degree does language success correlate to beard length?
Guido: It is absolutely essential. Just look at Perl's fate -- Larry Wall is just too clean-shaven. :-)
Or maybe someone should consider such silliness when they make a new language.
Well, leaving aside the fact that neither of them will compile because of lack of whitespace. Editors, you might want to think about when use of the <pre> tag is appropriate.
I still wish the parrot project took off and combined with Perl. Just imagine the poor joy using Lambda's combined with Perl and white spaces? Sounds like a pure paradise.
http://saveie6.com/
There is this language called Lisp. Might have heard of it before.
Erlang, also.
I understand the kiddies are feeling the Clojure love these days as well (although I suppose that just ends up categorized as a Lisp subset)
C'mon Guido, you're smarter than this...
He did answer one question once and for all. The smiley closes the bracket.
https://xkcd.com/541/ All hail the BDFL
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
I know about all the religious arguments pro or against whitespace as syntax. Personally, I am a happy user of python and I actually like the forced indentation, YMMV. But please slashdot, why do you screw up the indentation when the inventor of a whitespace-as-syntax-language gives a code example? This will be too easy for anyone arguing against the use whitespace of syntax.
karma police: arrest this man, he talks in maths; he buzzes like a fridge, he's like a detuned radio. [radiohead]
What is not appropriate is for a language to rely on whitespace.
factor 966971: 966971
"Wasted not" is synonymous with "did not waste". It sounds pretentiously archaic, but it is correct. On the other hand, borking up the whitespace in a Python code sample? That ain't OK at all.
On the other hand, borking up the whitespace in a Python code sample? That ain't OK at all.
Which is borked with respect to the whitespace, the example or Python? Obviously both and I submit that the latter enables the former which is why it's a horrible language "feature." [ Flame me if you want Python fans, but you know in your hearts I'm right. :-) ] [ And, *that*, Randall (https://xkcd.com/541/) is how you terminate a parenthetical with an emoticon :-) ]
It must have been something you assimilated. . . .
I asked the Python 3 question and to answer Guido's question of me; I work at a large conglomerate that does a lot of defense contracting. In my area we deal with aerospace applications and so our linux systems are not Internet-facing. They are real-time systems that run simulations and data-acquisition. As you might expect, they only get upgraded when they really need it. We had a PDP-11 down in the lab until 2010.
I'm not sure why I mentioned my workplace other to demonstrate how distant Py3k can seem to be. My main concern was the apparent lack of 3.x support in the big libraries out there. PIL is a great example. Also PyPy. It seems to me that there are many users that will only upgrade when the 3rd party libraries require it.
"Here Lies Philip J. Fry, named for his uncle, to carry on his spirit"
Both, of course.
My point was that removing indents is never OK, with any language, since it makes the code unreadable. In this case, it also made the code uncompilable, but that's just a secondary offense.
borking up the whitespace in a Python code sample? That ain't OK at all.
It may have to do with a sloppy HTML conversion by Slashdot or something, but it is ironic.
P.S. I'm actually a fan of the Python/Haskell whitespace approach.
It's like the brace war.......it's silly because you should be able to handle braces at the end of a line, or on a new line. It's not like either one is very hard, so just do it.
Same with space. Personally I don't prefer it, but it's just syntax. There are a hundred other things that are more important about a programming language than block delineation.
"First they came for the slanderers and i said nothing."
But sure, just carry on 'dissing functional programming and alienate some more of your core users.
After that post, I seriously doubt you are a core user.....
"First they came for the slanderers and i said nothing."
With the broken indentation, would braces really have made it any easier to read? Barely.
Whether it was C code, bash, or Lisp, the editors should have used CODE blocks. That's the problem, not Python.
"Here Lies Philip J. Fry, named for his uncle, to carry on his spirit"
Did you read what he said? He wasn't dissing functional programming. His point was that FP features require powerful compilers. Python doesn't have that kind of compiler. Therefore the features don't have much use to Python.
By the way, I don't believe they made the print function to be intuitive. They made it because print had no reason to be a statement. Also who said that tuples are more important than arrays? Arrays are really a concept for lower-level languages. Tuples, lists, and dictionaries are higher-level concepts that might be implemented with arrays behind the scenes. Lists function similarly to how many people visualize arrays. The beauty of tuples is that they are immutable, which means that they never change and can be thought of as a single, meaningful package with its contents. In contrast, lists have to be thought of as containers that can contain unknown things that may change at any moment.
"Here Lies Philip J. Fry, named for his uncle, to carry on his spirit"
I find that copy and paste in Python is very easy to do in any editor that lets you block indent (most do). I've also seen lots of C++ and Java recently that have been cut & pasted with little regard to indentation which makes reading it misleading to say the least. I'm not saying that one syntax (with curly braces or without) is better than another, but curly braces are no panacea. I've uncovered a LOT of bugs in C++ caused by cut & paste with sloppy and wrong attempts to re-balance the braces. I've also found Python bugs caused by wrong indentations, often caused by letting an editor run wild with auto-indent -- you can do that in bracey languages so Python runs a little counter to that habit. Also for Python if sections of code at some indentation level get way too long, then there's probably a more readable way to break that code down.
I've been working on an Android project for the past couple years, using Python for test automation, C for the kernel and drivers of course, C and C++ for low-level Android OS stuff and native libraries, and Java for upper layers (internals and apps). Whitespace in the C-like languages is inconsistent across the board, sometimes even within a file. Tab widths and tab/space usage are different for each developer (and their "style periods"). We cannot enforce a corporate policy in whitespace because we get so much (99.9%) of the code from open source and other suppliers. But thanks to PEP 8, Python code from multiple sources all looks pretty much the same and you don't have to invest time customizing your editor to use one style for files from one subtree, change formatting on the fly, etc.
I should mention that where Python has Guido, The Linux kernel has Linus and his style guide. I find even local kernel module code is consistent style-wise. But outside of that, on my project anyway, it's a style free-for-all.
Someone should consider what a posting to slashdot would look like when they make a new language...?
Flamebait, but I'll bite.
The thing that got me interested in Python at the very beginning was its use of whitespace. So no, in my heart, I don't think you are right (I was a big fan of Occam). For me, it is clearly the way a programming language should be designed. I understand that it doesn't suit others; but, interestingly, that feature is one of the key (and overlooked) reasons why Python has become so prevalent.
There is clearly a (sufficiently) large subset of the programming community that strongly prefer whitespace scoping. And for those people, what are the other mainstream choices? Personally, I don't know of any (although, I'm sure that there are a few). And new language designers are less likely to follow Python's lead because of outspoken critics, like you.
Because of that, I believe that Python has a more loyal core group of supporters that are less likely to abandon it when the latest hotness comes out.
With a stronger base than most languages, Python is less likely to experience the dramatic momentum losses of more conventional languages. And it will continue to grow its community, as once-reluctant whitespace converts are picked up and other languages are less attractive to them, from then on.
Luckily, both of your opinions on whitespace were not, and are not, either significant or involved in Python's design.
And that's why you two don't have to be dead to me. :)
Plus, you can keep working with whatever it is that you DO like. Imagine that!
I've fallen off your lawn, and I can't get up.
How about being unable to create a 2D array without jumping through hoops (backwards, on fire, and without your pants)?
I've fallen off your lawn, and I can't get up.
This. Though I have to admit, I've often been tempted to insert meaningful whitespace in there.
Maybe someday when I submit to the temptation to play with https://github.com/mame/quine-relay
Yeah, I was going for funny but I guess no one got that.
I dislike whitespace having meaning, but was just trying to make a joke. As you noticed the idea was ridiculous, thus the joke.
Create a 2D array, like you would do in C? That's not pythonic. If you want C, then use C.
In Python you don't have to define memory before you can fill it with stuff. You plan your data structures and the interpreter manages memory. If you need default data then just go straight to writing the initializer function. Otherwise use higher level functions like append() or extend() while creating your data.
"Here Lies Philip J. Fry, named for his uncle, to carry on his spirit"
Interesting interview. Surely there were more important topics but if nothing else this interview was useful in that it taught me it's okay to use the parenthesis at the end of a smiley to serve double duty as the end of a parenthetical statement (kind of like this one :-). At least when your smiley is left in plain text, that is.
What makes the one line lambda worse is the fact that in Python, not everything is an expression. That one change would clean up so much bullshit in the language.
Or perhaps it makes the one-line lambda better...? As per Guido's own example, lambda's are essentially redundant, as you can achieve the same results with a locally-defined function. The one real difference is that certain things aren't permitted in a lambda, because they're not expressions... which makes a lambda an approximation of a true function, rather than a procedure (Python's "functions" are in reality "procedures")....
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
Default to whitespace == scope, fine. But give a #define or option to turn it off/go back to {} or BEGIN/END or whatever instead...
Arrays have no place in a high-level language. An array has no intrinsic meaning, and any externally imposed meaning is non-obvious. You're supposed to define an object that makes its meaning and function obvious. I've been developing some code that started in Javascript and was migrated to Python, and every step of the process involved unpicking my own hacked-together array/list datastructures, working out what the hell I'd been thinking of, then impose some order on the whole thing.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
Hmm. An array has no intrinsic meaning? It's a list. I mean if we're going to get deep, nothing has any intrinsic meaning, man, but I don't think that's what you're trying to say. Can you explain?
As a C developer, I often need to collect a list of things and then iterate over them in a very specific order—whether it's computing a rolling average or just storing a list of items in a table for display. Not to mention the image processing I do, which depends on 1D, 2D and 3D arrays.
I don't know... I'm scratching my head over here. What am I missing?
Let's start with the (obvious) statement that you don't use a high-level language for its efficiency -- as a C developer you's be appalled at how slow my Python program runs! You use arrays of various dimensionalities to represent cartesian cordinates, vectors, and transformation matrices, because it is a computationally cheaper than using custom datatypes.
The whole point of high-level languages is to abstract things out to make it easier for the designer to express their thoughts more easily, and to reduce the possibility of errors. High-level languages need to be far more semantically meaningful than something like C. If your vector in C is an array [x1,x2,x3] and your point is [x2,y2,z2], you might accidentally mix them up, because if your "type" is simply "array of int". Python wants you to use datatypes so that your vector is a vector and your coordinate is a coordinate, and even if they are internally identical, they're still recognised by the system as different
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
Fascinating. What libraries in particular do you like from Python? Serious question.
"First they came for the slanderers and i said nothing."
Oh, I think execution speed is overrated anyway. In terms of user interaction, 30ms is the same as 150ms: "fast." If you have to do some heavy lifting that will take multiple seconds to compute in Python, you can always dip into C for that section.
But yes, the ease of typecasting and assignment are double edged swords in C. They can save you a lot of time, but it's easy to cut yourself. That's why, like many C developers, I use typedefs and structs heavily, and avoid using arrays for data types. For example, I would never define a color as:
double rgb[3];
But rather:
typedef struct { double red; double green; double blue; } ColorTriplet;
Of course this doesn't prevent me from assigning someColor.red = somePoint.z, but hopefully if I didn't mean to do that, it's a little easier to catch than someColor[0] = somePoint[3];.
But I often need to store a small array of those colors or points, and the C array mechanism is very helpful. And needless to say, when iterating over an image, the pixel buffer is most naturally addressed as an array (for CPU-based processing, anyway).
by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
Correct and correct. Never do the compute-intensive stuff in native Python + compute-intensive stuff (eg image manipulation) needs arrays = Python doesn't need arrays.
Python's lists are a perfectly adequate replacement for a small 1-dimensional array when needed on an ad hoc basis.
Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
Lua is better than Python in every way.
it's trivial in python. It's an incredible hoop jump in perl.
I've fallen off your lawn, and I can't get up.
perl. Go ahead, show me a reasonable 2d (or more) array in perl, lol. I don't think you can do it.
in python, there's nothing to it, trivial to do and trivial to access. Not in perl, or at least, it hasn't been.
I've fallen off your lawn, and I can't get up.
yes, wasn't talking about python. Was talking about perl.
I've fallen off your lawn, and I can't get up.
So no, you can't create a whole program functionally, but if FP was incorporated effectively into multi-paradigm development, it would make simpler debugging no end. What do I mean by properly? FP should be a limited subsystem. No side-effects: no printing, no information, no condition changes or varying claims. This has to be an strong concept (with the possible exemption of debug info). Techniques can contact features, and features can contact other features, but features can't contact procedures. This has to be an strong concept, and I don't beleive most multi-paradigm 'languages' implement it. Why does it have to be unbreakable? Because the whole factor is to decrease debugging attempt. With real FP, bug monitoring is (relatively) easy: if the operate gives the incorrect response, there's a bug in it; if it gives the right response, there's no bug. But as soon as you allow condition changes and other adverse reactions, it's a process, not a operate, and a side-effect bug might only display itself further down the range (eg you unintentionally keep an A in the create shield and the next concept gets an invalid A at the start) and you're remaining on a looooong search. It's regrettable that program control in Python is such a blunder, mostly for traditional reasons. There's quite a bit of good items on PyPI these days, and if we were beginning over, I think we'd do better to restrict the conventional collection to a small set of important fundamentals, and to advertise the best collections from outside resources via the conventional program database and resources. I do a reasonable bit of development in Python and curly-bracket 'languages' (C, C++, JavaScript, PHP, etc.) and remarkably, a forgotten/misplaced wavy segment in any of those various curly-bracket 'languages' seem to crack my rule greatly more often than indent problems do. | Cheap Umrah Packages | Cheap flights To Harare
I did learn something new, I learned Python..and for the most part, I like it.. It's more readable (as in sourcecode, not as in indentation) than Perl.
It's mostly the indent==scope that's so annoying. There's a couple of other things, like seemingly unnecessary colons in a few places, but those are VERY VERY minor compared to the huge issue that is indentation == scope.
But I still use Python. Can't you see that liking something, despite greatly disliking one of its huge distinguishing features, is actually a positive for Python?