Re: learnpython.org - an online interactive Python tutorial

2011-04-25 Thread harrismh777

Dave Angel wrote:

time echo scale = 1010; 16 * a(1/5) - 4 * a(1/239) |bc -lq




Wouldn't it be shorter to say:

time echo scale = 1010;  4 * a(1) |bc -lq


Well, you can check it out by doing the math... (its fun...)

...  you will notice that 'time' is called first, which on *nix systems 
clocks the processing, breaking out the system and user times... right?


... so try these 10,000 comparisons on your *nix system:

time echo scale = 10010; 16 * a(1/5) - 4 * a(1/239) |bc -lq

time echo scale = 10010;  4 * a(1) |bc -lq

(those will take a few minutes, if your processor is running 2-3Ghz...)

... then try these 100,000 runs:

time echo scale = 100010; 16 * a(1/5) - 4 * a(1/239) |bc -lq

time echo scale = 100010;  4 * a(1) |bc -lq

(Those will take some time, probably less than 20 - 30 minutes... )


After your time comparisons, tell me whether you want to use a(1)*4 ??

Leonard Euler came up with the formula I'm using here... and used it 
himself for paper 'n pencil arithmetic... because the arctan(n) infinite 
series converges much quicker (by orders of magnitude) for values of (n) 
 0.  (the smaller the (n) the better)


We can make the entire function run even faster by using smp and 
splitting the  'a(1/5)' and  'a(1/239)' across two cores, having the 
arctan series' running in parallel. This is important if your 'big num' 
is going to be hundreds of thousands or millions of places. On my baby 
Beowulf cluster I have played a bit with running this on two separate 
systems and then bringing the result together in the end... fun for 
playtime... interesting to see how many digits (in how much time) can be 
achieved *without* using a super-computer


You can also try these formula for comparison sake:

PI  =  20 * a(1/7) + 8 * a(3/79)
or
PI  =  8 * a(1/3) + 4 * a(1/7)
or
PI  =  24 * a(1/8) + 8 * a(1/57) + 4 * a(1/239)



Happy Easter,  and have a slice of pie on me   :)





kind regards,
m harris



--
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-25 Thread harrismh777

Steven D'Aprano wrote:

It seems to me that weak typing is a Do What I Mean function, and DWIM is
a notoriously bad anti-pattern that causes far more trouble than it is
worth. I'm even a little suspicious of numeric coercions between integer
and float. (But only a little.)


I'm wondering about that as well... (a little)... I mean, maybe the way 
to be really consistent (especially with the Zen of Python, explicit is 
better than implicit) that int -- float -- complex (imaginary) should 
not occur either !


I think folks would baulk at that though... big-time.   :)


So, bottom line here... if my students want to get numbers into their 
programs in 3.x then the correct way to handle the imput() would be:


n = int(input(enter num  ))


... and then let the interpreter throw an exception if the input 
cannot be type cast to int?



kind regards,
m harris


--
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-25 Thread Terry Reedy

On 4/25/2011 2:20 AM, harrismh777 wrote:

Steven D'Aprano wrote:

It seems to me that weak typing is a Do What I Mean function, and DWIM is
a notoriously bad anti-pattern that causes far more trouble than it is
worth. I'm even a little suspicious of numeric coercions between integer
and float. (But only a little.)


I'm wondering about that as well... (a little)... I mean, maybe the way
to be really consistent (especially with the Zen of Python, explicit is
better than implicit) that int -- float -- complex (imaginary) should
not occur either !

I think folks would baulk at that though... big-time. :)


Guido regards the number classes as subtypes of abstract number.
Given a==d, and b==e, he believes that after
c = a op b
f = d op e
then c == f should be true (in so far as possible).
This is why he wanted to change int division.

In other words, he wants Python math to pretty much imitate calculators,
on the basis that this is what most users expect and want.

This goes along with Python's general 
polymorphism/genericity/duck-typing philosophy. It is no different from 
the fact that one can write generic algorithms that give equivalent 
answers for equivalent inputs of ordered collections or indexable sequences.



So, bottom line here... if my students want to get numbers into their
programs in 3.x then the correct way to handle the imput() would be:

