Python Newbie

[Mitya Sirenef]

It's worth noting, though, that there are self-perpetuating aspects to
it. I can happily distribute a .py file to a Linux audience, because
many Linux distros come with a Python already installed, or at very
least can grab one easily via the package manager. No matter how
awesome Fred's Awesome Internet Language is, it's not going to be as
good a choice as something that people can simply 'apt-get install',
'yum install', or whatever they're most familiar with. I don't have
enough history with Python to know when that status began to be
achieved, nor how it happened, but I'd guess that exciting/interesting
a distro manager is different from being the best choice for writing
an application.

That said, though, Python is very good at both halves. But there might
very well be a language far superior for writing (say) a GUI app, that
just doesn't have the traction that Python does thanks to its
usefulness in the plumbing.

ChrisA

Sure, that's true; I mostly meant it in context of stuff listed on that
page, and when compared to languages of similar age.

It's also worth noting that if there's a new language that is somewhat
better than all established languages, but not to the extent that it
will ever replace them (because of network effects), it's not really
better for any practical purposes -- present and future[*] ecosystem is a
part of a language's value proposition.

-m

[*] of course, future is hard to predict, especially when it hasn't yet
happened.

 

[rurpy]

[...] the first 'killer app' for Python was nuclear weapon calculations...

Gives a whole new meaning to the phrase "killer app", doesn't it?

 

[Chris Angelico]

It's also worth noting that if there's a new language that is somewhat
better than all established languages, but not to the extent that it
will ever replace them (because of network effects), it's not really
better for any practical purposes -- present and future[*] ecosystem is a
part of a language's value proposition.

Right. In a pure and clinical sense, it may be "better" - it might
save you 10% on dev time and 25% on run time, say - but if it costs
you more than that in support and documentation when you explain to
people how they have to install a new language interpreter to use it,
it's a much less promising proposal. (That's why Gypsum, my MUD client
written in Pike, is still a toy. I was fully aware that I was saddling
it with an obscure language interpreter.)

ChrisA

 

[Mark Lawrence]

It's worth noting, though, that there are self-perpetuating aspects to
it. I can happily distribute a .py file to a Linux audience, because
many Linux distros come with a Python already installed, or at very
least can grab one easily via the package manager. No matter how
awesome Fred's Awesome Internet Language is, it's not going to be as
good a choice as something that people can simply 'apt-get install',
'yum install', or whatever they're most familiar with. I don't have
enough history with Python to know when that status began to be
achieved, nor how it happened, but I'd guess that exciting/interesting
a distro manager is different from being the best choice for writing
an application.

That said, though, Python is very good at both halves. But there might
very well be a language far superior for writing (say) a GUI app, that
just doesn't have the traction that Python does thanks to its
usefulness in the plumbing.

ChrisA

Sure, that's true; I mostly meant it in context of stuff listed on that
page, and when compared to languages of similar age.

It's also worth noting that if there's a new language that is somewhat
better than all established languages, but not to the extent that it
will ever replace them (because of network effects), it's not really
better for any practical purposes -- present and future[*] ecosystem is a
part of a language's value proposition.

-m

[*] of course, future is hard to predict, especially when it hasn't yet
happened.

Seems like as good a time as any to throw this into the pot
http://www.gossamer-threads.com/lists/python/python/129650?do=post_view_threaded

 

