Promoting Python

[Steven D'Aprano]

On Wed, 6 Apr 2016 09:06 pm, BartC wrote:

> On 05/04/2016 06:48, Gordon( Hotmail ) wrote:

>> The problem I am finding is most of the sites claiming to help understand
>> Python devote far too much space bragging about the wonders of Python
>> instead of...

I'd like to see these sites. I suspect that "bragging" actually
means "taking for granted powerful features that are unthinkable in BASIC".

If it makes you feel better, Bart, your opinion about Python is somewhat
similar to my opinion on the more esoteric areas of Lisp and Haskell
programming. That's the Blub paradox in action again. But the difference is
that I'm completely aware that my ignorance of Lisp and Haskell is *my*
ignorance, not their wilful obscuration.

Well, except for Monads. I'm convinced that Monads are a long-running April
Fool's gag that has gotten completely out of hand...

*wink*


> I fully agree. But you don't have to use classes, exceptions,
> decorators, generators, iterators, closures, comprehensions, meta
> classes, ... the list of meaningless buzzwords just goes on.

"Meaningless buzzwords"? Every one of those terms have meaning. They are
technical jargon, not buzzwords.

Honestly, hearing you say that makes you sound just tired and lost, an old
dog who has given up on the possibility of learning any new tricks. That's
sad, because none of those technologies above (with the possible exception
of metaclasses, which are kinda mind-bending the first eighty or ninety
times you read about them) are that complicated or difficult to use.
They're just *different*.

I feel for you -- when I hear folks talking about asynchronous programming,
or databases, I feel just as lost. But I'm not so arrogant to imagine that
those people are just flapping their mouths making random noises that have
no meaning, or that they're just sprouting buzzwords.

I don't get async programming because I've never taken the time to learn it.
That doesn't make it a "meaningless buzzword", it makes it something I
personally know little or nothing about. I should do something about it,
and the fact that I don't is *my loss*.

Unless you think that you have learned everything there is to know about
programming, you should know better than to describe modern programming
features as "meaningless buzzwords".


> It'll cope with ordinary coding as well, although such programs seem to
> be frowned upon here; they are not 'Pythonic'.

What's "ordinary coding" mean?

Most people, I imagine, know what a Zippo lighter is, even if they've never
owned one or smoked:

http://www.zippo.com/lighters.aspx?c=1230

You can light a fire with one by flicking them open and letting the lighter
do most of the work. That's "Pythonic".

But there's another way: you could, if you wish, clutch the lighter in one
hand, and a piece of flint in another, and strike the flint against the
lighter hard enough for sparks to come off. Direct the sparks into a small
pile of extremely fine wood shavings, or punk wood, and blow ever-so-gently
until the tinder catches alight. It won't be as easy or efficient as using
a proper flint and steel, but it will (probably) work.

https://en.wikipedia.org/wiki/Fire_striker

Is that what you mean by "ordinary coding"?

There's nothing wrong with lighting a fire with steel and flint, if you're
in the wilderness, or after civilization has collapsed, and you can no
longer get hold of lighter fluid or friction matches. It was a technology
that lasted for literally thousands of years, it works, and isn't
inherently *bad*. And for those who prefer to use human effort rather than
products of advanced technology (like butane lighter fluid), a steel and
flint is the more attractive option.

But, frankly, using a Zippo lighter as the steel *is* inherently bad, since
its the wrong sort of steel and will be very inefficient. That's not what
Zippo lighters are designed to be. In an emergency, with no other steel
around, using a Zippo lighter as a fire-striker may be justified by
necessity, but it should never be PREFERRED over using it the way it was
designed to be used.

Of course programming is rather more complex that lighting fires, and
there's no hard and fast line between using Python in a Pythonic fashion
and misusing it in a non-Pythonic fashion. This isn't unique to Python: in
*every* language, there is "good coding style" and "poor coding style",
both of which depends on the strengths and weaknesses of the specific
language being used.



>> Liberty Basic
>> for n = 32 to 255: print n;chr$(n) : next n
>>
>> REM BBC Basic
>> FOR c = 1 TO 15 : COLOUR c
>>    PRINT "Color ";c
>> NEXT c
> 
> Python apparently has hundreds of libraries to do this stuff, which is a
> downside: there are as many libraries as Basics probably! And each seems
> to work a little differently from the other...
> 
> I haven't tried graphics in Python, but I would start by googling
> 'python basic graphics' or some such phrase.

Unfortunately, technology has moved on, and there's nothing I've seen that
comes close to the simplicity of graphics programming in 1980s-era BASICs.
The closest is, perhaps, the turtle graphics module in Python, based on
Logo, but I think the honest truth is that for all the advantages of modern
GUI systems, the old low resolution, handful of colour PCs had their
charms, and I think we've lost a certain something in their passing.

Not that I would ever go back to the bad old days when 64K was considered
more memory than anyone would ever need. But still, it's not just
nostalgia, there really was something awesome about turning on a brand new
computer for the first time and being able to immediately start doing
graphics programming.


-- 
Steven