Re: Guido on python3 for beginners

[Larry Hudson via Python-list]

On 02/19/2016 06:36 PM, Steven D'Aprano wrote:

On Fri, 19 Feb 2016 02:39 pm, Rustom Mody wrote:


[snip]


But you can't do anything interesting with this language, so it is not
satisfying. On the other hand, here's "Hello World" in another language,
one which is Turing complete so it can do anything Python or C can do:

(=<`#9]~6ZY32Vx/4Rs+0No-)"Fh}|Bcy?`=*z]Kw%oG4UUS0/@-ejc(:'8dc

but the learning curve is steep enough that it will be frustrating rather
than interesting.

https://en.wikipedia.org/wiki/Malbolge



Somewhat OT, but speaking of "Hello World", check out:

http://www2.latech.edu/~acm/HelloWorld.shtml

It's a collection of "Hello World" programs in umpteen languages.
(Well, not really umpteen, but there are a lot of them.)   ;-)

 -=- Larry -=-

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

Re: Guido on python3 for beginners

[Steven D'Aprano]

On Thu, 18 Feb 2016 07:40 pm, Terry Reedy wrote:

> 8. 2.x has two subtlely different types of classes.  The 2.x docs do not
> document the type of builtin and stdlib classes. I discovered that
> tkinter classes are still old-style in 2.7 when I backported a patch
> from 3.x to 2.7 and it mysteriously did not work. Py 3 wins here.  To
> me, this alone makes 2.x a bad choice for most beginners.

An excellent point!


> 11.  To test is something is text, isinstance s, c), where 'c' is one of
> str, bytes, unicode, basestring, (bytes, unicode), (str, unicode).  +1
> for 3.x.

In Python 3, it should be much rarer to want to test whether something is
unicode or bytes. You can't combine them easily, so you rarely want to
handle them in identical ways.


> 12. 2.7 has two different open' functions, open and io.open.  In 3.x
> these are the same opjects.  I believe there are other 3.x backports
> like this.

There's also codecs.open().





-- 
Steven

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

Re: Guido on python3 for beginners

