New user's initial thoughts / criticisms of Python

[Chris Angelico]

On Sun, Nov 10, 2013 at 12:08 AM, John von Horn <j.h69 at btinternet.com> wrote:
> Hi Everyone,
>
> I'm Mr. Noobie here, I've just started easing into Python (2.7.4) and am
> enjoying working along to some youtube tutorials. I've done a little
> programming in the past.

Hi! For myself, I've come from a background writing code in many other
languages (most notably C family), and I actually joined this list to
ask how to do something that turned out to be impossible[1]. Ended up
staying because the community's awesome. (Apart from a few. You know
who you are. :) )

> I've just got a few thoughts I'd like to share and ask about:
>
> * Why not allow floater=float(int1/int2) - rather than floater=float
> (int1)/float(int2)?
>
> Give me a float (or an error message) from evaluating everything in the
> brackets. Don't make me explicitly convert everything myself (unless I
> want to)

As others have said, what you're asking for is actually magic. One of
the rules of Python - one for which I'm not aware of any exceptions -
is that you can always take a subexpression out and give it a new
name:

floater = float(int1/int2)

temporary = int1/int2
floater = float(temporary

will do the exact same thing (modulo the retention of an
intermediate). This helps *HUGELY* with debugging, and it's part of a
general "no magic" policy. Sometimes there are other handy cases,
too... like that literals are nothing special, and that methods on
objects carry all the information they need:

>>> formatter = "Foo {} bar {} quux".format
>>> formatter("Asdf","Qwer")
'Foo Asdf bar Qwer quux'
>>> formatter("Hello","World")
'Foo Hello bar World quux'

I just created a function that's actually a method off a literal
string. (It returns a string. I'm doing this at the interactive
interpreter (REPL [2]), so the return values are being displayed.) As
far as the rest of the code's concerned, it's a function just like any
other. JavaScript doesn't do this. You can have closures, which carry
state about with them... but for some reason that completely escapes
my comprehension, methods aren't bound to the objects that called
them, so these two do quite different things:

document.getElementsByTagName("P");

var func = document.getElementsByTagName;
func("P");

That's magic, and IMHO not a good thing. So, getting back to your
query about floats... The only way for that to be not-magic would be
for the int-divided-by-int part to be not yet evaluated by the time
the float call happens. As others have pointed out, Python 3 has
int/int --> float, so *this specific* instance wouldn't apply. But the
same consideration applies to other types:

>>> import fractions
>>> fractions.Fraction(12345/54321)
Fraction(4093955369001953, 18014398509481984)

The division is done and results in either a float (Python 3, as shown
above) or an int (which would be 0). Either way, by the time the
Fraction constructor tries to figure out what value it's been given,
information has been lost (floats get rounded). The correct way to
create a Fraction is to pass it the numerator and denominator
separately:

>>> fractions.Fraction(12345,54321)
Fraction(4115, 18107)

This now has the exactly correct value (it cancelled the common prime
factor of 3 from both values). It's a small price to pay for a
guarantee of no-magic evaluation, and the awesome simplicity that that
gives.

> Just some initial thoughts. I just wanted to know the reasoning behind
> the above, be shown the shortcomings of my ignorance, pointed in the
> right direction. Let the High Priests of Python come forth and speak wise
> words and show me the ignorance of thy ways. Let my cup be filled to
> overflowing with your kind knowledge and wisdom.

I like that attitude: "This seems odd, so I'll ask why, because that
way I'll learn something". Some of us have worked with a large number
of different programming languages, others have a background in
mathematics (Steven D'Aprano, who'll probably post a response in this
thread before long, recently contributed a shiny new statistics module
to the Python standard library), still others have been working in
computers so long that they've become them (okay, not quite). Maybe
none of us is a High Priest of this language, but we all have our own
perspectives on what works and what doesn't, so pretty much any
question is going to get some responses. :)

> Is everyone happy with the way things are? Could anyone recommend a good,
> high level language for CGI work? Not sure if I'm going to be happy with
> Perl (ahhh, get him, he's mentioned Perl and is a heretic!) or Python. I
> would very much value any constructive criticism or insights.

No, not everyone's happy with the way things are. If we were, where
would Python 3.4 come from? :)

If by CGI you actually literally mean CGI, then most of us don't have
any experience with it. But if you mean more generally "code executed
on the fly to create a web page", there are quite a few options. Some
of us have worked with, again, a variety of languages (I just quit/got
fired from a job involving PHP; my boss couldn't understand why I so
strongly disliked PHP, despite lengthy explanations), and even within
one language there are often multiple ways to do things (Python web
frameworks are a huge thing all of their own). I would recommend
setting down more of your requirements, then going through the
languages and frameworks you know of and ticking the boxes as much as
you can. When you've finished that exercise, you might have something
like "I could use Django, except that it doesn't do XYZ for me", which
would make a perfect python-list thread, or "I could use PHP, except
that the hammer has two claws on it[3]", which wouldn't. :)

Welcome to Python, and to python-list. You'll find us all fairly
opinionated, but as long as you're willing to learn, we'll be more
than happy to explain things :)

ChrisA
[1] For the curious, I was trying to sandbox CPython and run untrusted
scripts while stopping them from accessing the OS or file system. It's
basically impossible, so we switched to embedding JavaScript instead.
[2] Read/Evaluate/Print Loop. Something I'd consider fairly standard
now for an interactive interpreter. PHP's interactive mode is a
Read/Eval Loop, so you have to explicitly print things - seems like a
trivial difference, but it affects productivity hugely, especially
when you didn't compile in GNU Readline support.
[3] http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/
and when you've read that,
http://www.flickr.com/photos/raindrift/sets/72157629492908038