[Steven D'Aprano]

Today I learned the hard way that all function parameters in Python are
passed by reference (meaning whatever happens to them inside a function,
new values are always passed to caller). Not good.

Today you learned wrong.

This is a common misapprehension. Python is not pass by reference, nor is
it pass by value. There are many, many more argument passing strategies
used than just those two. Like Ruby and Java, Python is pass by object-
reference, or pass by sharing if you prefer.

You can read more about this here:

http://www.mail-archive.com/[email protected]/msg46612.html

The canonical test of pass-by-reference is to write a "swap" procedure,
one which swaps the values of any two variables:

a = 1
b = 2
swap(a, b)
assert a == 2, b == 1


You cannot write this in Python.

The canonical test of pass by value is that arguments are copied when you
pass them to a function:

a = 1
def different_from_global(argument):
assert id(argument) != id(a)

different_from_global(a) # fails


Python does not copy arguments when you pass them to functions.

I got caught up on
this. To combat the mostly unwanted behavior, inside a function I have
to reassign variables intended to be local to new variables. A pain. Can
anyone offer ONE reason why Python was designed that way?

Because it is a sensible way to operate for an object-oriented language.
Python will not unnecessarily copy data that doesn't need to be copied.
If you want a copy, you copy it yourself. On the other hand, function
parameters should be local to the function. These two requirements rule
out both pass by value and pass by reference as the parameter passing
model.

Out of curiosity, does anyone have any idea why function declarations
are preceded by the keyword "def" rather than something more intuitive
like "function" or at least "func", perhaps?

"def" is short for "define". As for why the keyword was chosen to be
"def" rather than "define" (like Scheme), "function" (like Pascal),
"defun" (like Lisp), "fun" (like Erland), "define method" (like Dylan),
or even "swyddogaeth" (Welsh), that's just a matter of personal taste of
the creator.

 

[Serhiy Storchaka]

"def" is short for "define".

Actually "def" is short for "DEfine Function".

 

[Rui Maciel]

(e-mail address removed) wrote:

So far I am getting the impression that Python is a toy language of some
kind (similar to Basic of the early 80's), not really suitable for serious
work. The only difference between these languages (admittedly, a serious
one) is the existence of extensive libraries. Otherwise there would be no
good reason for Python to exist. Nevertheless, it does exist and I have to
learn it. As long as someone is paying for my time, that's OK with me.

That's some military-grade trolling.


Rui Maciel

 

[Chris Angelico]

I get the impression that you are a developer of some experience on a single
language. I wouldn't call myself a developer but I have written, modified
and/or debugged software in upwards of 20 languages and, from that
perspective, I would say that the second language you learn is probably the
hardest for the simple reason that you have to put away a bunch of learned
prejudices and learn a whole new set. After three or four, you start to see
the commonalities and differences and 'get' why they exist and you find
yourself with a new set of learned prejudices but you also gain the
perspective that some languages are good at 'this' while others are good at
'that'.

+1000

When you learn your first language, you think you're learning to
program, but that's not really accurate. Once you've learned half a
dozen, you begin to understand something of the art of coding as
distinct from any particular language; after that, you can learn any
language fairly easily.

Steve, why do you say you're not a developer? A score of languages
under your belt, choosing to write code in your spare time, and
speaking competently on the comparative merits of different languages
and why you made the decision you made - sounds like you're every bit
a coder. Don't run yourself down so!

ChrisA

 

[Ethan Furman]

Steve, why do you say you're not a developer? A score of languages
under your belt, choosing to write code in your spare time, and
speaking competently on the comparative merits of different languages
and why you made the decision you made - sounds like you're every bit
a coder. Don't run yourself down so!

+1

 

[Gene Heskett]

+1

I'll add another +1 to that. My /main/ coding expertise, such as it is, is
in assembly on the 6x09 cpu's. Sure, I've done stuff in C, and in Basic09,
but when I sit down to do a serious bit of code for that platform that
doesn't need fancy trig functions, I do it in assembly. Why? The closer I
can get to the hardware, the fewer surprises I find. I can handle input
errors for every possible error just by testing for legal input, and if not
legal, branch to output a help screen to the dummy that cannot type. Often
me. Quick stuff that does require some math gets done in basic09 which
is good to about 8-9 digits, or calculating the next eclipse, based on
julian dates, gets done in C where I have doubles and 17 digit floats
available.

And I have quite a few bash scripts, often running as background daemons,
that greatly simplicate my daily activities. KMail for instance, doesn't
have to take 2 minute timeouts while it fetches new mail is one of them. So
my email is a matter of tapping the + key for the next message, replying if
I want to & clicking send. Everything else is automatic. Ditto if I am
working on the old machine & need a printout, I just send the text file
from the assembler to device /p, and 15 seconds later a laser printer on
that desk fires up and spits out my listing at 22 ppm. /p actually feeds a
ser-usb adapter, its output is captured on this machine, sent to cups for
rendering & sent back down the same cable to the printer also plugged into
that usb hub. To me there is zero point in having to stop & look up the
command line syntax to drive lp with a 100 character command line when
except for the filename to print, it never changes. Put it in a bash
script that doesn't make typu's.

So I am a programmer in that sense, just not at the level of abstraction
that python has to offer.

I am here because I was hoping some knowledge leakage would help me to
understand python, but at my age I am beginning to have to admit the level
of abstraction is something I may never fully grok. If I ever find a
python book that literally starts at square one, it _will_ come home with
me though.

But I have too many hobbies too, I have a BP rifle that needs a trip to the
range this afternoon for some exercise.

Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
My views
<http://www.armchairpatriot.com/What Has America Become.shtml>
The telephone is a good way to talk to people without having to offer
them a drink.
-- Fran Lebowitz, "Interview"
I was taught to respect my elders, but its getting
harder and harder to find any...

 

[Steve Simmons]

Steve, why do you say you're not a developer? A score of languages
under your belt, choosing to write code in your spare time, and
speaking competently on the comparative merits of different languages
and why you made the decision you made - sounds like you're every bit
a coder. Don't run yourself down so! ChrisA

I guess I was a developer back in 1972 when I did 15 months worth of
COBOL and for a while in the late 70's when I was coding in assembler
for ICL machines (24 bit words!) but since then, I've never done enough
with any one language to be able to code without 'the book' open in
front of me, so I'd feel a bit of a fraud if I called myself a
developer. However, what I have done has taught me every computer works
in the same way, from the Raspberry Pi all the way back to those 32Kb
'mainframes' of the 70's and that a compiler/linker or interpreter goes
through a very similar process for any language on any architecture,
although I'm sure someone will reply to this post to tell me that the
Gargleflup 3000 model 6.78.009B was COMPLETELY different or to ask why I
hadn't mentioned the Zurp language if I was so damn knowledgeable. ;-)
I suppose that if I had to label myself, it would be 'IT Generalist' but
I've been doing that for over 40 years so I suppose I'm a Specialist
Generalist

 

[Steve Simmons]

I am here because I was hoping some knowledge leakage would help me to
understand python, but at my age I am beginning to have to admit the
level of abstraction is something I may never fully grok. If I ever
find a python book that literally starts at square one, it _will_ come
home with me though. But I have too many hobbies too, I have a BP
rifle that needs a trip to the range this afternoon for some exercise.
Cheers, Gene

I'm using Rapid GUI Programming with Python & Qt (Mark Summerfield ISBN
978-0-13-235418-9) - it fits for me because I needed something that
covered GUI development but also had an intro to the language. The
first 3 chapters are a Python intro at a sensible level for experienced
coders (none of this 'here is the keyboard, there is the screen'
nonsense) so it is enough to get you going with Python. The rest is
about Qt/PyQt, taught via manageable examples and giving a fairly well
thought out dialogue (monologue?) of what each line/function does. It
was useful enough for me to want to carry the hardback version with me
on my 'commute' from the UK to Nigeria where I am currently working.
I've also got two books by Wesley Chun, (Core Python Programming & Core
Python Applications Programming) on my Kindle . I can't give you a
sensible verdict on those two because, while I've finally settled to
reading fiction on the Kindle, I still like to have a real book when it
comes to reference works (on any subject) so they haven't had the usage
that Summerfield has.

