PyCon: Evangelizing Python [LWN.net]

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 (subscriber, #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 (subscriber, #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 (subscriber, #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.