n = int(input(enter num  ))


Yes.


... and then let the interpreter throw an exception if the input cannot
be type cast to int?


Converted (not cast) to int or float or complex or anything else other 
than strl.


--
Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-25 Thread Gregory Ewing

harrismh777 wrote:
maybe the way 
to be really consistent (especially with the Zen of Python, explicit is 
better than implicit) that int -- float -- complex (imaginary) should 
not occur either !


Applying parts of the Zen selectively can be dangerous.
Practicality also beats purity. I've used a language
where there was no automatic promotion from ints to
floats, and it was a pain in the backside.

--
Greg
--
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-24 Thread Steven D'Aprano
On Sun, 24 Apr 2011 11:35:28 +1000, Chris Angelico wrote:

 On Sun, Apr 24, 2011 at 10:42 AM, Steven D'Aprano
 steve+comp.lang.pyt...@pearwood.info wrote:
 This is much like my experience with Apple's Hypertalk, where the only
 data structure is a string. I'm very fond of Hypertalk, but it is
 hardly designed with machine efficiency in mind. If you think Python is
 slow now, imagine how slow it would be if every expression had to be
 converted from a number back into a string, and vice versa, after every
 operation:

 x = str(int(1) + int(2))
 y = str(int(9)/int(3))
 z = str(int(x) - int(y))
 flag = str(int(z) == int(0))

 only implicitly, by the interpreter.
 
 Except that it wouldn't bother with a native integer implementation,
 would it? With a string-is-bignum system, it could simply do the
 arithmetic on the string itself, with no conversions at all.

I can assure you that Hypertalk had no BigNum system. This was in the 
days of Apple Mac when a standard int was 16 bits, although Hypertalk 
used 32 bit signed long ints.

But a text-string based bignum would be quite inefficient. Consider the 
relatively small number 256**100. Written out in a string it requires 240 
digits, with one byte per digit that's 240 bytes. Python stores longints 
in base 256, which requires 100 bytes (plus some overhead because it's an 
object):

 sys.getsizeof(256**100)
122

I suppose an implementation might choose to trade off memory for time, 
skipping string - bignum conversations at the cost of doubling the 
memory requirements. But even if I grant you bignums, you have to do the 
same for floats. Re-implementing the entire floating point library is not 
a trivial task, especially if you want to support arbitrary precision 
floats.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-24 Thread Chris Angelico
On Sun, Apr 24, 2011 at 6:13 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
 suppose an implementation might choose to trade off memory for time,
 skipping string - bignum conversations at the cost of doubling the
 memory requirements. But even if I grant you bignums, you have to do the
 same for floats. Re-implementing the entire floating point library is not
 a trivial task, especially if you want to support arbitrary precision
 floats.

Or just arbitrary precision decimal strings, which aren't floats at
all. But to be honest, I've never looked at any implementation of REXX
(and the open source implementations do seem to be inferior to IBM's
OS/2 implementation, I think - haven't done any empirical testing
though), so I can't say how it's done. But it seems to my small
understanding that it'd be simpler to just work with the base 10
string than to convert it to base 256 or base 2**32 or something, just
because you skip the conversions. Obviously this makes REXX a poor
choice for heavy HEAVY computation, but it's potentially faster for
things that involve a little computation and a lot of string
manipulation (which is where REXX does well).

Chris Angelico
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-24 Thread Steven D'Aprano
On Sat, 23 Apr 2011 22:10:47 -0500, harrismh777 wrote:

 I've been giving this some more thought. From the keyboard, all I am
 able to enter are character strings (not numbers). Presumably these are
 UTF-8 strings in python3.  If I enter the character string  57  then
 python converts my character string input and returns an reference to
 object 57.

That depends on where you enter it. If you enter it in between a pair of 
quotation marks, no conversion is done.

But I'll grant you that there are many places where the user/programmer 
communicates to the Python interpreter, and can generally only do so via 
characters or bytes. But that's hardly unique to numbers -- a dict is a 
rich compound data structure, but you can only create dicts by entering 
them as characters too. That's what we call syntax.

But the point is, once you have entered such a dict into the Python 
virtual machine:

d = {'spam': lambda x: x**2 + 3*x - 5, 42: ['a', 'b', 23, object(), []],
 17: (35, 19, True), 'x': {'cheese': 'cheddar'}, 
 'y': {'animal': 'aardvark'}, 'z': None}

Python no longer needs to convert it or its components back and forth 
between a string and the in-memory data structure. Converting to or from 
strings tend to be used in only a very few places:

* compiling from source code, including eval and exec;
* the interactive interpreter;
* some, but not all, serialization formats (e.g. JSON and YAML);
* printing the object repr;
* explicitly converting to string;

which is a big win for both speed and memory. You'll note that every 
single one of those is a special case of Input/Output.


[...]
 My idea for consistency is this: since the interpreter converts int
 to float, and float to imaginary (when needed), then it does (at least
 in a limited way) type promoting.

You are conflating lexing/parsing/compiling code with executing code. 
Just because you need to have a plumber install your water pipes when 
building a house, doesn't make it either practical or desirable to call a 
plumber in every time you want to turn a tap on.

I will grant that there are situations where a more implicit type 
conversion may be useful, or at least convenient. Perl does what you 
want, promoting strings to ints (and visa versa?) depending on what you 
try to do with them. Hypertalk, part of Apple's long defunct but not 
forgotten Hypercard, was deliberately designed to help non-programmers 
program. And I've sometimes experimented with config file formats that do 
similar things. So it's not that I think that weak typing in the REXX/
Hypertalk/Perl sense is always wrong, only that it's wrong for Python.

On the other hand, both Flash and Javascript also do weak typing, and the 
results in practice can be confusing and fraught with problems:

http://nedbatchelder.com/blog/200708/two_weak_typing_problems.html

And I think this quote from Peter Wone is amusing:

Weak typing such as is used in COM Variants was an early attempt to 
solve this problem, but it is fraught with peril and frankly causes more 
trouble than it's worth. Even Visual Basic programmers, who will put up 
with all sorts of rubbish, correctly pegged this as a bad idea and 
backronymed Microsoft's ETC (Extended Type Conversion) to Evil Type Cast.

http://stackoverflow.com/questions/597664/when-should-weak-types-be-discouraged


It seems to me that weak typing is a Do What I Mean function, and DWIM is 
a notoriously bad anti-pattern that causes far more trouble than it is 
worth. I'm even a little suspicious of numeric coercions between integer 
and float. (But only a little.)



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Re: learnpython.org - an online interactive Python tutorial

2011-04-24 Thread Dave Angel

On 01/-10/-28163 02:59 PM, harrismh777 wrote:

Cameron Simpson wrote:

| folks are not aware that 'bc' also has arbitrary precision floating
| point math and a standard math library.

Floating point math? I thought, historically at least, that bc is built
on dc (arbitrary precision integer math, reverse polish syntax) and that
consequently bc uses fixed point math rather than floating point.


My bad... I don't mean under-the-covers... I mean that the user may
calculate arbitrary precision floating arithmetic ... bc keeps track of
the decimal point and displays the number of digits the user specifies;
arbitrary precision calculator. (loose language, sorry)

On a *nix system, Mac OSx, Linux, run this to get 1000+ digits of PI:

time echo scale = 1010; 16 * a(1/5) - 4 * a(1/239) |bc -lq



scale sets the precision, -lq loads the math library arctan() quiet.





Wouldn't it be shorter to say:

time echo scale = 1010;  4 * a(1) |bc -lq

DaveA
--
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-24 Thread jmfauth
On 24 avr, 05:10, harrismh777 harrismh...@charter.net wrote:

     I've been giving this some more thought. From the keyboard, all I am
 able to enter are character strings (not numbers). Presumably these are
 UTF-8 strings in python3.  If I enter ...


In Python 3, input() returns a unicode, a sequence/table/array of
unicode code point(s). No more, no less.

Similar to Python 2 where raw_input() returns a sequence/table/array
of byte(s). No more, no less.

