LWN: Comments on "PyCon: Evangelizing Python"

PyCon: Evangelizing Python

dpquigl — Thu, 18 Apr 2013 16:03:13 +0000

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

rahulsundaram — Wed, 17 Apr 2013 23:51:37 +0000

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

raven667 — Wed, 17 Apr 2013 23:48:50 +0000

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

dpquigl — Wed, 17 Apr 2013 21:56:02 +0000

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: Praising Python for all the wrong reasons

gvy — Wed, 10 Apr 2013 11:09:30 +0000

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

Most computers running Windows?

marcH — Tue, 09 Apr 2013 06:05:16 +0000

> 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".

Python vs JavaScript

marcH — Tue, 09 Apr 2013 05:59:44 +0000

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

wtanksleyjr — Mon, 08 Apr 2013 21:08:51 +0000

>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

chrisV — Sat, 06 Apr 2013 19:42:36 +0000

"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.

PyCon: Praising Python for all the wrong reasons

jake — Sat, 06 Apr 2013 16:18:51 +0000

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

pboddie — Sat, 06 Apr 2013 16:01:39 +0000

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).

Most computers running Windows?

hummassa — Sat, 06 Apr 2013 13:13:34 +0000

> "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?

Duncan — Sat, 06 Apr 2013 12:16:52 +0000

> 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.

PyCon: Evangelizing Python

andrel — Fri, 05 Apr 2013 19:47:46 +0000

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

PyCon: Evangelizing Python

HelloWorld — Fri, 05 Apr 2013 18:41:36 +0000

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

XTF — Fri, 05 Apr 2013 13:49:41 +0000

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

XTF — Fri, 05 Apr 2013 13:27:30 +0000

[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

renox — Fri, 05 Apr 2013 13:25:35 +0000

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

XTF — Fri, 05 Apr 2013 13:15:23 +0000

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

PyCon: Praising Python for all the wrong reasons

gvy — Fri, 05 Apr 2013 12:59:17 +0000

> 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: Evangelizing Python

ThomasBellman — Fri, 05 Apr 2013 12:26:53 +0000

> as the Miranda language uses indentation and predates Python

And occam a couple of years before that.

PyCon: Evangelizing Python

intgr — Fri, 05 Apr 2013 08:42:39 +0000

> 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"

PyCon: Evangelizing Python

dlang — Fri, 05 Apr 2013 07:02:03 +0000

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

smurf — Fri, 05 Apr 2013 06:19:41 +0000

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

welinder — Fri, 05 Apr 2013 04:16:45 +0000

> 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.

Python vs JavaScript

joib — Thu, 04 Apr 2013 20:42:48 +0000

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

man_ls — Thu, 04 Apr 2013 07:52:40 +0000

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

sayap — Thu, 04 Apr 2013 07:04:54 +0000

> 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.

PyCon: Evangelizing Python

hummassa — Tue, 02 Apr 2013 19:13:29 +0000

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: Evangelizing Python

intgr — Tue, 02 Apr 2013 17:23:38 +0000

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

hummassa — Tue, 02 Apr 2013 17:06:57 +0000

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

PyCon: Evangelizing Python

lab — Tue, 02 Apr 2013 16:15:10 +0000

> 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

nix — Mon, 01 Apr 2013 22:57:54 +0000

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

nybble41 — Mon, 01 Apr 2013 18:16:43 +0000

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

kleptog — Mon, 01 Apr 2013 16:16:17 +0000

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

dark — Sun, 31 Mar 2013 09:48:03 +0000

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

marcH — Sun, 31 Mar 2013 09:46:05 +0000

> 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

marcH — Sun, 31 Mar 2013 09:23:30 +0000

> 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

tnoo — Sat, 30 Mar 2013 20:53:01 +0000

> 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

serzan — Sat, 30 Mar 2013 20:18:52 +0000

I did not say that it does.