learnpython.org - an online interactive Python tutorial

Discussion in 'Python' started by Ron, Apr 20, 2011.

  1. Ron

    Ron Guest

    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.
     
    Ron, Apr 20, 2011
    #1
    1. Advertising

  2. Ron

    Matty Sarro Guest

    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!

    On Wed, Apr 20, 2011 at 1:15 PM, Ron <> wrote:
    > 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.
    > --
    > http://mail.python.org/mailman/listinfo/python-list
    >
     
    Matty Sarro, Apr 20, 2011
    #2
    1. Advertising

  3. Ron

    Terry Reedy Guest

    On 4/20/2011 1:15 PM, Ron wrote:

    > 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.

    --
    Terry Jan Reedy
     
    Terry Reedy, Apr 20, 2011
    #3
  4. On Thu, Apr 21, 2011 at 3:15 AM, Ron <> wrote:
    > 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 "&lt;string>", line 1, in &lt;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
     
    Chris Angelico, Apr 21, 2011
    #4
  5. On Thursday 21 April 2011 03:15:50 Ron wrote:
    > 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.


    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.
    --
    Algis
    http://akabaila.pcug.org.au/StructuralAnalysis.pdf
     
    Algis Kabaila, Apr 21, 2011
    #5
  6. On Thu, Apr 21, 2011 at 5:10 PM, Algis Kabaila <> wrote:
    > 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
     
    Chris Angelico, Apr 21, 2011
    #6
  7. Ron

    harrismh777 Guest

    Algis Kabaila wrote:
    >
    >
    > 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
     
    harrismh777, Apr 21, 2011
    #7
  8. Am 21.04.2011 09:19, schrieb Chris Angelico:
    > On Thu, Apr 21, 2011 at 5:10 PM, Algis Kabaila <> wrote:
    >> 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?


    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.
    >>> 1+'2'

    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    TypeError: unsupported operand type(s) for +: 'int' and 'str'
    >>>


    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.

    --
    --- Heiko.
     
    Heiko Wundram, Apr 21, 2011
    #8
  9. On Thu, Apr 21, 2011 at 05:19:29PM +1000, Chris Angelico wrote:
    > On Thu, Apr 21, 2011 at 5:10 PM, Algis Kabaila <> wrote:
    > > 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
    > --
    > http://mail.python.org/mailman/listinfo/python-list


    It's strong typing. Python does not implicitly convert types. Weak typing is
    when I can do 1 + "1" and get 2.
     
    Westley Martínez, Apr 21, 2011
    #9
  10. Ron

    MRAB Guest

    On 21/04/2011 15:14, Westley Martínez wrote:
    > On Thu, Apr 21, 2011 at 05:19:29PM +1000, Chris Angelico wrote:
    >> On Thu, Apr 21, 2011 at 5:10 PM, Algis Kabaila<> wrote:
    >>> 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
    >> --
    >> http://mail.python.org/mailman/listinfo/python-list

    >
    > 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.
     
    MRAB, Apr 21, 2011
    #10
  11. Ron

    harrismh777 Guest

    Heiko Wundram wrote:
    > 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):
    > File "<stdin>", line 1, in<module>
    > TypeError: unsupported operand type(s) for +: 'int' and 'str'
    >>>> >>>


    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
     
    harrismh777, Apr 22, 2011
    #11
  12. On Fri, Apr 22, 2011 at 4:38 PM, harrismh777 <> wrote:
    > 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
     
    Chris Angelico, Apr 22, 2011
    #12
  13. Ron

    Mel Guest

    harrismh777 wrote:

    > Heiko Wundram wrote:
    >> 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):
    >> File "<stdin>", line 1, in<module>
    >> TypeError: unsupported operand type(s) for +: 'int' and 'str'
    >>>>> >>>

    >
    > 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.
     
    Mel, Apr 22, 2011
    #13
  14. Ron

    Roy Smith Guest

    In article <iorui3$a9g$>, Mel <>
    wrote:

    > > 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.


    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.
     
    Roy Smith, Apr 22, 2011
    #14
  15. On Fri, 22 Apr 2011 17:08:53 +1000, Chris Angelico <>
    declaimed the following in gmane.comp.python.general:

    > 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>
    --
    Wulfraed Dennis Lee Bieber AF6VN
    HTTP://wlfraed.home.netcom.com/
     
    Dennis Lee Bieber, Apr 23, 2011
    #15
  16. Ron

    flebber Guest

    On Apr 23, 4:28 pm, Dennis Lee Bieber <> wrote:
    > On Fri, 22 Apr 2011 17:08:53 +1000, Chris Angelico <>
    > declaimed the following in gmane.comp.python.general:
    >
    > > 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>
    > --
    >         Wulfraed                 Dennis Lee Bieber         AF6VN
    >            HTTP://wlfraed.home.netcom.com/


    I like what you have done. Was it deliberate that your site teaches
    python 2.x code rather than 3.x?
     
    flebber, Apr 23, 2011
    #16
  17. Ron

    Dotan Cohen Guest

    On Wed, Apr 20, 2011 at 20:15, Ron <> wrote:
    > 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.
    > --
    > http://mail.python.org/mailman/listinfo/python-list
    >


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

    --
    Dotan Cohen

    http://gibberish.co.il
    http://what-is-what.com
     
    Dotan Cohen, Apr 23, 2011
    #17
  18. Ron

    rantingrick Guest

    On Apr 23, 1:28 am, Dennis Lee Bieber <> wrote:

    > 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

    >>> def succ(s):

    return chr(ord(s) + 1)

    >>> succ('a')

    'b'
    >>> succ('B')

    'C'
    >>> succ('Z')

    '['

    PS: The cases of (s > 255) or (s < 0) will be for the advanced reader
    to solve.
     
    rantingrick, Apr 23, 2011
    #18
  19. Ron

    rantingrick Guest

    On Apr 22, 1:38 am, harrismh777 <> wrote:

    > 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
     
    rantingrick, Apr 23, 2011
    #19
  20. Ron

    Dotan Cohen Guest

    On Fri, Apr 22, 2011 at 09:38, harrismh777 <> wrote:
    > 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'.

    --
    Dotan Cohen

    http://gibberish.co.il
    http://what-is-what.com
     
    Dotan Cohen, Apr 23, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    0
    Views:
    332
  2. Replies:
    0
    Views:
    327
  3. Replies:
    0
    Views:
    322
  4. PerlFAQ Server
    Replies:
    0
    Views:
    712
    PerlFAQ Server
    Feb 3, 2011
  5. PerlFAQ Server
    Replies:
    0
    Views:
    726
    PerlFAQ Server
    Apr 4, 2011
Loading...

Share This Page