User: Password:
|
|
Subscribe / Log in / New account

PyCon: Evangelizing Python

Did you know...?

LWN.net is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net.

By Jake Edge
March 27, 2013

Python core developer Raymond Hettinger's PyCon 2013 keynote had elements of a revival meeting sermon, but it was also meant to spread the "religion" well beyond those inside the meeting tent. Hettinger specifically tasked attendees to use his "What makes Python awesome?" talk as a sales tool with management and other Python skeptics. While he may have used the word "awesome" a few too many times in the talk, Hettinger is clearly an excellent advocate of the language from a technical—not just cheerleading—perspective.

He started the talk by noting that he teaches "Python 140 characters at a time" on Twitter (@raymondh). He has been a core developer for twelve years, working on builtins, the standard library, and a few core language features. For the last year and a half, Hettinger has had a chance to "teach a lot of people Python". Teaching has given him a perspective on what is good and bad in Python.

Context for success

Python has a "context for success", he said, starting with its license. He and many others would never have heard of Python if it were not available under an open source license. It is also important for a "serious language" to have commercial distributions and the support that comes with those.

Python also has a "Zen", he said, which is also true of some other languages, like Ruby, but "C++ does not have Zen". Community is another area where Python excels. "C is a wonderful language", but it doesn't have a community, Hettinger said.

The PyPI repository for Python modules and packages is another important piece of the puzzle. Python also has a "killer app", in fact it has more than one. Zope, Django, and pandas are all killer apps, he said.

Windows support is another important attribute of Python. While many in the audience may be "Linux weenies" and look down on Windows users, most of the computers in the world are running Windows, so it is important for Python to run there too, he said. There are lots of Python books available, unlike some other languages. Hettinger is interested in Go, but there aren't many books on that language.

All of these attributes make up a context for success, and any language that has them is poised to succeed. But, he asked, why is he talking about the good points of Python at PyCon, where everyone there is likely to already know much of what he is saying? It is because attendees will often be in a position to recommend or defend Python. Hettinger's goal is for attendees to be able to articulate what is special about the language.

High-level qualities

The Python language itself has certain qualities that make it special, he said, starting with "ease of learning". He noted that David Beazley runs classes where students are able to write "amazing code" by the end of the second day. One of the exercises in those classes is to write a web log summarizing tool, which shows how quickly non-programmers can learn Python.

Python allows for a rapid development cycle as well. Hettinger used to work at a high-frequency trading company that could come up with a trading strategy in the morning and be using it by the afternoon because of Python. Though he was a good Java programmer, he could never get that kind of rapid turnaround using Java.

Readability and beauty in a language is important, he said, because it means that programmers will want to program in the language. Python programmers will write code on evenings and weekends, but "I never code C++ on the weekend" because it is "not fun, not beautiful". Python is both, he said.

The "batteries included" philosophy of Python, where the standard library is part of the language, is another important quality. Finally, one of Hettinger's favorite Python qualities is the protocols that it defines, such as the database and WSGI protocols. The database protocol means that you can swap out the underlying database system, switching to or from MySQL, Oracle, or PostgreSQL without changing the code to access the database. Once you know how to access one of them through Python, you know how to access them all.

As an example of the expressiveness and development speed of the language, Hettinger put up a slide with a short program. In a class he was teaching, someone asked how he would deduplicate a disk full of photos, and in five minutes he was able to come up with a fifteen-line program to do so. It is a real testament to the language that he could write that program live in class, but even more importantly, he can teach others to do the same. That one slide shows "a killer feature of the language: its productivity, and its beauty and brevity", he said.

But, there is a problem with that example. A similar slide could be created for Ruby or Perl, with roughly the same brevity. That would be evidence for the "all scripting languages are basically the same, just with different syntax" argument that he hears frequently from software executives. But all scripting languages are not the same, he said. That may have been true in 2000, but "we've grown since then"; there are lots of features that separate Python from the pack.

Winning language features

First up on Hettinger's list of "winning language features" is the required indentation of the language. It was an "audacious move" to make that choice for the language, but it contributes to the "clean, uncluttered" appearance of the code. He claimed that Python was the first to use indentation that way, though he later received a "Miranda warning" from an audience member as the Miranda language uses indentation and predates Python. People new to the language sometimes react negatively to the forced indentation, but it is a net positive. He showed some standard examples of where C programs can go wrong because the indentation doesn't actually match the control flow, which is impossible with Python. Python "never lies with its visual appearance", which is a winning feature, he said.

The iterator protocol is one of his favorite parts of the language. It is a "design pattern" that can be replicated in languages like Java and C++, but it is "effortless to use" in Python. The yield statement can create iterators everywhere. Because iterators are so deeply wired into the language, they can be used somewhat like Unix pipes. So the shell construct:

    cat filename | sort | uniq
can be expressed similarly in Python as:
    sorted(set(open(filename)))
This shows how iterators can be used as composable filters. In addition, Python has a level of expressiveness that is similar to SQL, so:
    sum(shares*price for symbol, shares, price in port)
will sum the number of shares times the price for all of the entries in port, which is much like the SQL equivalent:
    SELECT SUM(shares*price) FROM port;
Languages that don't have for loops that are as powerful as Python's cannot really compete, he said.

One of his favorite things to teach about Python are list comprehensions. The idea came from mathematical set building notation. They "profoundly improve the expressiveness of Python", Hettinger said. While list comprehensions might at first appear to violate the "don't put too much on one line" advice given to new programmers, it is actually a way to build up a higher-level view. The examples he gave can fairly easily be expressed as natural language sentences:

    [line.lower() for line in open(filename) if 'INFO' in line]
which creates a list of lower-cased lines that contain "INFO". The second seems directly derived from math notation:
    sum([x**3 for x in range(10000)])
which sums a list of the cubes of the first 10,000 integers (starting at zero). Since list comprehensions can generally be expressed as single sentences, it is reasonable to write them that way in Python.

The generators feature is a "masterpiece" that was stolen from the Icon language. Now that Python has generators, other languages are adding them as well. Generators allow Python functions to "freeze their execution" at a particular point and to resume execution later. Using generators makes both iterators and coroutines easier to implement in a "clean, readable, beautiful" form. Doing things that way is something that Python has "that others don't". His simple example showed some of the power of the feature:

    def pager(lines, pagelen=60):
        for lineno, line in enumerate(lines):
            yield line
            if lineno % pagelen == 0:
                yield FORMFEED

Generator expressions come from Hettinger's idea of combining generators and list comprehensions. Rather than requiring the creation of a list, generators can be used in expressions directly:

    sum(x**3 for x in range(10000))
From that idea, dictionary and set comprehensions are obvious extensions, he said. Generator expressions are one way to combat performance problems in Python code because they have a small memory footprint and are thus cache friendlier, he said.