Oh, and you're never too old for anything but most things take longer -
gives you more time to enjoy them ;-)

 

[Dennis Lee Bieber]

if (some statement): # short form

in the example I gave, but you figured exactly what I mean. Of course if the condition (some statement) is boolean there is no point adding "== true" or similar. But if (some statement) represents a value this is where I have trouble and again the origins of this date back to when Python had no boolean type. So now at least I understand it.

Python isn't the only language that will treat non-Boolean as
Boolean, though applying it to strings, floats, other objects may be an
extension (and one which does simplify a lot of code, in my view).

Error codes under DEC VAX/VMS used odd integers for
"success/information" and even integers for "warning/error" (been too
many years, I think positive integers were success/warning, negative
integers were information/error; I could also be wrong on which set were
even... if 0 were no-info/success then odd were errors and even were
success)).

The VAX instruction set only used the least significant bit for
Boolean checks, so one could do a fast check by

if (retCode) then
#assume odd are errors
#examine for "correctible" error codes
#or dump an exception
else
#assume we don't care for specific info messages
#a la: tape already at beginning, if the operation was a rewind
#do normal processing
end if

Btw, there are still languages with no boolean type today, MySQL for one. This creates big efficiency problems when fetching data from the database into a C# program - what should be a bool is fetched as an 8-byte integer! But that's a different story. I shut up now.