[Steven D'Aprano]

On Fri, 19 Feb 2016 02:39 pm, Rustom Mody wrote:

> Consider as hypothesis
> L1: Needs 4 weeks to master

A language that only takes 4 weeks to master, starting from zero programming
experience, clearly doesn't include much in the way of features.


> L2: Needs 4 years to manage (if you want to make it less hypothetical
> think C++)

Do you mean 4 years to *master*?

Generally speaking, it takes 10 years of experience to become a master of a
complex skill. You might learn all the syntax of C++ in 4 years, but that
doesn't mean you have mastered the language :-)


> Which would be more satisfying to a student?

To be satisfying, a language needs to have a shallow enough learning curve
that the student can make good progress right from the beginning, and
enough features that they can actually do interesting things. Here's a
language that a student can learn in about one minute, because it only has
two features:

Assignment:

LET x = 99

Printing:

print x


But you can't do anything interesting with this language, so it is not
satisfying. On the other hand, here's "Hello World" in another language,
one which is Turing complete so it can do anything Python or C can do:

(=<`#9]~6ZY32Vx/4Rs+0No-)"Fh}|Bcy?`=*z]Kw%oG4UUS0/@-ejc(:'8dc

but the learning curve is steep enough that it will be frustrating rather
than interesting.

https://en.wikipedia.org/wiki/Malbolge




-- 
Steven

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

Re: Guido on python3 for beginners

[Grant Edwards]

On 2016-02-19, Steven D'Aprano  wrote:

> Pascal was easy to learn and powerful, but it made the mistake of not
> standardising on a few critical functions that production languages need,
> like strings. Nevertheless, for the first 10 or 15 years, Apple used a mix
> of Pascal and assembly to write not just the operating system but a whole
> lot of applications for the Macintosh. Anyone who says that Pascal is a toy
> language is just ignorant.

At one point, Pascal was quite popular for emedded systems
(e.g. microprocessor) development also.  One of my first projects out
of school back in the early 80's was working on cell-site radio
firmware (Zilog Z8000 uP).

There were a few small extensions to the standard langage to deal with
the fact it was low-level code running on bare metal, but it was quite
a nice language for writing stuff for small microprocessor-based
systems.  After you debugged everything, you could turn off
array-bounds-checking, and the extra overhead compared to something
like C vanished.

-- 
Grant Edwards   grant.b.edwardsYow! HAIR TONICS, please!!
  at   
  gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Guido on python3 for beginners

[Rustom Mody]

On Friday, February 19, 2016 at 6:48:12 AM UTC+5:30, Steven D'Aprano wrote:

> 
> 
> But apart from that, I think that "teaching" versus "doing" language is a
> false dichotomy. Teaching languages should have a shallow learning curve
> (easy to get started and learn the language, easy discoverability).
> Production languages should have deep functionality and power. Those two
> are not *necessarily* opposed[1]. Good languages should have both: a
> shallow learning curve leading to deep functionality.
> 
> [1] Except in the trivial sense that the more you have to learn, the longer
> it will take.

Consider as hypothesis
L1: Needs 4 weeks to master
L2: Needs 4 years to manage (if you want to make it less hypothetical think C++)

Which would be more satisfying to a student?
[Not a hypothetical question: Some people like to go 
mountaineering/bungee-jumping etc
and breaks their necks.
Likewise Ive seen students who were so C++-happy they failed other courses!

I'd hazard you have forgotten what it feels like to be a student by some 
decades :-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Guido on python3 for beginners

[Rustom Mody]

On Thursday, February 18, 2016 at 9:22:10 PM UTC+5:30, Random832 wrote:
> On Thu, Feb 18, 2016, at 07:25, Rustom Mody wrote:
> > My beef is somewhat different: viz that post 70s (Pascal) and 80s
> > (scheme) 
> > programming pedagogy has deteriorated with general purpose languages
> > replacing
> > 'teaching-purpose language' for teaching.
> 
> The flaw in this idea is right there in your post. Both languages you
> named are strongly tied to a single paradigm (procedural for Pascal, and
> functional for Scheme) which don't match the paradigm that real-world
> work is done in. 

Factually incorrect.
Scheme is as multi-paradigm as you can get -- SICP spends considerable time
building OO systems, machine architectures etc
Culturally is another matter -- scheme tends to draw FP aficionados as python 
seems to draw OO ones.  The languages do not mandate this

> Is there a new "teaching-purpose language"?

No And that's the deterioration in the programming edu-world

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

Re: Guido on python3 for beginners

[Steven D'Aprano]

On Fri, 19 Feb 2016 02:51 am, Random832 wrote:

> On Thu, Feb 18, 2016, at 07:25, Rustom Mody wrote:
>> My beef is somewhat different: viz that post 70s (Pascal) and 80s
>> (scheme)
>> programming pedagogy has deteriorated with general purpose languages
>> replacing
>> 'teaching-purpose language' for teaching.
> 
> The flaw in this idea is right there in your post. Both languages you
> named are strongly tied to a single paradigm (procedural for Pascal, and
> functional for Scheme) which don't match the paradigm that real-world
> work is done in. Is there a new "teaching-purpose language"?


Scratch seems very popular for teaching young children. If I were 10, I
would definitely check it out. The emphasis is on writing re-usable code
snippets, collaboration, and graphics and animation.

https://scratch.mit.edu/


But apart from that, I think that "teaching" versus "doing" language is a
false dichotomy. Teaching languages should have a shallow learning curve
(easy to get started and learn the language, easy discoverability).
Production languages should have deep functionality and power. Those two
are not *necessarily* opposed[1]. Good languages should have both: a
shallow learning curve leading to deep functionality.

Pascal was easy to learn and powerful, but it made the mistake of not
standardising on a few critical functions that production languages need,
like strings. Nevertheless, for the first 10 or 15 years, Apple used a mix
of Pascal and assembly to write not just the operating system but a whole
lot of applications for the Macintosh. Anyone who says that Pascal is a toy
language is just ignorant.




[1] Except in the trivial sense that the more you have to learn, the longer
it will take.


-- 
Steven

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

Re: Guido on python3 for beginners

[Sven R. Kunze]

On 18.02.2016 07:59, Paul Rubin wrote:

Steven D'Aprano  writes:

I suppose that it is objectively correct that it is harder to learn
than Python 2. But I don't think the learning curve is any steeper. If
anything, the learning curve is ever-so-slightly less steep.

I think py3 has more learning curve because it uses iterators in places
where py2 uses lists.  That's a significant new concept and it can be
bug-prone even for programmers who are experienced with it.



That is indeed very true.


Best,
Sven
--
https://mail.python.org/mailman/listinfo/python-list

Re: Guido on python3 for beginners

[John Ladasky]

On Wednesday, February 17, 2016 at 11:28:17 PM UTC-8, Chris Angelico wrote:

> 5) print statement/function. Py3 forces you to put parentheses on it,
> which is no different from C's printf() or Pike's write() or any
> number of other languages where console I/O needs no language support.
> Maybe a tiny TINY advantage to Py2 in the short term, but as soon as
> you introduce the less basic features, keyword arguments are way
> better than the magic syntax the statement needs. (Also, trying to
> explain the interaction between the print statement's "soft space" and
> other console I/O is not easy.) By the time you've really learned the
> language, the advantage belongs to Py3.

Another advantage to the Py3 print function over the Py2 print statement is 
that it makes redirecting output SO much easier.  If I write a function that 
might sometimes print output to the console, and might at some other time print 
to a GUI window, or to a log file, I can just pass in the relevant output 
function name as an argument to my own function.  

This is very helpful, and I use it often.  I teach my new Python students to 
write their application's core logic, without regards to any GUI.  Later, when 
I teach them to use a GUI, building it is easier because the process is modular.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Guido on python3 for beginners

[Matt Wheeler]

On Thu, 18 Feb 2016 11:07 Chris Angelico  wrote:

> By the way... For bash users, adding this to .bashrc may make venvs a
> bit easier to keep straight:
>
> checkdir() {
> [ -n "$VIRTUAL_ENV" ] && ! [[ `pwd` =~ `dirname $VIRTUAL_ENV`* ]]
> && echo Deactivating venv $VIRTUAL_ENV... && deactivate
> [ -z "$VIRTUAL_ENV" -a -d env ] && echo Activating venv
> `pwd`/env... && source env/bin/activate
> }
> PROMPT_COMMAND=checkdir
>
> (I'm more fluent in Python than in bash, so this is a bit ugly.)
>
> As soon as you change out of the directory that contains your venv,
> it'll be deactivated, so you can't accidentally run stuff in the
> "wrong" environment. And as soon as you change into a directory that
> contains an 'env' subdir, it'll activate it. (Also applies on first
> creation; as soon as "python3 -m venv env" returns, this will activate
> the env.)
>

This is a bad idea for the same reason enabling all magic comments in your
editor is a bad idea.
(rvm does this but confirms that the rvmrc it's about to activate is one
that you've previously approved, I wouldn't want to try to write a shell
function that did that though :)).

>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Guido on python3 for beginners

[Random832]

On Thu, Feb 18, 2016, at 07:25, Rustom Mody wrote:
> My beef is somewhat different: viz that post 70s (Pascal) and 80s
> (scheme) 
> programming pedagogy has deteriorated with general purpose languages
> replacing
> 'teaching-purpose language' for teaching.

The flaw in this idea is right there in your post. Both languages you
named are strongly tied to a single paradigm (procedural for Pascal, and
functional for Scheme) which don't match the paradigm that real-world
work is done in. Is there a new "teaching-purpose language"?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Guido on python3 for beginners

[Rustom Mody]

On Thursday, February 18, 2016 at 12:17:26 PM UTC+5:30, Steven D'Aprano wrote:
> On Wednesday 17 February 2016 19:51, Rustom Mody wrote:
> 
> > I hope someone can help me find this link: There is some record that Guido
> > has said that python3 is probably a bit harder on noobs than python2.
> > 
> > Does anyone know/have that link?
> 
> 
> I can't say that I've seen it. I know that Raymond Hettinger is not too fond 
> of adding new syntactic features that add little in the way of power but 
> make the language harder to learn, but I don't recall anyone saying that it 
> is harder for newbies to get started with Python 3 than Python 2.
> 
> There are more features in Python 3, so in that trivial sense of "more to 
> learn", I suppose that it is objectively correct that it is harder to learn 
> than Python 2. But I don't think the learning curve is any steeper. If 
> anything, the learning curve is ever-so-slightly less steep.
> 
> 
Thanks Steven!
So its Raymond Hettinger... Good enough

So now I find your earlier post:
https://mail.python.org/pipermail/python-list/2015-March/688387.html

Obviously google was not obliging when I searched for Guido :-)

BTW I have no tongs in this 2 vs 3 fire -- I'll leave that to Rick jmf and other
noble gentry.

My beef is somewhat different: viz that post 70s (Pascal) and 80s (scheme) 
programming pedagogy has deteriorated with general purpose languages replacing
'teaching-purpose language' for teaching.

Which is about as intelligent as calling Martha[1] and Rose[2] both pianists

[1] https://www.youtube.com/watch?v=YLZLp6AcAi4
[2] https://www.youtube.com/watch?v=_bjKDJD-CLc
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Guido on python3 for beginners

[Chris Angelico]

On Thu, Feb 18, 2016 at 9:57 PM, Cem Karan  wrote:
> I agree with Chris on all his points.  My personal feeling is that Py3 is the 
> way to go for teaching in the future; its just that little bit more 
> consistent across the board.  And the things that are confusing are not 
> things that beginners will need to know about.
>
> About the only thing I've read where Py2 has a slight advantage is for 
> scripts where you're suddenly surprised by Py2 starting up when you've been 
> using a Py3 interactive interpreter.  For me, I'd probably give my students a 
> block of code that they are asked to copy at the start of their files to test 
> for Py2 or Py3, and to raise an exception on Py2.  After that, I just 
> wouldn't worry about it.
>

Another solution is to have a little bit of boilerplate at the shell first:

python3 -m venv env
source env/bin/activate

Then both "python" and "python3" will run the binary from your virtual
environment, and as a side bonus, you get to use pip without root
privileges.

By the way... For bash users, adding this to .bashrc may make venvs a
bit easier to keep straight:

checkdir() {
[ -n "$VIRTUAL_ENV" ] && ! [[ `pwd` =~ `dirname $VIRTUAL_ENV`* ]]
&& echo Deactivating venv $VIRTUAL_ENV... && deactivate
[ -z "$VIRTUAL_ENV" -a -d env ] && echo Activating venv
`pwd`/env... && source env/bin/activate
}
PROMPT_COMMAND=checkdir

(I'm more fluent in Python than in bash, so this is a bit ugly.)

As soon as you change out of the directory that contains your venv,
it'll be deactivated, so you can't accidentally run stuff in the
"wrong" environment. And as soon as you change into a directory that
contains an 'env' subdir, it'll activate it. (Also applies on first
creation; as soon as "python3 -m venv env" returns, this will activate
the env.)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Guido on python3 for beginners

[Cem Karan]

On Feb 18, 2016, at 4:57 AM, Chris Angelico  wrote:

> On Thu, Feb 18, 2016 at 7:40 PM, Terry Reedy  wrote:
>> To my mind, the numerous duplications and overlaps in 2.7 that are gone in
>> 3.x make 2.7 the worse version ever for beginners.
> 
> Hmm. I was teaching on 2.7 up until last year, and for the most part,
> we taught a "compatible with Py3" subset of the language, without any
> significant cost. If you'd shown code saying "except ValueError, e:"
> to one of my Py2 students then, s/he would have been just as
> unfamiliar as one of my Py3 students would be today. That said,
> though, it's still that Py3 is no worse than Py2, and potentially
> better.
> 
> The removal of L suffixes (and, similarly, the removal of u"..."
> prefixes on text strings) is a bigger deal to newbies than it is to
> experienced programmers, so that one definitely counts. "This is
> great, but how can I remove that u from the strings?" was a common
> question (eg when they're printing out a list of strings obtained from
> a database, or decoded from JSON).
> 
> The removal of old-style classes is a definite improvement in Py3, as
> is the no-arg form of super(), which I'd consider a related change. So
> there's a bunch of tiny little "quality of life" improvements here.
> 
> ChrisA

I agree with Chris on all his points.  My personal feeling is that Py3 is the 
way to go for teaching in the future; its just that little bit more consistent 
across the board.  And the things that are confusing are not things that 
beginners will need to know about.

About the only thing I've read where Py2 has a slight advantage is for scripts 
where you're suddenly surprised by Py2 starting up when you've been using a Py3 
interactive interpreter.  For me, I'd probably give my students a block of code 
that they are asked to copy at the start of their files to test for Py2 or Py3, 
and to raise an exception on Py2.  After that, I just wouldn't worry about it.

Thanks,
Cem Karan
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Guido on python3 for beginners

[Chris Angelico]

On Thu, Feb 18, 2016 at 7:40 PM, Terry Reedy  wrote:
> To my mind, the numerous duplications and overlaps in 2.7 that are gone in
> 3.x make 2.7 the worse version ever for beginners.

Hmm. I was teaching on 2.7 up until last year, and for the most part,
we taught a "compatible with Py3" subset of the language, without any
significant cost. If you'd shown code saying "except ValueError, e:"
to one of my Py2 students then, s/he would have been just as
unfamiliar as one of my Py3 students would be today. That said,
though, it's still that Py3 is no worse than Py2, and potentially
better.

The removal of L suffixes (and, similarly, the removal of u"..."
prefixes on text strings) is a bigger deal to newbies than it is to
experienced programmers, so that one definitely counts. "This is
great, but how can I remove that u from the strings?" was a common
question (eg when they're printing out a list of strings obtained from
a database, or decoded from JSON).

The removal of old-style classes is a definite improvement in Py3, as
is the no-arg form of super(), which I'd consider a related change. So
there's a bunch of tiny little "quality of life" improvements here.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Guido on python3 for beginners

[Terry Reedy]

On 2/18/2016 2:27 AM, Chris Angelico wrote:

On Thu, Feb 18, 2016 at 5:47 PM, Steven D'Aprano
 wrote:

There are more features in Python 3, so in that trivial sense of "more to
learn", I suppose that it is objectively correct that it is harder to learn
than Python 2. But I don't think the learning curve is any steeper. If
anything, the learning curve is ever-so-slightly less steep.


Let's see... changes in Py3.

1) Division of two integers now yields a float instead of flooring.
For someone fresh to programming, that's a Py3 advantage, although it
can cause surprises elsewhere. But since 1.0==1, it's not going to be
a problem for a new programmer. Advantage: Py3.

2) Strings are Unicode text, and files etc may need to have their
encodings declared. Definitely causes some issues in ASCII-only
situations, where a lot of other languages (notably including PHP, for
the people building web sites) let you be sloppy. Advantage: Py3 if
you speak any language other than English; otherwise Py2 in the very
short term, neither in the medium term, and most definitely Py3 in the
long term (no more "funny characters break my program" errors long
after deployment).

3) Laziness. When you explain to someone what the range() function
does, Py2 makes a list, but Py3 makes... a range. It doesn't really
answer the question at all. When you ask Py2 for a dictionary's
keys/values, you get a list; Py3 gives you a thing that mostly acts
like a list, only it isn't. If you map a function over a list, you get
back a lazy thing that will eventually call that function. Py2 often
has less levels of indirection, ergo less things to try to explain.
Advantage: Py2; the benefits (lower memory usage, etc) aren't
significant to new users.

4) Exception chaining. You get more information when errors cascade.
Advantage: Py3, easily and without any question.

5) print statement/function. Py3 forces you to put parentheses on it,
which is no different from C's printf() or Pike's write() or any
number of other languages where console I/O needs no language support.
Maybe a tiny TINY advantage to Py2 in the short term, but as soon as
you introduce the less basic features, keyword arguments are way
better than the magic syntax the statement needs. (Also, trying to
explain the interaction between the print statement's "soft space" and
other console I/O is not easy.) By the time you've really learned the
language, the advantage belongs to Py3.

6) The fact that the name "python" may not invoke the interpreter you
want. Advantage: Py2, if any; there'll be times when they're on par,
but Py3 never comes out ahead.

7) Whether or not the interpreter comes pre-installed on your system.
As of a few years ago, that was a clear advantage to Py2 (most systems
would ship with both, or neither, or Py2 only), but that's shifting.
It's only a small difference, though; on Windows, you generally get
nothing, and on any system with a decent package manager, you should
be able to request either version with ease.

It's actually a pretty tough call. Most of the Py3 advantages aren't
for the absolute beginner; it's not easier to write "Hello, world" in
Py3, and aside from the change to integer division, most of the
changes won't benefit small-to-medium scripts either. The biggest
advantage (Unicode by default) really only shows itself by sparing you
hassles later on - it's not going to make your life easier in the
short term, ergo it's not going to make the language easier to learn.
Py3 isn't so much easier as _better_. There are specific situations
where it's massively better, but for the most part, they're about on
par.


8. 2.x has two subtlely different types of classes.  The 2.x docs do not 
document the type of builtin and stdlib classes. I discovered that 
tkinter classes are still old-style in 2.7 when I backported a patch 
from 3.x to 2.7 and it mysteriously did not work. Py 3 wins here.  To 
me, this alone makes 2.x a bad choice for most beginners.


9. Two integer classes and the nuisance of 'L' suffix.  Py 3 wins for 
beginners, at least.  (Mentioned by Inaki).


10. Two except-clause syntaxes in 2.7, just one in 3.x.  -1 syntax is 
+1 vote for 3.x


11.  To test is something is text, isinstance s, c), where 'c' is one of 
str, bytes, unicode, basestring, (bytes, unicode), (str, unicode).  +1 
for 3.x.


12. 2.7 has two different open' functions, open and io.open.  In 3.x 
these are the same opjects.  I believe there are other 3.x backports 
like this.


13. 2.7 has two ways to apply arguments to functions: apply and *args. 
3.x only has the latter.


To my mind, the numerous duplications and overlaps in 2.7 that are gone 
in 3.x make 2.7 the worse version ever for beginners.



--
Terry Jan Reedy

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

Re: Guido on python3 for beginners

[INADA Naoki]

In Python 3, I don't required to teach followings to newbies.

1. Don't do `class Foo:`, do `class Foo(object):`.
2. Don't do `isinstance(x, int)`, do `isinstance(x, (int, long))`.
3. Don't return non-ASCII string from `__repr__`, otherwise UnicodeError
   happens in logging and you will lost your important log.
4. Use %r instead of %s in logging to avoid UnicodeError when __str__
returns non ASCII strings.

I think there are many pitfalls fixed in Python 3 other than above.
Python 3 is far easier to teach and review code than Python 2.


On Thu, Feb 18, 2016 at 4:27 PM, Chris Angelico  wrote:

> On Thu, Feb 18, 2016 at 5:47 PM, Steven D'Aprano
>  wrote:
> > There are more features in Python 3, so in that trivial sense of "more to
> > learn", I suppose that it is objectively correct that it is harder to
> learn
> > than Python 2. But I don't think the learning curve is any steeper. If
> > anything, the learning curve is ever-so-slightly less steep.
>
> Let's see... changes in Py3.
>
> 1) Division of two integers now yields a float instead of flooring.
> For someone fresh to programming, that's a Py3 advantage, although it
> can cause surprises elsewhere. But since 1.0==1, it's not going to be
> a problem for a new programmer. Advantage: Py3.
>
> 2) Strings are Unicode text, and files etc may need to have their
> encodings declared. Definitely causes some issues in ASCII-only
> situations, where a lot of other languages (notably including PHP, for
> the people building web sites) let you be sloppy. Advantage: Py3 if
> you speak any language other than English; otherwise Py2 in the very
> short term, neither in the medium term, and most definitely Py3 in the
> long term (no more "funny characters break my program" errors long
> after deployment).
>
> 3) Laziness. When you explain to someone what the range() function
> does, Py2 makes a list, but Py3 makes... a range. It doesn't really
> answer the question at all. When you ask Py2 for a dictionary's
> keys/values, you get a list; Py3 gives you a thing that mostly acts
> like a list, only it isn't. If you map a function over a list, you get
> back a lazy thing that will eventually call that function. Py2 often
> has less levels of indirection, ergo less things to try to explain.
> Advantage: Py2; the benefits (lower memory usage, etc) aren't
> significant to new users.
>
> 4) Exception chaining. You get more information when errors cascade.
> Advantage: Py3, easily and without any question.
>
> 5) print statement/function. Py3 forces you to put parentheses on it,
> which is no different from C's printf() or Pike's write() or any
> number of other languages where console I/O needs no language support.
> Maybe a tiny TINY advantage to Py2 in the short term, but as soon as
> you introduce the less basic features, keyword arguments are way
> better than the magic syntax the statement needs. (Also, trying to
> explain the interaction between the print statement's "soft space" and
> other console I/O is not easy.) By the time you've really learned the
> language, the advantage belongs to Py3.
>
> 6) The fact that the name "python" may not invoke the interpreter you
> want. Advantage: Py2, if any; there'll be times when they're on par,
> but Py3 never comes out ahead.
>
> 7) Whether or not the interpreter comes pre-installed on your system.
> As of a few years ago, that was a clear advantage to Py2 (most systems
> would ship with both, or neither, or Py2 only), but that's shifting.
> It's only a small difference, though; on Windows, you generally get
> nothing, and on any system with a decent package manager, you should
> be able to request either version with ease.
>
> It's actually a pretty tough call. Most of the Py3 advantages aren't
> for the absolute beginner; it's not easier to write "Hello, world" in
> Py3, and aside from the change to integer division, most of the
> changes won't benefit small-to-medium scripts either. The biggest
> advantage (Unicode by default) really only shows itself by sparing you
> hassles later on - it's not going to make your life easier in the
> short term, ergo it's not going to make the language easier to learn.
> Py3 isn't so much easier as _better_. There are specific situations
> where it's massively better, but for the most part, they're about on
> par.
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>



-- 
INADA Naoki  
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Guido on python3 for beginners

[Chris Angelico]

On Thu, Feb 18, 2016 at 5:47 PM, Steven D'Aprano
 wrote:
> There are more features in Python 3, so in that trivial sense of "more to
> learn", I suppose that it is objectively correct that it is harder to learn
> than Python 2. But I don't think the learning curve is any steeper. If
> anything, the learning curve is ever-so-slightly less steep.

Let's see... changes in Py3.

1) Division of two integers now yields a float instead of flooring.
For someone fresh to programming, that's a Py3 advantage, although it
can cause surprises elsewhere. But since 1.0==1, it's not going to be
a problem for a new programmer. Advantage: Py3.

2) Strings are Unicode text, and files etc may need to have their
encodings declared. Definitely causes some issues in ASCII-only
situations, where a lot of other languages (notably including PHP, for
the people building web sites) let you be sloppy. Advantage: Py3 if
you speak any language other than English; otherwise Py2 in the very
short term, neither in the medium term, and most definitely Py3 in the
long term (no more "funny characters break my program" errors long
after deployment).

3) Laziness. When you explain to someone what the range() function
does, Py2 makes a list, but Py3 makes... a range. It doesn't really
answer the question at all. When you ask Py2 for a dictionary's
keys/values, you get a list; Py3 gives you a thing that mostly acts
like a list, only it isn't. If you map a function over a list, you get
back a lazy thing that will eventually call that function. Py2 often
has less levels of indirection, ergo less things to try to explain.
Advantage: Py2; the benefits (lower memory usage, etc) aren't
significant to new users.

4) Exception chaining. You get more information when errors cascade.
Advantage: Py3, easily and without any question.

5) print statement/function. Py3 forces you to put parentheses on it,
which is no different from C's printf() or Pike's write() or any
number of other languages where console I/O needs no language support.
Maybe a tiny TINY advantage to Py2 in the short term, but as soon as
you introduce the less basic features, keyword arguments are way
better than the magic syntax the statement needs. (Also, trying to
explain the interaction between the print statement's "soft space" and
other console I/O is not easy.) By the time you've really learned the
language, the advantage belongs to Py3.

6) The fact that the name "python" may not invoke the interpreter you
want. Advantage: Py2, if any; there'll be times when they're on par,
but Py3 never comes out ahead.

7) Whether or not the interpreter comes pre-installed on your system.
As of a few years ago, that was a clear advantage to Py2 (most systems
would ship with both, or neither, or Py2 only), but that's shifting.
It's only a small difference, though; on Windows, you generally get
nothing, and on any system with a decent package manager, you should
be able to request either version with ease.

It's actually a pretty tough call. Most of the Py3 advantages aren't
for the absolute beginner; it's not easier to write "Hello, world" in
Py3, and aside from the change to integer division, most of the
changes won't benefit small-to-medium scripts either. The biggest
advantage (Unicode by default) really only shows itself by sparing you
hassles later on - it's not going to make your life easier in the
short term, ergo it's not going to make the language easier to learn.
Py3 isn't so much easier as _better_. There are specific situations
where it's massively better, but for the most part, they're about on
par.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Guido on python3 for beginners