But generators have a problem: they are a "bad date". Like a date that can only talk about themselves, generators can only talk, not listen. That led to the idea of two-way generators. Now generators can accept inputs in the form of send(), throw(), and close() methods. It is a feature that is unique to Python, he said, and is useful for implementing coroutines. It also helps "tame" some of the constructs in Twisted.

Decorators have an interesting history in Python. They don't really add new functionality that can't be done other ways, so the first few times they were proposed, they were turned down. But they kept being proposed, so Guido van Rossum (Python's benevolent dictator for life) used a tried and true strategy to make the problem go away: he said that if everyone could agree on a syntax for decorators, he would consider adding them. For the first time ever, the entire community came together and agreed on a syntax. It presented that agreement to Van Rossum, who agreed: "you shall have decorators, but not the syntax you asked for".

In retrospect, the resistance to decorators (from Van Rossum and other core developers) was wrong, Hettinger said, as they have turned out to be a "profound improvement to the language". He pointed to the lightweight web frameworks (naming itty, Flask, and CherryPy) as examples of how decorators can be used to create simple web applications. His one slide example of an itty-based web service uses decorators for routing. Each new service is usually a matter of adding three lines or so:

    @get('/freespace')
    def compute_free_disk_space(request):
        return subprocess.check_output('df')
The code above creates a page at /freespace that runs df and returns its output as a web page.

"Who's digging Python now?", he asked with a big grin, as he did in spots throughout the talk—to much applause. The features he had mentioned are reasons to pick Python over languages like Ruby, he said. While back in 2000, Python may have been the equivalent of other scripting languages, that has clearly changed.

There are even more features that make Python compelling, such as the with statement. Hettinger thinks that "context managers" using with may turn out to be as important to programming as was the invention of the subroutine. The with statement is a tool for making code "clean and beautiful" by setting up a temporary context where the entry and exit conditions can be ensured (e.g. files closed or locks unlocked) without sprinkling try/finally blocks all over. Other languages have a with, but they are not at all the same as Python's. The best uses for it have not yet been discovered, he said, and suggested that audience members "prove to the world that they are awesome", so that other languages get them.

The last winning feature that he mentioned was one that he initially didn't want to be added: abstract base classes. Van Rossum had done six months of programming in Java and "came back" with abstract base classes. Hettinger has come to embrace them. Abstract base classes help clarify what a sequence or a mapping actually is by defining the interfaces used by those types. They are also useful for mixing in different classes to better organize programs and modules.

There is something odd that comes with abstract base classes, though. Python uses "duck typing", which means that using isinstance() is frowned upon. In fact, novice Python programmers spend their first six months adding isinstance() calls, he said, and then spend the next six months taking them back out.

With abstract base classes, there is an addition to the usual "looks like a duck, walks like a duck, quacks like a duck" test because isinstance() can lie. That leads to code that uses: "well, it said it was a duck, and that's good enough for me", he said with a laugh. He thought this was "incredibly weird", but it turns out there are some good use cases for the feature. He showed an example of using the collections.Set abstract base class to create a complete list-based set just by implementing a few basic operations. All of the normal set operations (subset and superset tests, set equality, etc.) are simply inherited from the base class.

Hettinger wrapped up his keynote with a request: "Please take this presentation and go be me". He suggested that attendees present it to explain what Python has that other languages are missing, thus why Python should be chosen over a language like Ruby. He also had "one more thing" to note: the Python community has a lot of both "established superstars" as well as "rising young superstars". Other languages have "one or two stars", he said, but Python has many; just one more thing that Python has that other languages don't.


(Log in to post comments)

PyCon: Evangelizing Python

Posted Mar 27, 2013 19:03 UTC (Wed) by kjp (subscriber, #39639) [Link]

As much as I love python I have to disagree about one item in that list: the DB-API. It has 5(!) different parameter quoting methods that drivers may use, and it uses an insane default (a select statement starts a transaction instead of being in autocommit, and that has unfortunately also infected sqlalchemy). That last part [unintended long transactions] can wreak havoc on a MVCC database.

Exceptions are also great (cough cough GO), and the exception hierarchy in 3.x looks really good, although I haven't used 3.x yet. The async io and coroutines planned for 3.4 (yield from) also look really nice.

Also: never use import *, use pyflakes, be intentional about choosing function and module names so you can grep for them later, and life should be good :-)

DB-API

Posted Mar 28, 2013 16:07 UTC (Thu) by smurf (subscriber, #17840) [Link]

I have to second your gripe about the DB-API. It's fundamentally non-Pythonic in other way, too: I would like to write

    import Db
    db = Db.connect(whatever)

    for x,y in db.select("select x,y from foo where bar=${baz}", baz=123):
        do_something(x,y)

In fact I wonder how many people, besides me ( see sqlmix on github ) wrote their own wrapper for the stuff?

Zen?

Posted Mar 28, 2013 7:12 UTC (Thu) by ncm (subscriber, #165) [Link]

"C++ does not have Zen"

Every concentrated activity has Zen. To perceive the Zen of C++ requires great clarity of mind, perhaps greater than many can achieve. Fortunately there is important work for persons at every level of enlightenment to do.

PyCon: Evangelizing Python

Posted Mar 28, 2013 7:53 UTC (Thu) by eru (subscriber, #2753) [Link]

"C is a wonderful language", but it doesn't have a community,

Maybe because it no longer needs a community, any more than the hammer or the screwdriver needs a community...

But I recall back when I was first learning C, there was a C community around magazines like The C User's Journal and Dr. Dobbs Journal. Later I learned a lot in the comp.std.c and comp.lang.c USENET newsgroups.

PyCon: Evangelizing Python

Posted Mar 28, 2013 15:43 UTC (Thu) by ortalo (subscriber, #4654) [Link]

Secure C Coding still has/needs a community IMHO (and certainly is not yet as straightforward as the hammer or the screwdriver...), e.g. look around CERT/CC.
Such things are far from finished.

PyCon: Evangelizing Python

Posted Mar 29, 2013 12:19 UTC (Fri) by renox (subscriber, #23785) [Link]

> "C is a wonderful language", but it doesn't have a community,

PC much?
C is probably the language I know the best, but I totally disagree that C is a wonderful language, it's a language which doesn't know whether it is should be a portable assembly language or a high level language, so it fails at both.

PyCon: Evangelizing Python

Posted Apr 5, 2013 13:15 UTC (Fri) by XTF (guest, #83255) [Link]

So what language does Python use for it's implementation? C++?

PyCon: Evangelizing Python

Posted Apr 5, 2013 13:25 UTC (Fri) by renox (subscriber, #23785) [Link]

CPython is written in C, C is often the best tool to use because of many reasons (availability of compilers/of developers, performance, etc), but this doesn't make it a "wonderful" language..
Unless by "wonderful" you mean "full of undefined behaviours just waiting to hurt the developers" ( http://blog.regehr.org/archives/category/compilers ) in which case I agree.

PyCon: Evangelizing Python

Posted Apr 5, 2013 13:49 UTC (Fri) by XTF (guest, #83255) [Link]

I didn't mention wonderful at all. Just wanted to state that apparently C is still the best choice in certain cases.

PyCon: Evangelizing Python

Posted Apr 5, 2013 19:47 UTC (Fri) by andrel (guest, #5166) [Link]

Pypy is written in Python. More precisely a restricted subset of Python called RPython.

PyCon: Evangelizing Python

Posted Mar 28, 2013 9:58 UTC (Thu) by jezuch (subscriber, #52988) [Link]

I'm not a Python programmer (Pythonista?) but I *adore* yield :) I've written my share of implementations of Java's Iterator interface so I can truly appreciate it's tremendous usefulness (which I don't have in Java).

Also, generators etc. are quite clearly an influence of functional languages that I'd like to see more of in the so-called mainstream languages.

PyCon: Evangelizing Python

Posted Mar 28, 2013 12:45 UTC (Thu) by fsateler (subscriber, #65497) [Link]

C# has all of that. It also has Linq, which makes processing sequences (or anything that can be represented as a sequence) fairly easy, in an SQL-like language.

PyCon: Evangelizing Python

Posted Mar 29, 2013 8:10 UTC (Fri) by marcH (subscriber, #57642) [Link]

C# and .NET are praised by many programming rock starts, so they probably rock, too. Too bad they come from the wrong place:

http://www.codinghorror.com/blog/2013/03/why-ruby.html

PyCon: Evangelizing Python

Posted Mar 28, 2013 11:54 UTC (Thu) by marcH (subscriber, #57642) [Link]

> Readability and beauty in a language is important, he said, because it means that programmers will want to program in the language. Python programmers will write code on evenings and weekends, but "I never code C++ on the weekend" because it is "not fun, not beautiful".

That's an incredibly weak promotion of readability that would be instantly dismissed by many managers.

Readability is critical because it helps maintain code faster, and with less bugs. => $$$$$ !

And as everyone here knows "Programmers are constantly in maintenance mode" ( http://pragmatictips.com/11 )

PyCon: Evangelizing Python

Posted Mar 28, 2013 13:28 UTC (Thu) by dpquigl (guest, #52852) [Link]

I find this comment about not writing C++ on the weekend because it is "not fun, not beautiful" to be completely ridiculous. I know it isn't yours but it just seems completely outlandish to me. I have the misfortune of having to use python at work sometime and I find it horrible on so many levels. When I go home and code on the weekend the last thing I'd want to do is use python. I go home and code C or code in some other high level strongly typed language.

I personally find python much harder to read than any other language that I've ever used and I include prolog in this statement too. The lack of any type of type information in the language makes it so you hope someone names variables the right way so you have some semblance of how to use it. The do whatever and clean up the mess mentality of python is horrible too. No need to make sure that variable is actually a string. Just treat it as one and if it isn't catch some random exception and move on or let it blow up. Of course you won't know it blows up until after you're 500 lines into your script. Or worse you have a long running python process that hits a section of code after days of running and it blows up in there and you have to figure out wtf went wrong.

PyCon: Evangelizing Python

Posted Mar 28, 2013 13:47 UTC (Thu) by tnoo (subscriber, #20427) [Link]

> Or worse you have a long running python process that hits a section of code after days of running and it blows up in there and you have to figure out wtf went wrong.

Which never happened to me with C or C++... oh wait, segmentation faults, wrong dynamic casts,..

PyCon: Evangelizing Python

Posted Mar 29, 2013 8:31 UTC (Fri) by marcH (subscriber, #57642) [Link]

> Which never happened to me with C or C++... oh wait, segmentation faults, wrong dynamic casts,..

Comparing Python with C/C++ cannot go very far. They are at two completely different levels; completely different tools for different jobs.

It'd more interesting to know which _other_ high-level languages dpquigl is using on the WE.

PyCon: Evangelizing Python

Posted Mar 29, 2013 14:01 UTC (Fri) by dpquigl (guest, #52852) [Link]

By trade I'm a Kernel/Systems Programmer so most of my work is done in C. However before I fell into that I was determined to be a game developer so I've written a lot of application code in many high level languages. I've developed game engines in C,C++,Java, and C# using opengl, directX, XNA and even did a stint working on an Unreal 3 engine based game before I had to quit due to conflicting with my real job (it eventually got released when they decided to actually hire developers instead of making it a people work on it in their free time project).

Even though UE3 game logic is mostly written in Unreal Script the language itself was checked and some preliminary compilation was done before being cooked and packaged for deployment into the game. The most interesting feature that I found for unreal script was that classes had states and function overloading wasn't just on parameterization but also based on state. You could declare a function onFire in the default state but then also declare the same function in a state called currentlyFiring. Where onFire in the default state would start the gun firing and setup the animations and such calling onFire in the while firing state would endup being a noop for certain weapons to make sure that you couldn't fire during a reload. Alternative if your weapon was in the reloading state and you called onfire again certain weapons would cancel the reload like in the instance of a pump shotgun.

On top of that I've done enterprise work for Java and C# and have done web apps in both. I've been trying to learn ruby as well as python because even though I'm not a fan of weak typed scripting languages more and more is being written in it and standing still just means you get left behind.

One issue I have with python is that every time I've asked for the right way to do something the only thing I get from python advocates is that you're free to do it however you like. Except for the one time I did something which is apparently against the book in a language which from what I can tell is the free love movement of development. I needed to validate the types of data coming in from a json string and to do this I checked if the values I got back matched certain data types which apparently is a big no no in the world of python. Instead I'm supposed to use them as if they were those data types and wait for the world to explode when they aren't and pick up the pieces.

Another is that we see horribly written code which makes its way into the core of Linux systems being written in python. The initial code for all of the Xen services was written in python and it was a horrible mess and horrible to maintain. What did they do? They started transitioning it all into C system services. Python is great in that it makes programming accessible to people who never would have programmed to begin with. However python is also horrible for the same reason.

PyCon: Evangelizing Python

Posted Mar 29, 2013 14:06 UTC (Fri) by dpquigl (guest, #52852) [Link]

Forgot to add some iOS and Android development as well so tack on Objective-C and Java for that in there as well.

PyCon: Evangelizing Python

Posted Mar 30, 2013 3:57 UTC (Sat) by nevets (subscriber, #11875) [Link]

I totally agree with you. I had to work in that xen Python mess. It was horrible.

Another problem I have with Python is that if I don't use it for a while, I have to always get my Python book out and relearn it. I'm a C programmer and Python is just so foreign to me. I rather program in Perl.

Someone told me once that people who like to program in English prefer Python and those who prefer to program in math prefer Perl or C. I've also always had trouble reading pseudo code and preferred the actual code to look at.

PyCon: Evangelizing Python

Posted Mar 30, 2013 14:26 UTC (Sat) by intgr (subscriber, #39733) [Link]

> I needed to validate the types of data coming in from a json string and to do this I checked if the values I got back matched certain data types which apparently is a big no no in the world of python. Instead I'm supposed to use them as if they were those data types and wait for the world to explode when they aren't and pick up the pieces.

I believe there's a misunderstanding there. You shouldn't do type-checking of data passed in internal APIs; if your function accepts a string parameter, you don't check that it's string every time -- just assume that the caller got it right.

However, if you're decoding JSON received from untrusted sources, then that kind of type checking makes sense and is often required to prevent some kinds of security bugs.

Case in point with Python 2:

def check_age(data):
    d = json.loads(data)
    if d['age'] < 18:
        print "You must be 18 or older to continue."
    else:
        print "OK!"

>>> check_age('{"age": 13}')
You must be 18 or older to continue.

>>> check_age('{"age": "13"}')
OK!

This hole is fixed in Python 3, but in general there are still surprises you can run into if you allow arbitrary types from untrusted input.

PyCon: Evangelizing Python

Posted Mar 30, 2013 20:53 UTC (Sat) by tnoo (subscriber, #20427) [Link]

> This hole is fixed in Python 3,

Maybe I don't get it, but how should an undefined value d['age'] be compared to a number? The natural way is to compare int(d['age']) < 18. which won't give random behaviour. and which would be done in any sane language. Nice that it raises Type error in Python3.

PyCon: Evangelizing Python

Posted Mar 31, 2013 9:23 UTC (Sun) by marcH (subscriber, #57642) [Link]

> You shouldn't do type-checking of data passed in internal APIs; if your function accepts a string parameter, you don't check that it's string every time -- just assume that the caller got it right.

"internal" can mean internal to either: your host, your process, your jar, your file, your company, your department, your team,... where does the trust stop? The answer probably depends on the task at hand. There is no simple answer.

Searching for "Defensive Programming" should return a lot of simple - and extreme - answers. Make your own opinion somewhere in the middle...

PyCon: Evangelizing Python

Posted Mar 31, 2013 9:48 UTC (Sun) by dark (guest, #8483) [Link]

It's not really about trust. It's about embracing duck typing.

If you're parsing data from strings then by all means check that it's well-formed and that it's the kind of data you expect -- it's all under your control at that point.

If you're accepting a value from elsewhere, then it may make sense to do sanity checks on it, but those should be along the lines of "does it support the methods I expect to call on it", not "does it have the specific type I expect". The best example of this is file objects -- you really shouldn't enforce that it's a "file", you should let the caller pass in whatever file-like object is most convenient.

Most python code is simple enough that you can do those 'checks' just by calling the methods when you need them and getting an exception if they fail. But if you're about to insert such a received value into a complex system and you want to catch errors before they're deep in the stack then it may make sense to inspect the value a bit. Or just convert it -- calling int(value) or str(value) will throw exceptions right away, and the latter will let the value handle its own conversion.

PyCon: Evangelizing Python

Posted Mar 28, 2013 22:05 UTC (Thu) by ibukanov (subscriber, #3942) [Link]

Wasn't it C that got Quiet NaN first that made it very hard to debug numerical programs? Python duck typing is a child play compared with that...

PyCon: Evangelizing Python

Posted Apr 5, 2013 13:27 UTC (Fri) by XTF (guest, #83255) [Link]

[quote] Or worse you have a long running python process that hits a section of code after days of running and it blows up in there and you have to figure out wtf went wrong.[/quote]
In that case you've probably chosen the wrong tool for the job.

PyCon: Evangelizing Python

Posted Apr 5, 2013 18:41 UTC (Fri) by HelloWorld (guest, #56129) [Link]

Oh, so Python is worse to read than Prolog because it's dynamically typed? Yeah, that makes sense. Oh wait, it doesn't: Prolog is also dynamically typed!

By the way: C is neither high-level nor strongly-typed. Sometimes it's better to remain silent, you know...

PyCon: Evangelizing Python

Posted Apr 17, 2013 21:56 UTC (Wed) by dpquigl (guest, #52852) [Link]

By the way you should learn proper reading comprehension before opening your mouth. I did not say that C is high-level nor strongly-typed. What I said was.

"I go home and code C or code in some other high level strongly typed language.".

That sentence does not mean that C is a strongly typed high level language.

PyCon: Evangelizing Python

Posted Apr 17, 2013 23:48 UTC (Wed) by raven667 (subscriber, #5198) [Link]

Sorry to be a language nit-picker but "some other" in this context is often interpreted to mean another of the same kind or something similar, implying that you think C is a strongly typed high level language.

PyCon: Evangelizing Python

Posted Apr 17, 2013 23:51 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

I think referring to "strongly typed" as if it is a binary thing instead of a continuum is a mistake either way.

PyCon: Evangelizing Python

Posted Apr 18, 2013 16:03 UTC (Thu) by dpquigl (guest, #52852) [Link]

I agree but the context of the larger discussion was that people don't code C++ on the weekend. C++ is what I was referencing with some other strongly typed high level language and was the language I originally addressed. If you take the one sentence out of the context of the paragraph then yes you are correct. Taken within context of the entire paragraph it should have been clear that I was talking about C++.

PyCon: Evangelizing Python

Posted Mar 28, 2013 12:58 UTC (Thu) by mpr22 (subscriber, #60784) [Link]

*sigh* Beauty is subjective, Mr Hettinger. Please do not mistake your opinion of the beauty of languages for fact - or, if you don't so mistake it, please don't speak in a manner liable to convey the impression that you do.

PyCon: Evangelizing Python

Posted Mar 29, 2013 8:51 UTC (Fri) by marcH (subscriber, #57642) [Link]

> *sigh* Beauty is subjective, Mr Hettinger.

Mr Hettinger was not expressing his personal opinion. He was much bolder than that. The sentence "it's a beautiful" is a commonly accepted language short-cut for "most people find it beautiful".

(I'm not interested in arguing either)

PyCon: Evangelizing Python

Posted Mar 28, 2013 14:50 UTC (Thu) by pspinler (subscriber, #2922) [Link]

My concern with python's indentation is that it sometimes presents practical difficulties to collaboration.

For example, I can't reliably count on being able to copy and paste code segments from my colleague's emails (especially email sent from outlook, bleah). I've even found this issue when attempting to read and reuse code published on some web pages.

otoh, for a language that uses syntax markers for flow of control, copied code will work as copied regardless of indentation, and auto-indentation tools will always correctly restore the code to a readable status.

-- Pat

PyCon: Evangelizing Python

Posted Mar 28, 2013 15:58 UTC (Thu) by mpr22 (subscriber, #60784) [Link]

My main practical annoyance with Python's use of indentation as the exclusive syntax for block structure is that it interferes with convenient use of the REPL for testing code snippets (since rectangle select is approximately never as convenient to use as linewise select). I also find the whole business of needing to care about indentation, when in a delimited-block language my text editor can do 100% of the caring-about-indentation for me, a positively retrograde step.

PyCon: Evangelizing Python

Posted Mar 28, 2013 18:24 UTC (Thu) by jwakely (subscriber, #60262) [Link]

I always thought I was the only person who had that problem using the Python REPL, I find it incredibly annoying but all the Python users around me never seem bothered by it.

PyCon: Evangelizing Python

Posted Mar 30, 2013 12:25 UTC (Sat) by thoeme (subscriber, #2871) [Link]

Puh! And I thought *I* was only one being put off by python's use of identation... It always reminds of my miserable time in university using some retarded pascal interpreter on the school's VAX system. I tried to learn Python, but stopped imedeately when I found out that first example would not work due to 2 <tab>s in a block identation. Stupid design choice.

PyCon: Evangelizing Python

Posted Mar 30, 2013 17:58 UTC (Sat) by jwakely (subscriber, #60262) [Link]

I have no problem at all with the indentation in a source file, but I wish the REPL was a bit smarter about handling the variations in whitespace that easily occur when selecting and pasting chunks of code.

PyCon: Evangelizing Python

Posted Mar 30, 2013 18:44 UTC (Sat) by smurf (subscriber, #17840) [Link]

Why should Python's indentation be a problem?

You use indentation in pretty much every other high-level programming language, otherwise you won't understand your code tomorrow.
The only difference is that Python uses the indents directly, while most other languages require redundant clutter like braces or BEGIN-END keywords to tell the compiler what to do.

Related to this, about everybody I know has written (or debugged) at least one piece of interesting C code like

   if (foo)
       if (bar)
            baz();
   else
       quux();
You simply don't get to make these mistakes in Python.

Interestingly, the idea of indentation as primary syntax seems to spread to other contexts.
Cf. CoffeeScript or HAML.

PyCon: Evangelizing Python

Posted Apr 5, 2013 4:16 UTC (Fri) by welinder (guest, #4699) [Link]

> You simply don't get to make these mistakes in Python.

That's actually wrong.

When a tab sneaks in you so get to make those mistakes and there is
nothing that visually tells you anything. Things line up neatly,
but don't actually work.

In C you don't get to make those mistakes. If it's important
then you can see it.

PyCon: Evangelizing Python

Posted Apr 5, 2013 6:19 UTC (Fri) by smurf (subscriber, #17840) [Link]

So set up your editor that your tabs actually do the same thing, visually, that Python thinks they do logically. Simple.
Or tell your editor to not use tabs at all. Again, simple.
Or tell your editor not to use spaces (i.e. ony Python indent == 1 tab) and make the tabs wide enough that you can't miss any misalignment.

The Python community has more-or-less agreed on the second option; personally I strongly prefer the third. But that's as much bikeshedding as whether a C open brace goes on the same line as the if statement, or below it (and if so, which indent does it get?)

This kind of mistake (mixing up tabs and spaces) is so easy to check for that Python actually has an option for it. Which C compiler checks for "wrong" indentation on nested statements?

PyCon: Evangelizing Python

Posted Apr 5, 2013 7:02 UTC (Fri) by dlang (subscriber, #313) [Link]

any language that requires me to have a specific configuration in my editor to use the language is not a reasonable choice.

If you are a full-time programmer who works in a nice, dedicated environment, you may end up with a nice tailored config.

But, like most sysadmins, I have to support software on all sorts of systems, many of which I haven't ever touched 5 minutes before I'm working on the code.

by the way, this is why I'm a vi person. every system has some variation of vi that I can run to get the job done. other editors, it's not the same thing.

PyCon: Evangelizing Python

Posted Apr 8, 2013 21:08 UTC (Mon) by wtanksleyjr (subscriber, #74601) [Link]

>any language that requires me to have a specific configuration in my editor to use the language is not a reasonable choice.

That's why I stopped trying to learn APL, by the way. So I do agree with your basic concern.

But it's really not accurate to say that Python requires an editor with a specific configuration. I have to edit Python with Notepad from time to time, and nothing breaks. It's simply a matter of comfort and caution to use an editor that won't make it easy to do things that screw up code -- but the language doesn't care.

So many times I have to edit code that a hardware engineer or a skilled, dedicated sysadmin (who isn't a double-classed programmer-sysadmin like I am) has previously modified. Very commonly I'll find random indentation (hardware engineers are the worst -- I recall cases where every newly added line of C was added flush left, no indentation at all, in the middle of properly indented code; and then no attempt was made to bring the result back upstream).

It's a minor thing to note that Python CAN be told to error out if the indentation is mixed in any way; by default it only errors out if the indentation is completely ambiguous, or if it contains spaces before tabs on the same line.

> But, like most sysadmins, I have to support software on all sorts of systems, many of which I haven't ever touched 5 minutes before I'm working on the code.

Same here. And I'll also say that Python is usually not the first choice of sysadmins -- Perl is usually much closer to a sysadmin's basic toolbox, and much much further away from a programmer's, while Python makes all the sysadmin tools take more typing to use.

> by the way, this is why I'm a vi person. every system has some variation of vi that I can run to get the job done. other editors, it's not the same thing.

Hahahaha. You work with SANE systems. Healthy systems. I work with systems where sometimes the only choice is vi, and sometimes the only choice is notepad.exe.

Anyhow, if you can't install your editor, you can't install a language. You're stuck with what you've got. In my case, I switch between bash, powershell, and cmd.exe. If I took your complaint seriously, I would have to hate using powershell and bash because they aren't available on all the platforms. Naw... Better to simply and silently resent the corporate choices that made the better choice unavailable.

We're stuck with the corporate tools we're given. (Pun intended but unindented.)

(BTW -- I'm a vi guy too, given the chance.)

-Wm

PyCon: Evangelizing Python

Posted Apr 5, 2013 8:42 UTC (Fri) by intgr (subscriber, #39733) [Link]

> there is nothing that visually tells you anything

Note that this is fixed in Python 3, it gives you a "TabError: inconsistent use of tabs and spaces in indentation"

Just watch and listen to him!

Posted Mar 28, 2013 16:13 UTC (Thu) by southey (subscriber, #9466) [Link]

Since LWN.net will not do so and the video has the vague title of Keynote, the video URL is
http://pyvideo.org/video/1669/keynote-3

PyCon: Evangelizing Python

Posted Mar 28, 2013 17:22 UTC (Thu) by wookey (subscriber, #5501) [Link]

People keep saying python is really easy and cool, but I still find it pretty hard work, and revert to bash or perl given half a chance. It is the language I recommend to newbies as it's popular and there are plenty of learning resources, but I can't bring myself to like it. It's not too bad to read, but writing it always seems like hard going. This is mostly lack of familiarity I guess, and probably its tendency to be 'objecty'. I've always found objectyness deeply mysterious. I think it's mostly being brought up on BASIC and C and bash (and ml, but I prefer to forget about that). It's just really hard to shift your brain into the new ways of thinking that fancy new languages promote. (I include C++ and java in the 'fancy new languages' category too).

PyCon: Evangelizing Python

Posted Mar 28, 2013 19:12 UTC (Thu) by serzan (subscriber, #8155) [Link]

That does sound like lack of familiarity. I've learned python a few years after shell and perl and I very much prefer it over the latter two.

Python itself does not enforce any specific paradigm (OO was only added afterwards) and its idea of OO is very relaxed compared to java/c++.

Also, I find that perl/shell are terrible for writing non-trivial scripts because handling exceptions requires so much more discipline than with python.

PyCon: Evangelizing Python

Posted Mar 29, 2013 13:25 UTC (Fri) by tnoo (subscriber, #20427) [Link]

> Python itself does not enforce any specific paradigm (OO was only added afterwards) and its idea of OO is very relaxed compared to java/c++.

OO was at the core of the language from the very beginning. The oldest documentation I found was version 1.4 (1996) which makes frequent references to Modula and C++.

But I agree that Python does not enforce any specific paradigm, or rather, effortlessly combines all of them. This is an asset, especially getting students to program data analysis scripts, which probably have never seen anything else than Basic or Matlab. The power of OO is still there, and can be easily used even in procedural programs.

PyCon: Evangelizing Python

Posted Mar 30, 2013 18:02 UTC (Sat) by jwakely (subscriber, #60262) [Link]

How does C++ force any OO paradigm on you?

PyCon: Evangelizing Python

Posted Mar 30, 2013 20:18 UTC (Sat) by serzan (subscriber, #8155) [Link]

I did not say that it does.

PyCon: Evangelizing Python

Posted Mar 28, 2013 18:49 UTC (Thu) by jschrod (subscriber, #1646) [Link]

Ah, the with statement. An innovative concept. Sigh.
Those who don't know Lisp are condemned to reinvent it.

And something like yield I've used in Barbara Liskov's CLU many decades ago. Good to see that it starts to arrive in mainstream languages, too.

PyCon: Evangelizing Python

Posted Mar 29, 2013 8:04 UTC (Fri) by marcH (subscriber, #57642) [Link]

> Those who don't know Lisp are condemned to reinvent it.

Or rather: those who know it will "steal with pride" what's good in it and leave the rest.

PyCon: Evangelizing Python

Posted Mar 29, 2013 10:47 UTC (Fri) by jschrod (subscriber, #1646) [Link]

If they would steal with pride, PEP 343 would mention Lisp somewhere. It doesn't. The talk doesn't mention it either. Doesn't look like much pride to me.

It doesn't mention the source of yield either, and even attributes it to Icon. (yield is called suspend there. And Ralph Griswold clearly knew the work of Barbara Liskov, made 3 years earlier, and published in relevant ACM SIG journals.) Even the ultra-short Wikipedia page of CLU acknowledges who came up with yield first - Barbara Liskov, the brilliant scientist who formulated the concept of abstract data types, exceptions, iterators, and many other things first.

PyCon: Evangelizing Python

Posted Mar 29, 2013 13:03 UTC (Fri) by marcH (subscriber, #57642) [Link]

LISP was considered in the discussions:

http://mail.python.org/pipermail/python-dev/2005-May/0537...
http://starship.python.net/crew/mwh/pep310/8.txt

Looks like C++' RAII was more influential though and much closer to the final feature.

You don't really think any serious language designer group reinvents the wheel without looking at other languages, do you?

PyCon: Evangelizing Python

Posted Mar 29, 2013 13:56 UTC (Fri) by jschrod (subscriber, #1646) [Link]

> You don't really think any serious language designer group reinvents the
> wheel without looking at other languages, do you?

Well, no (designers), partly (documentation and review) and yes (evangelists).

In my experience, actual language designers know about the concepts. Then it's documented, and the influences are not part of the rationales, though they should be (witness the cited PEP). Then evangelists (witness the talk from the article) come and present 30+ year old stuff as innovative concepts that's the best thing since sliced bread. Reading the article, I couldn't refrain from commenting - you seem to take that much more as an attack as it's meant to.

My comments are not meant specific for Python, you could also look at Javascript with its obvious roots in Self (which pioneered prototype-instance based OOPL) mentioned in almost no documentation.

PyCon: Evangelizing Python

Posted Mar 29, 2013 18:04 UTC (Fri) by marcH (subscriber, #57642) [Link]

> Well, no (designers), partly (documentation and review) and yes (evangelists).

Fair enough.

> you seem to take that much more as an attack as it's meant to.

Well, it was an attack on "someone"... vague. Quite clearer now.

PyCon: Evangelizing Python

Posted Mar 30, 2013 14:49 UTC (Sat) by intgr (subscriber, #39733) [Link]

> Ah, the with statement. An innovative concept. Sigh. Those who don't know Lisp are condemned to reinvent it.

> Then evangelists (witness the talk from the article) come and present 30+ year old stuff as innovative concepts that's the best thing since sliced bread

Did he ever claim that these ideas were invented in Python? Did he say the word "innovative" even once in the talk?

All he said is that these features set Python apart from other "scripting languages", wtih Perl and Ruby brought out as examples. It's a true factual statement.

Lisp isn't even on the radar for being a competitor to Python.

PyCon: Evangelizing Python

Posted Mar 31, 2013 9:46 UTC (Sun) by marcH (subscriber, #57642) [Link]

> Did he ever claim that these ideas were invented in Python? Did he say the word "innovative" even once in the talk?

> All he said is that these features set Python apart from other "scripting languages", wtih Perl and Ruby brought out as examples.

In such a promotion speech context omitting references/credits creates a very fine line between the two. I can imagine the speaker saying the latter and the most of the audience misunderstanding the former (of course we'll never know).

I don't think there should be things like "credits" in reference documents like PEPs (PEPs seem to have pointers to discussions which is more than enough).

On the other hand I (finally) agree with jchrod: I expect a "Python's awesome" talk to give credit where it's due. Not just for honesty but also to help me develop my general software engineering culture and better understand *how* to create awesome things, i.e., by standing on the shoulder of giants, recombining existing ideas in new ways, and not patenting trivial prior art.

PyCon: Evangelizing Python

Posted Apr 1, 2013 16:16 UTC (Mon) by kleptog (subscriber, #1183) [Link]

Is it possible it's just because there are many people, like me, who don't know lisp and wouldn't know what a "with-statement in lisp" would look like if it stared them in the face. Certainly google isn't returning me any results, I guess they didn't call it the "with-statement" :). Perhaps someone who does know lisp should actually describe what it was the lisp did first.

I hope people aren't just referring to lisp's ability to transform source code at compile time because that (IMO) trivialises what the with-statement adds to the language: the ability to factor out certain idioms that would otherwise require explicit handling of exceptions. There's a difference between "language X makes it possible to do idiom Y" and "language X includes explicit support for idiom X".

While it may be that lisp did it first Python is the only contemporary language I know that includes something like the with-statement, which does say something.

PyCon: Evangelizing Python

Posted Apr 1, 2013 18:16 UTC (Mon) by nybble41 (subscriber, #55106) [Link]

In Common Lisp the form is known as "unwind-protect" [1], and in Scheme it's "dynamic-wind" [2]. The latter is more complicated because it attempts to handle the case where the inner code is re-entered through a continuation after the cleanup code has already been executed, but the idea is similar.

Both expressions execute a block of code with a guarantee that some other code will be executed when control leaves the block, no matter how that happens (e.g. normal exit, exception, calling a continuation). Operations built on top of this mechanism often start with "with-" by convention, e.g. "with-open-file" (Common Lisp) and "call-with-input-file" (Scheme) both ensure that the file provided to the inner block is closed afterward.

[1] http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node96.html
[2] http://www.schemers.org/Documents/Standards/R5RS/HTML/r5r...

PyCon: Evangelizing Python

Posted Apr 1, 2013 22:57 UTC (Mon) by nix (subscriber, #2304) [Link]

Needless to say, nothing remotely as complicated as the protocols needed in Python to implement 'with' are needed in Lisp. The macro system and unwind-protect/dynamic-wind provides all you need, and implementing new with-*'s is a matter of a few lines of extremely not difficult code. (I emphasise this because macros can often be extremely arcane. Writing a with-blah isn't one of those: the most you have to worry about is a bit of variable capture.)

PyCon: Evangelizing Python

Posted Apr 2, 2013 16:15 UTC (Tue) by lab (subscriber, #51153) [Link]

> Python is the only contemporary language I know that includes something like the with-statement, which does say something

The C# 'using' statement?
http://msdn.microsoft.com/en-us/library/yh598w02(v=vs.110).aspx

PyCon: Evangelizing Python

Posted Apr 2, 2013 17:06 UTC (Tue) by hummassa (subscriber, #307) [Link]

Every single C++ variable initialization is the equivalent to python's with and C#'s using...

PyCon: Evangelizing Python

Posted Apr 2, 2013 17:23 UTC (Tue) by intgr (subscriber, #39733) [Link]

Similar, yes. Equivalent, no.

1. Python's "with" statement is more flexible, it has access to the exception when it occurs. A "with db_transaction():" block can automatically decide to commit or roll back, unlike C++/C#. You can also implement something like "with ignore_exception(OSError):"

2. Python doesn't require you to create a local variable to hold the state; this always annoys me when using the RAII pattern to hold locks in C++.

3. Prettier syntax ;)

PyCon: Evangelizing Python

Posted Apr 2, 2013 19:13 UTC (Tue) by hummassa (subscriber, #307) [Link]

1. std::uncaught_exception() allows for your commit/rollback scenario, but not your ignore_this_exception scenario. The latter does not seem a good idea to me, but...
2. the lock thing can be implicit... it's a matter of how you do it. Anyway,
{
some_lock_t lock(x);
x.do_something();
}
does not seem sooo wrong to me... although I usually put it on X and do
x.do_something_locked<some_lock_t>();
only, or even
some_locking_scaffold(x).do_something();
and this last one is really easy.
3. it's not! :-D

PyCon: Praising Python for all the wrong reasons

Posted Apr 5, 2013 12:59 UTC (Fri) by gvy (guest, #11981) [Link]

> Lisp isn't even on the radar for being a competitor to Python.
Yeah, especially given Steel Bank Common Python. Crap, the radar you use must be from '60s!

PyCon: Praising Python for all the wrong reasons

Posted Apr 6, 2013 16:01 UTC (Sat) by pboddie (guest, #50784) [Link]

Your mention is the only trace of "Steel Bank Common Python" I can find on the Internet using Google. Meanwhile, I am aware of CLPython which may or may not now run on SBCL (given that I haven't checked CLPython's status for a while).

PyCon: Praising Python for all the wrong reasons

Posted Apr 6, 2013 16:18 UTC (Sat) by jake (editor, #205) [Link]

For Lisp-Python mashups, Hy might be of interest:

http://code.activestate.com/lists/python-announce-list/9602/

jake

PyCon: Praising Python for all the wrong reasons

Posted Apr 10, 2013 11:09 UTC (Wed) by gvy (guest, #11981) [Link]

It was a crude pun regarding "competition" applicability indeed, given the huge difference between these two cultures (at least from my perspective).

Python vs JavaScript

Posted Mar 28, 2013 23:26 UTC (Thu) by man_ls (guest, #15091) [Link]

It is funny that the speaker compared Python with Ruby so often, but apparently never mentioned JavaScript. I have the feeling that JavaScript is (oh surprise) the shiny cool new kid, despised for many years as a client-side adornment but lately stealing the wind from all the rest. And excuse me for mixing my metaphors so badly.

That has happened to me: I have to confess I am infected too. I have used Python for several years and it has served me well. But something about it was a bit bland: at its core it did not seem to trust functional programming but had to disguise it with comprehensions and yields. It was finally the transition from 2.x to 3.x did me in: really shoddy engineering; and that is not even the point.

Now I have seen really intelligent people moving JavaScript forward, doing very interesting stuff on the client and creating one of the most incredible ecosystems in Free software with npm. Few people are missing anything in Python out there, and it is really astonishing to me as Python is quite elegant and JavaScript tends to be horrible. And yet JavaScript works better and seems to be better suited for anything in real life.

Python vs JavaScript

Posted Mar 29, 2013 8:27 UTC (Fri) by marcH (subscriber, #57642) [Link]

> But something about it was a bit bland: at its core it did not seem to trust functional programming but had to disguise it with comprehensions and yields.

Functional programming in Python is a bit of a mystery. On the one hand it is seriously good at it and on the other hand the BDFL is not a big fan:

http://www.artima.com/weblogs/viewpost.jsp?thread=98196
http://python-history.blogspot.com/2009/04/origins-of-pyt...

Actually... by not scaring users away with functional syntax, Python might have done more for functional programming than functional languages, introducing many more people to it. Maybe that was Guido's secret or subconscious plan?

Oh and by the way: object oriented stuff is totally optional in Python and can be completely forgotten when not appropriate. A massive relief for anyone coming from... here for instance:
http://steve-yegge.blogspot.com/2006/03/execution-in-king...

> It was finally the transition from 2.x to 3.x did me in: really shoddy engineering;

Care to elaborate a bit?

Python vs JavaScript

Posted Mar 29, 2013 11:07 UTC (Fri) by man_ls (guest, #15091) [Link]

Care to elaborate a bit?
Sure, it is just the incompatibility between Python 2.x and 3.x code: it forces library developers to choose to support one or the other, instead of offering a common ground (which developers have found on their own but is still a bit cumbersome). To this day the default packages carried by Debian and Mac OS X (the two operating systems I use) are 2.x, so there is little incentive to upgrade most libraries.

I have spoken a lot about it in the past and received a lot of interesting feedback, so allow me to say just that a different solution would have been much appreciated and might have eased the divide, should such a divide be absolutely necessary (something that I am not sure).

On to the subject of the non-rivality with JavaScript: the PyPI has currently 29444 vs 26256 for npm; in a couple of years node.js is almost at the same number of packages, and that is without counting the huge number of browser-specific libraries. npm is still accelerating. It is hard to find comparable statistics of total downloads and such, but the most popular PyPI package is lxml which has seen about 8M downloads, while the most starred npm package (right on the front page), the web server framework express, has seen 1/17th as many downloads in the last month alone.

It is interesting how Python developers don't seem to see JavaScript as the competition and instead focus on Ruby. For me they cover a very similar space: both are scripting languages that have overstepped their boundaries, both multi-paradigm (although in the case of JavaScript "paradigm" is a bit charitable) and both contenders for the successor of Perl as "the duct tape of the internet".

Python vs JavaScript

Posted Apr 4, 2013 7:04 UTC (Thu) by sayap (guest, #71380) [Link]

> To this day the default packages carried by Debian and Mac OS X (the two operating systems I use) are 2.x, so there is little incentive to upgrade most libraries.

Debian Python maintainer is not very good at his job: http://lwn.net/Articles/496335/ Be grateful that you even have Python 2.7. Also, a quick Google search shows that MacPorts has packages for Python3.

> On to the subject of the non-rivality with JavaScript: the PyPI has currently 29444 vs 26256 for npm

You are comparing a "batteries included" language with one that doesn't have a standard library.

Python vs JavaScript

Posted Apr 4, 2013 7:52 UTC (Thu) by man_ls (guest, #15091) [Link]

You are comparing a "batteries included" language with one that doesn't have a standard library.
True for JavaScript, but node.js does a good job of supporting a fair standard library.

Python vs JavaScript

Posted Apr 4, 2013 20:42 UTC (Thu) by joib (subscriber, #8541) [Link]

I've been toying with the idea of playing around with node.js when I get some time. But I wonder, how well does it do for "normal" scripting stuff? I'm sure it's a nice tool for building socket servers, proxies and so on, but how suitable is it for stuff outside that niche? Stuff like parsing text, csv files, connecting to databases (ldap, sql, ...), access to POSIX functions, etc.?

In addition to the above, personally in python land I've used numpy/scipy/matplotlib extensively to do calculations and plotting stuff; AFAICT javascript/node/npm doesn't have anything coming close to those. But in the grand scheme of things that's perhaps a somewhat esoteric use case. Then again, servers capable of handling tens of thousands of concurrent connections seem pretty esoteric as well (to me, at least!)..

Python vs JavaScript

Posted Apr 9, 2013 5:59 UTC (Tue) by marcH (subscriber, #57642) [Link]

Similar questions here: can I use Node.js on the command line as a "glue" language like bash, Perl and Python? Is there an interactive mode? Can I Google any question and find a StackOverflow thread about it?

(The language matters, but the "ecosystem" matters probably even more.)

PyCon: Evangelizing Python

Posted Apr 5, 2013 12:26 UTC (Fri) by ThomasBellman (subscriber, #67902) [Link]

> as the Miranda language uses indentation and predates Python

And occam a couple of years before that.

Most computers running Windows?

Posted Apr 6, 2013 12:16 UTC (Sat) by Duncan (guest, #6647) [Link]

> most of the computers in the world are running Windows

I'm surprised nobody else seems to have commented on this so far. I thought most computers were running Linux these days, with Android pushing Linux over the top?

Not that I've cared enough to actually track it myself, but that's the impression from what I've read. But even if it's a plurality not a majority, I believe it has been awhile since the MS slogan of "A computer on every desktop" has been supplanted by (roughly speaking) "A computing device in every pocket", and most of those, as well as most of the servers serving them, as well as a good portion of the routers routing between the two, run Linux. MS may still rule the desktop, but the desktop's only a small portion of the computing world these days, and getting smaller literally by the minute.

Of course the claim wouldn't be our editor's fault, rather the fault of the guy doing the presentation (and thus making the claim) being covered. Tho it's still disruptive enough a claim as to merit an editorial parenthetical or footnote disclaimer, I'd think. It certainly was here.

Most computers running Windows?

Posted Apr 6, 2013 13:13 UTC (Sat) by hummassa (subscriber, #307) [Link]

> "A computing device in every pocket"

Is it funny to remember that the first time I read something like that was in Bill Gates' book?

Most computers running Windows?

Posted Apr 9, 2013 6:05 UTC (Tue) by marcH (subscriber, #57642) [Link]

> I'm surprised nobody else seems to have commented on this so far. I thought most computers were running Linux these days, with Android pushing Linux over the top?

I like my Android phone and tablet very much but I don't use them to write Python code.

Yes the desktop PC market is shrinking fast yet it remains the only way to get work done. I don't see mobile or couch devices changing this any time soon.

Note: I wrote "desktop PC"; not "Windows".

PyCon: Evangelizing Python

Posted Apr 6, 2013 19:42 UTC (Sat) by chrisV (subscriber, #43417) [Link]

"But generators have a problem: they are a "bad date". Like a date that can only talk about themselves, generators can only talk, not listen. That led to the idea of two-way generators. Now generators can accept inputs in the form of send(), throw(), and close() methods. It is a feature that is unique to Python"

Except that it isn't. This has been available in spidermonkey's ECMAscript implementation for ages (since 1.7?). Any language which provides delimited continuations can implement this, which includes GNU guile's scheme implementation (where I have working code which does this), and no doubt most of the other functional languages can do something similar.


Copyright © 2013, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds