learnpython.org - an online interactive Python tutorial

[Ron]

Hey everyone.

I've written an online interactive Python tutorial atop Google App Engine: http://www.learnpython.org.

All you need to do is log in using your Google account and edit the wiki to add your tutorials.

Read more on the website.

Thanks for your help, and I would appreciate if you help me spread the word, and give me feedback on the website.

 

[Matty Sarro]

Awesome project, I really like it. I'll see if I can't help adding
some material that's missing when I get on the train.
Keep up the great work!

 

[Terry Reedy]

I've written an online interactive Python tutorial atop Google App Engine:

http://www.learnpython.org.

Currently giving 500 server error. Hope something clears up.

 

[Chris Angelico]

Hey everyone.

I've written an online interactive Python tutorial atop Google App Engine: http://www.learnpython.org.

That looks very handy! And I notice you've protected yourself by
running it in a sandbox:


import time
time.sleep(3)

Traceback (most recent call last):
File "/base/data/home/apps/learnpythoneasy/1.349862757547785986/main.py",
line 93, in post
exec(cmd, safe_globals)
File "<string>", line 1, in <module>
TypeError: 'NoneType' object is not callable

hehe

Quite a few people on Threshold RPG have spoken to me about learning
programming, and I usually point them to Python or Pike; I think this
site will be where I start pointing people. Looks good!

ChrisA

 

[Algis Kabaila]

Hey everyone.

I've written an online interactive Python tutorial atop
Google App Engine: http://www.learnpython.org.

All you need to do is log in using your Google account and
edit the wiki to add your tutorials.

Read more on the website.

Thanks for your help, and I would appreciate if you help me
spread the word, and give me feedback on the website.

Python is completely object oriented, and not "strongly typed"

False: Python IS strongly typed, without doubt (though the
variables are not explicitly declared.)

Explicit declaration and strong typing are two completely
differen things. If you are going to teach (and that is what
tutorials are for), it is obligatory to learn first...

OldAl.

 

[Chris Angelico]

False: Python IS strongly typed, without doubt (though the
variables are not explicitly declared.)

Strongly duck-typed though. If I create a class that has all the right
members, it can simultaneously be a file, an iterable, a database, and
probably even a web browser if it feels like it. Is that strong typing
or not?

Chris Angelico

 

[harrismh777]

Python is completely object oriented, and not "strongly typed"

False: Python IS strongly typed, without doubt (though the
variables are not explicitly declared.)

Playing the advocate for a moment here, this is something that I was
confused about early on also... and frankly, you are both correct, but
from different vantage points.

Python IS strongly typed in that operations may only be applied to
objects that support 'that' operation... numbers support (+) and also
strings support (+) , although, the (+) does 'different' things
depending on the object type. You might look at this as STRONGLY typed
and you would be correct... however, you might look on this as weakly
typed and you would still be correct... because why?

Because, the programmer doesn't have to worry about the 'types' she is
using ... the object based nature of the language and polymorphism come
together so that the 'right thing' happens with (+) regardless of
type... see? weakly typed...

In C the programmer is always considering what 'type' is this thing...
even testing for it... and C is considered by those programmers (yes, me
) as STRONGLY typed. The types must be declared ahead of time for sure,
but that's not the point... the point is that the 'type' matters and
must always be on the front lobes in thinking about logic.

In Python much of the thinking about types is not even necessary.. for
the most part... and by design. In this way of thinking the language is
weakly typed... on the other hand, because the objects may be only
manipulated by operations they support, this makes Python STRONGLY
typed. Confused yet???

How one thinks about this depends on programming background, what is
meant by 'type' and how the programmer differentiates thinking about
types as variables versus objects.

Having said all of that, I agree that Python should be classified as
STRONGLY typed... and this classification should always come with an
explanation ... especially to new advocates writing tutorials...

kind regards,
m harris

 

[Heiko Wundram]

Am 21.04.2011 09:19, schrieb Chris Angelico:

Strongly duck-typed though. If I create a class that has all the right
members, it can simultaneously be a file, an iterable, a database, and
probably even a web browser if it feels like it. Is that strong typing
or not?

Yes, that's strong typing, because your class only works in those
contexts that you "explicitly" allow it to work in (through implementing
an interface, be it an iterator, a file, etc.), independent of
"duck-typing" (which is pretty much described by the term
interface-based typing IMHO).

The difference between strong typing and weak typing is best described by:

Python 2.6.5 (r265:79063, Jun 12 2010, 17:07:01)
[GCC 4.3.4 20090804 (release) 1] on cygwin
Type "help", "copyright", "credits" or "license" for more information.Traceback (most recent call last):

which means that the interface for implementing "+" on the input types
"int" and "str" isn't implemented (i.e., TypeError). Weakly typed
languages allow this to work:

modelnine@gj-celle ~ $ php
<?php echo 1+'2'; ?>
3
modelnine@gj-celle ~ $

through all kinds of type-casting magic, which isn't explicitly
specified as interfaces on the objects (PHP also has integer and string
objects) themselves.

 

[Westley Martínez]

Strongly duck-typed though. If I create a class that has all the right
members, it can simultaneously be a file, an iterable, a database, and
probably even a web browser if it feels like it. Is that strong typing
or not?

Chris Angelico

It's strong typing. Python does not implicitly convert types. Weak typing is
when I can do 1 + "1" and get 2.

 

[MRAB]

It's strong typing. Python does not implicitly convert types. Weak typing is
when I can do 1 + "1" and get 2.

It could be argued that it does implicit convert for some numeric
types, eg int to float when needed.

 

[harrismh777]

The difference between strong typing and weak typing is best described by:

Python 2.6.5 (r265:79063, Jun 12 2010, 17:07:01)
[GCC 4.3.4 20090804 (release) 1] on cygwin
Type "help", "copyright", "credits" or "license" for more information.Traceback (most recent call last):

Yes. And you have managed to point out a serious flaw in the overall
logic and consistency of Python, IMHO.

Strings should auto-type-promote to numbers if appropriate.

This behavior should occur in input() as well. If a 'number' string is
entered and can be converted to a Python number (whatever I mean by that
at the moment) then the string should be converted to a number (int or
float as appropriate) and the input() should return a reference to the
number type ( a value ); otherwise, input() should return the string
entered, or throw a type error.

If an operation like (+) is used to add 1 + '1' then the string should
be converted to int and the addition should take place, returning a
reference to object int (2).


My feelings about this are strongly influenced by my experiences with
the REXX language on IBM's SAA systems--- OS/2 and VM/CMS. In REXX
everything is a string... everything. If a string just happens to be a
REXX number, then it can be manipulated as you might expect for a
number. Neither here, nor there... just that I believe Python could
take advantage of the "Python Number" concept and provide for auto-type
casting of string to number (int or float) as appropriate if the string
meets the Python Number requirements.

Just an idea... again, probably got beat up long before my time, I'm
guessing...


kind regards,
m harris

 

[Chris Angelico]

My feelings about this are strongly influenced by my experiences with the
REXX language on IBM's SAA systems--- OS/2 and VM/CMS. In REXX everything is
a string... everything. If a string just happens to be a REXX number, then
it can be manipulated as you might expect for a number.

Wow, someone else who knows REXX and OS/2! REXX was the first bignum
language I met, and it was really cool after working in BASIC and
80x86 assembly to suddenly be able to work with arbitrary-precision
numbers!

The "everything is a string, but treat it as a number if you like"
system is rather handy in a few places. I wanted it for my automated
DNS editor - I wanted to concatenate several numbers (from the date,
and the constant "1"), and then, if the resulting number is not
greater than another number (the previous serial), increment. Ahh
well...

I'm not so sure that all strings should autopromote to integer (or
"numeric" generally). However, adding a string and a number _should_
(IMHO) promote the number to string.

print "Hello, "+name+", you have "+credit+" dollars of credit with us."

Okay, that one is probably better done with the % operator, but it
definitely makes logical sense to concatenate numbers and strings as
strings, not to add them as numbers.

Chris Angelico

 

[Mel]

The difference between strong typing and weak typing is best described
by:

Python 2.6.5 (r265:79063, Jun 12 2010, 17:07:01)
[GCC 4.3.4 20090804 (release) 1] on cygwin
Type "help", "copyright", "credits" or "license" for more information.

1+'2'

Traceback (most recent call last):

Yes. And you have managed to point out a serious flaw in the overall
logic and consistency of Python, IMHO.

Strings should auto-type-promote to numbers if appropriate.

"Appropriate" is the problem. This is why Perl needs two completely
different kinds of comparison -- one that works as though its operands are
numbers, and one that works as though they're strings. Surprises to the
programmer who picks the wrong one.

Mel.

 

[Roy Smith]

Strings should auto-type-promote to numbers if appropriate.

"Appropriate" is the problem. This is why Perl needs two completely
different kinds of comparison -- one that works as though its operands are
numbers, and one that works as though they're strings. Surprises to the
programmer who picks the wrong one.[/QUOTE]

Ugh, tell me about it.

The project I'm currently working on used to use PHP (which has the same
auto-promotion semantics as Perl) as the front end to a SQL database.
The PHP code gleefully turned strings into numbers and back again all
over the place, but it all got cleaned up at the database interface
since SQL has strict typing.

We converted the back end database to MongoDB, which does not have
strict typing. We're still cleaning up the mess of inconsistent data
(i.e. string vs integer) that creeps into the database through various
paths. Not to mention 0 vs. '' vs null vs false.

Implicit type conversion can be convenient. But, then again, so can
removing the safety guards from a chain saw.

 

[Dennis Lee Bieber]

I'm not so sure that all strings should autopromote to integer (or
"numeric" generally). However, adding a string and a number _should_
(IMHO) promote the number to string.

print "Hello, "+name+", you have "+credit+" dollars of credit with us."

Okay, that one is probably better done with the % operator, but it
definitely makes logical sense to concatenate numbers and strings as
strings, not to add them as numbers.

But what if /I/ want
"A" + 1
to return
"B"

<G>

 

[flebber]

        But what if /I/ want
                "A" + 1
to return
                "B"

<G>

I like what you have done. Was it deliberate that your site teaches
python 2.x code rather than 3.x?

 

[Dotan Cohen]

Hey everyone.

I've written an online interactive Python tutorial atop Google App Engine: http://www.learnpython.org.

All you need to do is log in using your Google account and edit the wiki to add your tutorials.

Read more on the website.

Thanks for your help, and I would appreciate if you help me spread the word, and give me feedback on the website.

Nice work! I notice that the "Next Chapter" link does not work.

 

[rantingrick]

But what if /I/ want
                "A" + 1
to return
                "B"

No problem! Python even allows you to create your own functions! I
know, amazing! 8-O
return chr(ord(s) + 1)
'['

PS: The cases of (s > 255) or (s < 0) will be for the advanced reader
to solve.

 

[rantingrick]

Strings should auto-type-promote to numbers if appropriate.

No they should not! We do not want a language to "guess" our
intentions. We are big boys and girls and should be responsible for
own actions.

This behavior should occur in input() as well. If a 'number' string is
entered and can be converted to a Python number (whatever I mean by that
at the moment) then the string should be converted to a number (int or
float as appropriate) and the input() should return a reference to the
number type  ( a value );  otherwise, input() should return the string
entered, or throw a type error.

No, no, no! This is evil! That is what "eval" is for my friend.

If an operation like (+) is used to add  1 + '1' then the string should
be converted to int and the addition should take place, returning a
reference to object int (2).

My god man, have you gone completely insane? 8-O

 

[Dotan Cohen]

If an operation like (+) is used to add  1 + '1' then the string should be
converted to int and the addition should take place, returning a reference
to object int (2).

No, the int 1 should be cast to a string, and the result should be the
string '11'.