[Random832]

On Thu, Feb 18, 2016, at 01:47, Steven D'Aprano wrote:
> There are more features in Python 3, so in that trivial sense of "more to 
> learn", I suppose that it is objectively correct that it is harder to
> learn 
> than Python 2. But I don't think the learning curve is any steeper. If 
> anything, the learning curve is ever-so-slightly less steep.

I wonder if (with one of the major differences being the unicode thing)
there is a differences between the learning curve for people whose
primary prior experience is with languages that use byte strings for
text (such as perl, [as typically used] C, shell/awk/etc, PHP, python 2)
vs languages that use some form of unicode string (UTF-8 byte strings on
a platform whose default encoding is also UTF-8 don't count) for text
(such as java, C#, javascript).

I feel like the unicode string stuff (issues like encodings etc) is
something that you only have to learn _once_, and then if you really
understand it then for a new language you can just look up how to do it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Guido on python3 for beginners

[Paul Rubin]

Steven D'Aprano  writes:
> I suppose that it is objectively correct that it is harder to learn
> than Python 2. But I don't think the learning curve is any steeper. If
> anything, the learning curve is ever-so-slightly less steep.

I think py3 has more learning curve because it uses iterators in places
where py2 uses lists.  That's a significant new concept and it can be
bug-prone even for programmers who are experienced with it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Guido on python3 for beginners

[Ben Finney]

Steven D'Aprano  writes:

> There are more features in Python 3, so in that trivial sense of "more to 
> learn", I suppose that it is objectively correct that it is harder to learn 
> than Python 2. But I don't think the learning curve is any steeper.

Set against the “more features in Python 3” is the “more inconsistencies
and cruft in Python 2”.

How to weigh those objectively is beyond me, but my experience is that
the inconsistencies in Python 2 make it more difficult for newcomers
than Python 3.

> If anything, the learning curve is ever-so-slightly less steep.

Yes. The language Python 3 is more consistent with fewer historical edge
cases the beginner needs to know; and the new features don't have to be
learned all at once. Both of which mean that the newcomer has an easier
time in Python 3.

-- 
 \ “Not to perambulate the corridors in the hours of repose in the |
  `\  boots of ascension.” —ski hotel, Austria |
_o__)  |
Ben Finney

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

Re: Guido on python3 for beginners

[Steven D'Aprano]

On Wednesday 17 February 2016 19:51, Rustom Mody wrote:

> I hope someone can help me find this link: There is some record that Guido
> has said that python3 is probably a bit harder on noobs than python2.
> 
> Does anyone know/have that link?


I can't say that I've seen it. I know that Raymond Hettinger is not too fond 
of adding new syntactic features that add little in the way of power but 
make the language harder to learn, but I don't recall anyone saying that it 
is harder for newbies to get started with Python 3 than Python 2.

There are more features in Python 3, so in that trivial sense of "more to 
learn", I suppose that it is objectively correct that it is harder to learn 
than Python 2. But I don't think the learning curve is any steeper. If 
anything, the learning curve is ever-so-slightly less steep.


-- 
Steve

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

Guido on python3 for beginners

[Rustom Mody]

On Tuesday, February 16, 2016 at 10:54:43 AM UTC+5:30, John Ladasky wrote:
> On Monday, February 15, 2016 at 6:02:24 PM UTC-8, Rick Johnson wrote:
> > I don't need Python3. And i reckon that by the time i do, 
> > something more interesting will come along, or, i'll create 
> > something more interesting myself. i've been drafting, and 
> > dreaming, of a new language spec for over a year now.. And 
> > the best thing about starting a new language, you can do 
> > anything you want... no dependencies! 
> 
> If you have all the skills that you claim, you're a far better programmer 
> than I.  So -- exactly why are you complaining to people who are developing 
> and/or using Py3?  Go off and impress everyone.  Become your own BDFL.

I hardly want to enter a 'who-can-fart-loudest' contest with Rick...
I hope someone can help me find this link: There is some record that Guido has
said that python3 is probably a bit harder on noobs than python2.

Does anyone know/have that link?
-- 
https://mail.python.org/mailman/listinfo/python-list