jmf
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-23 Thread flebber
On Apr 23, 4:28 pm, Dennis Lee Bieber wlfr...@ix.netcom.com wrote:
 On Fri, 22 Apr 2011 17:08:53 +1000, Chris Angelico ros...@gmail.com
 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
         wlfr...@ix.netcom.com    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?
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-23 Thread Dotan Cohen
On Wed, Apr 20, 2011 at 20:15, Ron ron.rei...@gmail.com 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
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-23 Thread rantingrick
On Apr 23, 1:28 am, Dennis Lee Bieber wlfr...@ix.netcom.com 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.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-23 Thread rantingrick
On Apr 22, 1:38 am, harrismh777 harrismh...@charter.net 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
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-23 Thread Dotan Cohen
On Fri, Apr 22, 2011 at 09:38, harrismh777 harrismh...@charter.net 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
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-23 Thread Tim Chase

On 04/23/2011 11:51 AM, Dotan Cohen wrote:

harrismh777harrismh...@charter.net  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'.


Oh, come on...clearly if you're adding mixed types, there's 
significance to the difference, so the result should obviously be 
the complex number


  (1+1j)

Or maybe it should be the tuple

  (1,1)

Or did I mean the list

 [1,1]

It's all so obvious...  :)

I didn't mind the auto-promotion (as much) in VB6 when I had an 
explicit concat operator


  1  1   ' returns 11

vs

  1 + 1   ' returns 2

-tkc




--
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-23 Thread Westley Martínez
On Fri, Apr 22, 2011 at 04:48:39PM -0700, Dan Stromberg wrote:
 On Thu, Apr 21, 2011 at 11:38 PM, harrismh777 harrismh...@charter.netwrote:
 
 
  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.
 
 
 Please no.  It's a little more convenient sometimes when you're coding, but
 it adds bugs that aren't worth the small benefit.
 
 Explicit is better than implicit.
 
 http://www.python.org/dev/peps/pep-0020/

We have tcl for this anyways.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-23 Thread harrismh777

Chris Angelico wrote:

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!


Yes, my big num research stuff was initially done in REXX, on VM/CMS. 
I later ported my libraries over to OS/2 and continued with that well 
into the '90s, when I discovered Unix and 'bc'.  Many folks are not 
aware that 'bc' also has arbitrary precision floating point math and a 
standard math library. It is much faster than REXX because the libraries 
are written in C, and unlike REXX they do not have to be implemented in 
the interpreter. The syntax of 'bc' is C-like, which is its only 
down-side for new students who have never had any language training. 
REXX was a great business language, particularly when CMS Pipelines was 
introduced.


Just for fun, and a trip down memory lane, you can take a look at some 
of my ancient REXX code... this code is a REXX math library designed to 
be used from the command line,  written in REXX. The primary scientific 
functions were implemented, as well as some code to calculate PI... 
most of the algorithms can be ported to 'bc' easily, but the 'bc' 
algorithms will run much faster, of course.


Back in the day, REXX was the 'new BASIC'

... now I use Python.