SQL itself did not define a Boolean type until the 1999 standard --
and in that standard, Boolean is an optional feature.
http://en.wikipedia.org/wiki/Boolean_data_type#SQL

Apparently few database engines implement a true Boolean.

 

[Dennis Lee Bieber]

awesome Fred's Awesome Internet Language is, it's not going to be as

Pardon, but was that deliberate -> FAIL

 

[Michael Torrie]

Hi folks. I am a long time C sharp dev, just learning Python now due
to job requirements. My initial impression is that Python has got to
be the most ambiguous and vague language I have seen to date. I have
major issues with the fact that white space matters. How do you deal
with this?

Well I never use tabs in python files and I don't expect any python
source code file to either. Any that do I consider to be a bug.

But as for whitespace syntax formatting in general, I love it.
Executable pseudo-code makes for more rapid development (and fewer
errors) than in any language I have used to date.

 

[jmfauth]

On 22/02/2013 22:37, (e-mail address removed) wrote:> So far I am getting the impression ....

My main message to you would be :  don't approach Python with a negative
attitude, give it a chance and I'm sure you'll come to enjoy it.

----

Until you realize this:

Py32:

42

Py33:

50

Very easy to explain: wrong, incorrect, naive unicode
handling.

jmf

 

[Michael Torrie]

Thanks for this. Regarding ambiguity, you will never find me write
ambiguous code. I don't sabotage my own work. But the reality is
that in addition to writing my own code, I have to maintain existing.
I find it incredibly confusing then I see a statement along the
lines of "if not something" - have to study the code in detail to see
what it is testing.

As others have said, I don't see why this should be confusing. It's a
common idiom that happens in C# or C all the time:

if (!some_state)
{
//blah
}

There is absolutely no ambiguity here. Every C# and C programmer knows
exactly what this means. As others have said, it's the equivalent of
saying, ((bool)(expression) != True). Just in a cleaner way and in a
way that echos how most programmers actually think. And in python,
dropping the unnecessary comparisons actually gives you a speed up too.

In python there is some ambiguity as to what constitutes a boolean truth
or falsehood value for some types. For example, an empty list ([]) is
false, as is an empty dictionary ({}), and a number is 0. And in some
cases (default arguments, for example), using a "is None" comparison is
required. For example:

def some_function( a = None):
# None is used above as the default because lists are
# mutable, and if a list were placed up there it would
# affect all subsequent calls to some_function()

if a is None:
a = [ 'default', 'values', 'here']

for x in a:
print x

some_func()
some_func(1,2,3)

I could show more examples of what I find confusing in existing
code, but I don't intent to troll. I'm just trying to understand the
language as it is. I will see how it goes.

As long as you are trying to write C# code in Python, you'll be very
frustrated. Takes some time to learn about what it means to write
"pythonic" code. You'll be well-served and you will start to enjoy the
language more. Ditch the excess parenthesis. They don't make things
clearer necessary and they really confuse what is a statement with what
is an expression (a pet peeve of mine with C).

Finally take some time to learn about how Python works from a language
theory point of view. One interesting thing you'll learn is that python
actually has no variables. This is a powerful concept, but can get you
in trouble sometimes when you're not aware of this fact.

 

[Ethan Furman]

On 02/23/2013 10:44 AM, jmfauth wrote:

[snip various stupidities]

jmf

Peter, jmfauth is one of our resident trolls. Feel free to ignore him.

 

[Ian Kelly]

Until you realize this:

Py32:

50

Very easy to explain: wrong, incorrect, naive unicode
handling.

You've previously been asked not to hijack unrelated threads with your
misguided Unicode FUD. Since you persist in doing so, consider your
posts now relegated to my trash folder.

 

[Michael Torrie]

I'm using Rapid GUI Programming with Python & Qt (Mark Summerfield ISBN
978-0-13-235418-9) - it fits for me because I needed something that
covered GUI development but also had an intro to the language.

Sounds fun. One thing about PyQt is that it's really just C++ thinly
wrapped in python calls. It's not really that pythonic. PySide looks
to be a bit better, with more pythonic ways of interacting with things
(iteration, etc).