Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #102415 > unrolled thread

[STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO

Back to article view | Back to comp.lang.python

Contents

  [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO Rick Johnson <rantingrickjohnson@gmail.com> - 2016-02-02 19:26 -0800
    Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO John Ladasky <john_ladasky@sbcglobal.net> - 2016-02-02 22:02 -0800
      Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO Bernardo Sulzbach <mafagafogigante@gmail.com> - 2016-02-03 04:07 -0200
      Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO Rick Johnson <rantingrickjohnson@gmail.com> - 2016-02-06 12:54 -0800
        Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO INADA Naoki <songofacandy@gmail.com> - 2016-02-07 12:02 +0900
          Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-02-07 16:59 +1100
            Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO Paul Rubin <no.email@nospam.invalid> - 2016-02-06 23:04 -0800
              Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO Rustom Mody <rustompmody@gmail.com> - 2016-02-06 23:31 -0800
                Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO Paul Rubin <no.email@nospam.invalid> - 2016-02-06 23:51 -0800
                  Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO Chris Angelico <rosuav@gmail.com> - 2016-02-07 18:58 +1100
                  Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO Jason Swails <jason.swails@gmail.com> - 2016-02-08 10:20 -0500
              Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO Christian Gollwitzer <auriocus@gmx.de> - 2016-02-07 08:44 +0100
        Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO Chris Angelico <rosuav@gmail.com> - 2016-02-07 14:06 +1100
        Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO Ian Kelly <ian.g.kelly@gmail.com> - 2016-02-08 08:40 -0700
        Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO Random832 <random832@fastmail.com> - 2016-02-08 10:44 -0500
          Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO wxjmfauth@gmail.com - 2016-02-09 01:15 -0800
        Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO Chris Angelico <rosuav@gmail.com> - 2016-02-09 02:46 +1100
        Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO Random832 <random832@fastmail.com> - 2016-02-08 10:53 -0500
        Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO Chris Warrick <kwpolska@gmail.com> - 2016-02-08 18:48 +0100
        Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO John Ladasky <john_ladasky@sbcglobal.net> - 2016-02-11 23:51 -0800
          Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO Rick Johnson <rantingrickjohnson@gmail.com> - 2016-02-15 18:02 -0800
            Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO Chris Angelico <rosuav@gmail.com> - 2016-02-16 13:30 +1100
            Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO John Ladasky <john_ladasky@sbcglobal.net> - 2016-02-15 21:24 -0800
              Guido on python3 for beginners Rustom Mody <rustompmody@gmail.com> - 2016-02-17 00:51 -0800
                Re: Guido on python3 for beginners Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-02-18 17:47 +1100
                  Re: Guido on python3 for beginners Ben Finney <ben+python@benfinney.id.au> - 2016-02-18 17:57 +1100
                  Re: Guido on python3 for beginners Paul Rubin <no.email@nospam.invalid> - 2016-02-17 22:59 -0800
                    Re: Guido on python3 for beginners "Sven R. Kunze" <srkunze@mail.de> - 2016-02-18 22:37 +0100
                  Re: Guido on python3 for beginners Random832 <random832@fastmail.com> - 2016-02-18 02:00 -0500
                  Re: Guido on python3 for beginners Chris Angelico <rosuav@gmail.com> - 2016-02-18 18:27 +1100
                    Re: Guido on python3 for beginners John Ladasky <john_ladasky@sbcglobal.net> - 2016-02-18 12:22 -0800
                  Re: Guido on python3 for beginners INADA Naoki <songofacandy@gmail.com> - 2016-02-18 17:00 +0900
                  Re: Guido on python3 for beginners Terry Reedy <tjreedy@udel.edu> - 2016-02-18 03:40 -0500
                    Re: Guido on python3 for beginners Steven D'Aprano <steve@pearwood.info> - 2016-02-20 18:59 +1100
                  Re: Guido on python3 for beginners Chris Angelico <rosuav@gmail.com> - 2016-02-18 20:57 +1100
                  Re: Guido on python3 for beginners Cem Karan <cfkaran2@gmail.com> - 2016-02-18 05:57 -0500
                  Re: Guido on python3 for beginners Chris Angelico <rosuav@gmail.com> - 2016-02-18 22:07 +1100
                  Re: Guido on python3 for beginners Rustom Mody <rustompmody@gmail.com> - 2016-02-18 04:25 -0800
                    Re: Guido on python3 for beginners Random832 <random832@fastmail.com> - 2016-02-18 10:51 -0500
                      Re: Guido on python3 for beginners Steven D'Aprano <steve@pearwood.info> - 2016-02-19 12:17 +1100
                        Re: Guido on python3 for beginners Rustom Mody <rustompmody@gmail.com> - 2016-02-18 19:39 -0800
                          Re: Guido on python3 for beginners Steven D'Aprano <steve@pearwood.info> - 2016-02-20 13:36 +1100
                            Re: Guido on python3 for beginners Larry Hudson <orgnut@yahoo.com> - 2016-02-20 00:37 -0800
                        Re: Guido on python3 for beginners Grant Edwards <invalid@invalid.invalid> - 2016-02-19 15:06 +0000
                      Re: Guido on python3 for beginners Rustom Mody <rustompmody@gmail.com> - 2016-02-18 19:32 -0800
                  Re: Guido on python3 for beginners Matt Wheeler <m@funkyhat.org> - 2016-02-18 16:44 +0000
              Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO wxjmfauth@gmail.com - 2016-02-17 08:39 -0800
            Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO Christian Gollwitzer <auriocus@gmx.de> - 2016-02-18 22:14 +0100
              Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO Chris Angelico <rosuav@gmail.com> - 2016-02-19 08:54 +1100
            Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO Ian Kelly <ian.g.kelly@gmail.com> - 2016-02-18 21:07 -0700
              Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO wxjmfauth@gmail.com - 2016-02-19 02:18 -0800
    Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO Wolfgang Maier <wolfgang.maier@biologie.uni-freiburg.de> - 2016-02-03 09:27 +0100
    Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO Grobu <snailcoder@retrosite.invalid> - 2016-02-03 09:38 +0100
      Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO wxjmfauth@gmail.com - 2016-02-03 09:16 -0800
    Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO Quivis <quivis@domain.invalid> - 2016-02-06 14:59 +0000
    Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO Ethan Furman <ethan@stoneleaf.us> - 2016-02-18 18:22 -0800
      Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-02-19 10:05 +0000
    Re: [STORY-TIME] THE BDFL AND HIS PYTHON PETTING ZOO Terry Reedy <tjreedy@udel.edu> - 2016-02-19 23:15 -0500

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#102979

On Friday, February 12, 2016 at 1:51:35 AM UTC-6, John Ladasky wrote:

Reguarding a migration from Python2 to Pyhton3, John said:
>  I had to wait until my favorite packages were ported
> (numpy, scipy, matplotlib, pandas).

WxPython is not ported either, much to my chagrin.

> But once that happened, I moved from Py2 to Py3 years ago
> with scarcely a bump, bruise, or scratch.

So you have no Python2.x code remaining in your repos? Are
you telling us that you moved *EVERYTHING* to Python3? If
so, i can't imagine how something like that would even be
possible, hmm, unless of course, you don't have much code to
move...?

I could imagine that *IF* someone's entire Python repo
consisted of a couple hundred (or less) small scripts, with
few, or no, dependencies, such a migration would be
relatively easy. But even though i've only been writing
Python code for a handful of years, my repo consists of
thousands of scripts, millions of lines of code, and many,
*MANY* dependencies -- because after all, DRY is very
important, yes?

(That reminds me, i need to write a script to compile some
statistics on these files...)

> I like lazy evaluation.

Well, it is a "Pythonic feature" no doubt. And I'll admit,
many of the changes are "good changes". But they are not
good enough to risk blowing up millions of lines of code,
John. And what will i gain if i did? Nothing. There are *NO*
new features to offer my users, and even the features that
*WOULD* improve my coding experiences, are not enough to
warrant the misery.Heck, almost all of these festures i
could implement myself.

What's easier: migrating millions of lines into a hostile
environment just so i can gain a few new functionalities, or
writing a few lines to bring the needed functionalities to
*ME*? I don't need, nor do i want, *EVERYTHING* that Python3
brings to the table.

> I think that Unicode handling is vastly improved (and yes,
> I'm fully aware that exactly two people in this newsgroup
> don't agree, they make sure we all know).  I have
> encountered few surprises, and nothing that makes my job
> harder.

Well John, not everyone is going to experience the same
"level of onerous" when they port their code over to
Python3. Perhaps your case is unique. And there is no way
for myself, or anyone one else, to make an objective
judgment, without looking at the breath and depth of the code
you had to migrate.

Perhaps you don't have a lot of dependencies. Perhaps you
have not engineered "feature-rich libraries". Perhaps you
have have not written code that is on the bleeding edge, or
pushed your mental power to it's extremes. Perhaps your code
style is to "play it safe". Perhaps you're scripts consist
mostly of simple maintenance and utilities.

So even if you "believe" that the migration from Python2.x
to Python3.x is smooth, you're only able to make that
judgment relative to own *PERSONAL* experience, with your
own *PERSONAL* library.

So even though there is only two people in this group who
don't care for Pyhton Unicode handling (hey, your stats, not
mine!), there is only *ONE* of you who can judge the level
of onerous required to migrate *YOUR* code! Until you make
the depth and breath of you repo publicly view-able, your
opinion is just that -- an *OPINION*!

As for me, I've written vast libraries over the top of
wxPython and Tkinter. I've extended existing functionality,
added new functionality, and created a more consistent and
intuitive API than either library could have dreamed. I've
spent many long hours debugging, testing, and perfecting
these libraries, and so far, they work very nicely. Heck, my
refactored Tkinter API, and IDLE editor, is leaps and bounds
ahead of anything Python3 could manage to do. And it's a
shame too, because these two libraries are among some of the
oldest and most neglected of all.

But now i'm faced with a tough choice: (1) I could attempt
to migrate all these libraries, and risk mountains of subtle bugs
echoing down the inheritance/dependency chains, or (2) I
could leave the code where it is, and milk-it until the
majority of OS's will no longer run Python2.

JUST FYI: I'M GOING WITH CHOICE NUMBER TWO!

Why? Because only a fool would risk "exception hell" on code
that has been stable for a reasonable amount of time. Ever
heard the expression: "if it ain't broke, don't fix it"?
Well my code ain't broke, and until it becomes broken, my
time would be better spent forging new paths, instead of
flogging the old ones like dead, quadrupedaled, "beasts of
burden"!

> To be sure, people who are entrenched in the Py2 way of
> doing things, with a lot of legacy code, have some work to
> do -- on their code, and possibly on their brains.

Your "veiled ad hominem" is not justified John.With that
statement, you've just insulted well over half of the Python
community -- and the "better half", i might add! You're
talking about people who have been coding python, and many
other languages, probably long before you were even born!
I'm not as "curmudgeonly" as some folks around here, but i'm
no "spring chicken" either. Hurling personal attack just
because people don't gush over your beloved Pyhton3 is a
low-blow.

> Keep Py2 if you want it, then.  You still have a few more
> years before the PSF stops maintaining it.  If you really
> like it that much, why not maintain it yourself?

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!

[toc] | [prev] | [next] | [standalone]

#102982

On Tue, Feb 16, 2016 at 1:02 PM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
>> But once that happened, I moved from Py2 to Py3 years ago
>> with scarcely a bump, bruise, or scratch.
>
> So you have no Python2.x code remaining in your repos? Are
> you telling us that you moved *EVERYTHING* to Python3? If
> so, i can't imagine how something like that would even be
> possible, hmm, unless of course, you don't have much code to
> move...?

I have one project that's bound to Py2 by its one dependency, and I've
kept it Py3-compatible apart from the one block of code that sets that
up. (That includes renaming a function that was originally called
"await", even though that's not actually a keyword as of 3.6.) All the
rest of my code will run on Python 3. However, there is still a lot of
Python 2 code in my repos - it's the same code! Most of my stuff is
simple enough that I keep it 2/3 compatible. Sometimes there's a block
of code at the top to deal with {raw_,}input or a future directive or
a changed import name, but the bulk of the code is unchanged.

Of course, now that I go to actually *check*, it turns out that a lot
of my code has accidentally not been cross-version compatible. I use
the open(fn, encoding="...") form in quite a few places, so to make
that work, I would need "from io import open" (which seems to be a
safe no-op on Py3), and there are places where I use multi-arg
versions of print, which will end up displaying tuples in Py2 if I
don't slap in a __future__ directive. But that just means that I
really truly have *moved* to Python 3, to the extent that I don't
always even test my code on 2.7 any more.

ChrisA

[toc] | [prev] | [next] | [standalone]

#102986

On Monday, February 15, 2016 at 6:02:24 PM UTC-8, Rick Johnson wrote:
> On Friday, February 12, 2016 at 1:51:35 AM UTC-6, John Ladasky wrote:
> 
> Reguarding a migration from Python2 to Pyhton3, John said:
> >  I had to wait until my favorite packages were ported
> > (numpy, scipy, matplotlib, pandas).
> 
> WxPython is not ported either, much to my chagrin.

I was a big fan of WxPython myself.  I waited for Phoenix for a while, then decided to learn PyQt5.  Having been exposed to both GUI's ways of doing things, I'm not sure which I prefer.  I never liked Tkinter.

> > But once that happened, I moved from Py2 to Py3 years ago
> > with scarcely a bump, bruise, or scratch.
> 
> So you have no Python2.x code remaining in your repos? Are
> you telling us that you moved *EVERYTHING* to Python3? If
> so, i can't imagine how something like that would even be
> possible, hmm, unless of course, you don't have much code to
> move...?
>
> I could imagine that *IF* someone's entire Python repo
> consisted of a couple hundred (or less) small scripts, with
> few, or no, dependencies, such a migration would be
> relatively easy. But even though i've only been writing
> Python code for a handful of years, my repo consists of
> thousands of scripts, millions of lines of code, and many,
> *MANY* dependencies -- because after all, DRY is very
> important, yes?

It's true, I only have about 25,000 lines of code.  My largest program suite is only about 10% of that.  And indeed, it's now all in Py3. The 2to3 utility took care of most of my porting needs.  Yes, I aspire to the DRY principle.  I've written a few packages which extend Numpy's behavior in specific ways which I've re-used many times.

I acknowledge that there's a vocal group of Py2 users who have decided that it's too much trouble to switch.  The PSF has decided that its energies are better expended on growing Py3 than on maintaining Py2 for that diminishing user base.

But no one owns Python.  There is no law that states that Py2 adherents cannot maintain the language themselves, if they want it.  Sheesh.  Just do it.  Make it yours.  

Or make something better if you want.  You state:

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

Cheers.

[toc] | [prev] | [next] | [standalone]

#103047 — Guido on python3 for beginners

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?

[toc] | [prev] | [next] | [standalone]

#103088 — Re: Guido on python3 for beginners

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

[toc] | [prev] | [next] | [standalone]

#103089 — Re: Guido on python3 for beginners

Steven D'Aprano <steve+comp.lang.python@pearwood.info> 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

[toc] | [prev] | [next] | [standalone]

#103090 — Re: Guido on python3 for beginners

Steven D'Aprano <steve+comp.lang.python@pearwood.info> 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.

[toc] | [prev] | [next] | [standalone]

#103151 — Re: Guido on python3 for beginners

On 18.02.2016 07:59, Paul Rubin wrote:
> Steven D'Aprano <steve+comp.lang.python@pearwood.info> 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

[toc] | [prev] | [next] | [standalone]

#103091 — Re: Guido on python3 for beginners

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.

[toc] | [prev] | [next] | [standalone]

#103092 — Re: Guido on python3 for beginners

On Thu, Feb 18, 2016 at 5:47 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> 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

[toc] | [prev] | [next] | [standalone]

#103148 — Re: Guido on python3 for beginners

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.

[toc] | [prev] | [next] | [standalone]

#103094 — Re: Guido on python3 for beginners

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 <rosuav@gmail.com> wrote:

> On Thu, Feb 18, 2016 at 5:47 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> 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  <songofacandy@gmail.com>

[toc] | [prev] | [next] | [standalone]

#103096 — Re: Guido on python3 for beginners

On 2/18/2016 2:27 AM, Chris Angelico wrote:
> On Thu, Feb 18, 2016 at 5:47 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> 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

[toc] | [prev] | [next] | [standalone]

#103247 — Re: Guido on python3 for beginners

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

[toc] | [prev] | [next] | [standalone]

#103100 — Re: Guido on python3 for beginners

On Thu, Feb 18, 2016 at 7:40 PM, Terry Reedy <tjreedy@udel.edu> 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

[toc] | [prev] | [next] | [standalone]

#103105 — Re: Guido on python3 for beginners

On Feb 18, 2016, at 4:57 AM, Chris Angelico <rosuav@gmail.com> wrote:

> On Thu, Feb 18, 2016 at 7:40 PM, Terry Reedy <tjreedy@udel.edu> 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

[toc] | [prev] | [next] | [standalone]

#103106 — Re: Guido on python3 for beginners

On Thu, Feb 18, 2016 at 9:57 PM, Cem Karan <cfkaran2@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#103110 — Re: Guido on python3 for beginners

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

[toc] | [prev] | [next] | [standalone]

#103128 — Re: Guido on python3 for beginners

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"?

[toc] | [prev] | [next] | [standalone]

#103163 — Re: Guido on python3 for beginners

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

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web