Python advice

[Chris Angelico]

On Wed, Sep 24, 2014 at 12:48 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> On Mon, Sep 22, 2014 at 6:55 PM, Chris Angelico <rosuav at gmail.com> wrote:
>> Lua is a much simpler language than ECMAScript, incredibly
>> light-weight, and easily sandboxed. It doesn't work with Unicode (I
>> think its string type is eight-bit, so you have to work with encoded
>> bytes), which is a serious downside in my opinion. Learn Lua if you
>> want to work with something that embeds it. Otherwise, don't bother
>> for now.
>
> Apart from the Unicode issue, I'm curious what makes you describe it
> as "much simpler" than ECMAScript.  Lua has coroutines built into the
> language, stricter typing than ES (still not as strict as Python, but
> at least you don't have to deal with a === operator because the ==
> operator is broken), operator overloading, iterators, block-level
> scoping, closure construction that binds loop variables the way the
> programmer expects (unlike both Python and ES), and associative arrays
> that allow arbitrary keys rather than coercing the keys to strings.

Mainly that's based on a feeling, rather than anything specific; I've
worked with both Lua and JS from both ends (although the extent of my
experience with embedding Lua is an evaluation exercise only; the
project ended up going with ECMAScript via the V8 engine, which was
the other major choice), and Lua seems rather less featured. Partly
this might be a consequence of using a very full-featured JavaScript
implementation (V8), but it felt like embedding Lua meant doing a lot
more of the work myself. Also, from the script writer's point of view,
Lua's table type seems less powerful than the JS object, although that
may be a flawed appearance due to my greater experience with the
latter.

In any case, it fits into a very specific niche: you learn Lua if you
want to script something that offers Lua scripting. That's technically
the same as the JavaScript niche, except that there's a really big
"something" that everyone wants to script, and that's web browsers.
(Plus, node.js means you can write server-side code in JS, though
personally I wouldn't recommend it; I've seen nothing that node.js can
do that Python with a good framework can't do just as easily, and
without UTF-16 baggage.)

>> * SQL is the one and only database query language you should ever need
>> to bother with. (You might skip SQL too, if you use something like
>> SQLAlchemy, but you certainly won't need any other query language -
>> not in 2014.) It's well worth getting to know SQL at some point;
>> whether you use Python, Pike, C, or any other language for the
>> application, your SQL code will be the same.
>
> SQLAlchemy lets you use SQL without actually writing SQL, but I would
> argue that it's still basically necessary to understand SQL and what
> the SQLAlchemy calls translate to in order to use it.

What I'd say is that you have to understand database design. There are
concepts that go beyond the actual language used (figuring out what a
table's primary and unique keys are, handling joins, knowing how to
trace logical structure through a series of tables, etc) that you're
never going to get away from. With a framework like SQLAlchemy, you
shouldn't have to worry about things like the esoteric quoting rules
of different DBMSes (why, oh why, can't we just stick to the standard
- 'quoted string', "identifier", and not use backticks at all??), but
you still have to craft a sane database structure.

When I say that you won't need any *other* query language, I mean that
you're unlikely, in 2014, to use the BTrieve API calls that I worked
with in the 1990s to interface with Pastel Accounting, nor the DBase
calls that manipulate those fragile .dbf files that oh so easily get
damaged if two people try to use them at once, etc, etc, etc. You
might use a wrapper around SQL if you choose, but certainly if you
know SQL you should be able to handle any database. And that's a Good
Thing.

ChrisA