//
//
/** COMPUTE COMMAND LINE SCIENTIFIC CALCULATOR **/
//
//
/****/
/**   IBM Corporation  **/
/**   HARRISMH at RCHVMP2  **/
/**   EL8/663-1 B627   **/
/**   Rochester, MN  55901 **/
/****/
/**   AUTHOR:  Marcus Harris   **/
/** DATE:  93/10/22 ( port from VM/CMS )   **/
/**   UPDATE:  98/03/07**/
/**  VER:  2.0a**/
/****/
//
//
/**  syntax**/
/****/
/**  COMPUTE  expression;expression;expression@digits**/
/****/
/****/
/**  The expression(s) will be computed and displayed in terminal  **/
/**  line mode to arbitrary @digits of accuracy. **/
/****/
/**  The expression(s) may be any REXX math clause and may include **/
/**  a variable assignment, for use in a subsequent expression:**/
/**  ie.,  COMPUTE A=3;B=7;A/B;A*B@30  **/
/**(will compute both the quotient and product of A  B)   **/
/****/
//
//
/**  NOTES **/
/****/
/**  COMPUTE  expression;expression;expression@digits**/
/****/
/**  This program exploits Rexx  INTERPRET and NUMERIC DIGITS  **/
/****/
/**  This exec is portable to OS/2, NT and w95 Rexx/objectRexx **/
/**  without changes.  **/
/****/
//
//
/**  updates   **/
/** 93/10/21 mhh New Program  (port from VM/CMS)   **/
/** 98/03/07 mhh New Version 2.0a  **/
/**  This version includes trigonometric, logarithmic, **/
/**  exponential and combinatorial functions.  **/
/****/
/**  See the REXROOTS ABOUT file for a discussion  **/
/**  of the included 

Re: learnpython.org - an online interactive Python tutorial

2011-04-23 Thread Steven D'Aprano
On Fri, 22 Apr 2011 01:38:21 -0500, 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, inmodule
 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.

If that's a serious flaw, it's a flaw shared by the vast majority of 
programming languages.

As for the question of consistency, I would argue the opposite: that 
auto-promoting strings to numbers arguably is useful, but that is what is 
inconsistent, not the failure to do so.

Consider...

one + 1

Should this also promote one to integer 1? If so, what about uno and 
un and ein and один? 

If not, why privilege one *string* representation of the number 1 over 
other *string* representations of the number 1?

How about this?

[1, 2, 3] + [4]

Should that auto-promote to a list as well? If not, why not? Why does 
your argument in favour of auto-promotion to int also not apply to auto-
promotion to list?

What about this?

[2, 40, 10, 3].sort()

Should that auto-promote to list? Should the result of sorting be 
[2, 3, 10, 40] or ['10', '2', '3', '40']? 

What about:

[2, 4, 1, 3].index([)

Should that call the *string* index method, or the *list* index method?


If you want to argue that auto-promoting of strings to numbers is 
convenient for lazy programmers who can't be bothered keeping the 
distinction between strings and numbers straight, or for those who can't 
base the extra typing required to call int() but don't mind the 
inefficiency of the language repeatedly converting numbers to and from 
strings in the background, then I'd agree that the convenience argument 
is an argument in favour of weak-typing. (Not necessarily a *good* 
argument, but it's an argument.)

But I hope it is clear that consistency is not an argument in favour of 
weak-typing. As far as I know, no language applies weak-typing broadly to 
all types, and if a language did, it would be fraught with problems and 
traps.


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

This is much like my experience with Apple's Hypertalk, where the only 
data structure is a string. I'm very fond of Hypertalk, but it is hardly 
designed with machine efficiency in mind. If you think Python is slow 
now, imagine how slow it would be if every expression had to be converted 
from a number back into a string, and vice versa, after every operation:

x = str(int(1) + int(2))
y = str(int(9)/int(3))
z = str(int(x) - int(y))
flag = str(int(z) == int(0))

only implicitly, by the interpreter.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-23 Thread Chris Angelico
On Sun, Apr 24, 2011 at 10:42 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
 This is much like my experience with Apple's Hypertalk, where the only
 data structure is a string. I'm very fond of Hypertalk, but it is hardly
 designed with machine efficiency in mind. If you think Python is slow
 now, imagine how slow it would be if every expression had to be converted
 from a number back into a string, and vice versa, after every operation:

 x = str(int(1) + int(2))
 y = str(int(9)/int(3))
 z = str(int(x) - int(y))
 flag = str(int(z) == int(0))

 only implicitly, by the interpreter.

Except that it wouldn't bother with a native integer implementation,
would it? With a string-is-bignum system, it could simply do the
arithmetic on the string itself, with no conversions at all.

Re harrismh's code: For that sort of work, I used and still use the
REXXTry program that comes with OS/2 (written, I believe, by Mike
Cowlishaw), with a modified input routine that gives readline-style
capabilities. Dragging this vaguely back on topic, the end result is
rather similar in feel to IDLE or Hilfe (Pike's interactive
interpreter).

Chris Angelico
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-23 Thread Cameron Simpson
On 23Apr2011 19:37, harrismh777 harrismh...@charter.net wrote:
[...]
| Yes, my big num research stuff was initially done in REXX, on
| VM/CMS. I later ported my libraries over to OS/2 and continued with
| that well into the '90s, when I discovered Unix and 'bc'.  Many
| folks are not aware that 'bc' also has arbitrary precision floating
| point math and a standard math library.

Floating point math? I thought, historically at least, that bc is built
on dc (arbitrary precision integer math, reverse polish syntax) and that
consequently bc uses fixed point math rather than floating point.

Cheers,
-- 
Cameron Simpson c...@zip.com.au DoD#743
http://www.cskk.ezoshosting.com/cs/

From sci.physics:
t...@mailzone.com:
  The only problem is, how do you send a message from Earth to Mars
  instantly?  Does anyone have any ideas about where we can start?
John Baez b...@math.mit.edu:
  Just use a coordinate system in which the point at which the message is
  received has the same t coordinate as the point at which the message was sent.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-23 Thread harrismh777

Cameron Simpson wrote:

| folks are not aware that 'bc' also has arbitrary precision floating
| point math and a standard math library.

Floating point math? I thought, historically at least, that bc is built
on dc (arbitrary precision integer math, reverse polish syntax) and that
consequently bc uses fixed point math rather than floating point.


My bad... I don't mean under-the-covers... I mean that the user may 
calculate arbitrary precision floating arithmetic ... bc keeps track of 
the decimal point and displays the number of digits the user specifies; 
arbitrary precision calculator.  (loose language, sorry)


On a *nix system, Mac OSx, Linux, run this to get 1000+ digits of PI:

time echo scale = 1010; 16 * a(1/5) - 4 * a(1/239) |bc -lq



scale sets the precision,  -lq  loads the math library arctan() quiet.


--
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-23 Thread harrismh777

Steven D'Aprano wrote:

If that's a serious flaw, it's a flaw shared by the vast majority of
programming languages.


   Yes, agreed.


As for the question of consistency, I would argue the opposite: that
auto-promoting strings to numbers arguably is useful, but that is what is
inconsistent, not the failure to do so.


   I see your point...  but I'll push back just a little, in a minute...



Consider...

one + 1

[1, 2, 3] + [4]

[2, 40, 10, 3].sort()


   Yes, maybe problems all. Again, I see the point of your argument, 
and I do not necessarily disagree...


   I've been giving this some more thought. From the keyboard, all I am 
able to enter are character strings (not numbers). Presumably these are 
UTF-8 strings in python3.  If I enter the character string  57  then 
python converts my character string input and returns an reference to 
object 57.  If I enter the keyboard character string 34567 then the 
python interpreter converts my character string input into an object 
(creates a new object) (34567) returning a reference to that object (a 
type int). If I enter the keyboard character string 3.14 the python 
interpreter creates a float object (converts my string into a float) and 
returns a reference to the object. In any event, keyboard character 
strings that just happen to be numbers, are converted into int or float 
objects by the interpreter, from the keyboard, automatically.
   My idea for consistency is this: since the interpreter converts int 
to float, and float to imaginary (when needed), then it does (at least 
in a limited way) type promoting. So, it is consistent with the input 
methods generally to promote numeric string input to int -- float -- 
imaginary, as needed, therefore it is also consistent to promote a 
numeric string (that which I used to call a REXX number) into an int -- 
float -- imaginary, as implied by the statement(s). I am not asking for 
weak typing generally... nor am I thinking that all promotions are a 
good thing... just numeric string to int -- float -- imaginary when it 
makes sense. In any event, the programmer should be able to overide the 
behavior explicitly. On the other hand, I do see your point regarding 
performance. Otherwise,...


   ... type promotions really would not cause any more confusion for 
programmers who now know that int will be converted to float and use 
that knowledge conveniently


   I do believe that explicit is better than implicit (generally)... 
but not in this case. I am noticing a pattern in some of the responses, 
and that pattern is that some folks would find this appealing if not 
overtly convenient. The question IS, which I am not able to answer at 
this point, whether the convenience would actually cause other 
difficulties that would be worse...?



kind regards,
m harris




--
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-22 Thread harrismh777

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, inmodule
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



--
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-22 Thread Chris Angelico
On Fri, Apr 22, 2011 at 4:38 PM, harrismh777 harrismh...@charter.net 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
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-22 Thread Mel
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, inmodule
 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.

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-22 Thread Roy Smith
In article iorui3$a9g$1...@speranza.aioe.org, Mel mwil...@the-wire.com 
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.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-22 Thread Dan Stromberg
On Thu, Apr 21, 2011 at 11:38 PM, harrismh777 harrismh...@charter.netwrote:


 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.


Please no.  It's a little more convenient sometimes when you're coding, but
it adds bugs that aren't worth the small benefit.

Explicit is better than implicit.

http://www.python.org/dev/peps/pep-0020/
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-21 Thread Algis Kabaila
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.

[quote]
Python is completely object oriented, and not strongly typed
[/quote]

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
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-21 Thread Chris Angelico
On Thu, Apr 21, 2011 at 5:10 PM, Algis Kabaila akaba...@pcug.org.au 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


Re: learnpython.org - an online interactive Python tutorial

2011-04-21 Thread harrismh777

Algis Kabaila wrote:

[quote]
Python is completely object oriented, and not strongly typed
[/quote]

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
--
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-21 Thread Heiko Wundram
Am 21.04.2011 09:19, schrieb Chris Angelico:
 On Thu, Apr 21, 2011 at 5:10 PM, Algis Kabaila akaba...@pcug.org.au 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.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

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


Re: learnpython.org - an online interactive Python tutorial

2011-04-21 Thread MRAB

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 Kabailaakaba...@pcug.org.au  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.
--
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-21 Thread Dan Stromberg
On Thu, Apr 21, 2011 at 9:13 AM, MRAB pyt...@mrabarnett.plus.com wrote:

 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 Kabailaakaba...@pcug.org.au
  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.


Yes, it'll silently promote int to float, int to Decimal, and also almost
anything can be used in a Boolean context.  No other exceptions to strong
typing come to mind...
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-21 Thread Diego Arias
On Thu, Apr 21, 2011 at 8:20 PM, Dan Stromberg drsali...@gmail.com wrote:


 On Thu, Apr 21, 2011 at 9:13 AM, MRAB pyt...@mrabarnett.plus.com wrote:

 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 Kabailaakaba...@pcug.org.au
  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.


 Yes, it'll silently promote int to float, int to Decimal, and also almost
 anything can be used in a Boolean context.  No other exceptions to strong
 typing come to mind...


 --
 http://mail.python.org/mailman/listinfo/python-list

 Hi:

Really nice site, keep it going


-- 
Still Going Strong!!!
-- 
http://mail.python.org/mailman/listinfo/python-list


learnpython.org - an online interactive Python tutorial

2011-04-20 Thread 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.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-20 Thread 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!

On Wed, Apr 20, 2011 at 1:15 PM, Ron ron.rei...@gmail.com 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

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-20 Thread Ron
Thanks! :)
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-20 Thread FELD Boris
Excellent idea,

I've some ideas on specific subjects misunderstood by beginners.

One idea for facilitating the contribution, create a mercurial repository (or a 
git), everyone has not a google account and your contributors will be 
developers so they should use a SCM.

Once again, it's an excellent idea and, when the tutorials were expanded 
enough, i should be good to integrate it with python.org website (but it's more 
a dream than something else...)

One question, if i want to write a tutorial about import mechanism, how can i 
manage the file system ?

Nice work !
-- 
FELD Boris
Sent with Sparrow
On mercredi 20 avril 2011 at 19:57, Matty Sarro wrote: 
 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 ron.rei...@gmail.com 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
 -- 
 http://mail.python.org/mailman/listinfo/python-list
 
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-20 Thread Terry Reedy

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

--
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-20 Thread Chris Angelico
On Thu, Apr 21, 2011 at 3:15 AM, Ron ron.rei...@gmail.com 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
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: learnpython.org - an online interactive Python tutorial

2011-04-20 Thread Yico Gaga
 well ,i can't visit your website ,required time out ,maybe it's the GFW'S
problem ~

2011/4/21 Ron ron.rei...@gmail.com

 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

-- 
http://mail.python.org/mailman/listinfo/python-list