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

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

Re: Python 2 to 3 conversion - embrace the pain

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Python 2 to 3 conversion - embrace the pain Chris Angelico <rosuav@gmail.com> - 2015-03-16 14:22 +1100
    Re: Python 2 to 3 conversion - embrace the pain Paul Rubin <no.email@nospam.invalid> - 2015-03-15 22:07 -0700
      Re: Python 2 to 3 conversion - embrace the pain Chris Angelico <rosuav@gmail.com> - 2015-03-16 16:39 +1100
        Re: Python 2 to 3 conversion - embrace the pain Paul Rubin <no.email@nospam.invalid> - 2015-03-15 23:17 -0700
          Re: Python 2 to 3 conversion - embrace the pain Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-16 19:00 +1100
            Re: Python 2 to 3 conversion - embrace the pain Paul Rubin <no.email@nospam.invalid> - 2015-03-16 01:31 -0700
              Re: Python 2 to 3 conversion - embrace the pain Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-17 00:05 +1100
                Re: Python 2 to 3 conversion - embrace the pain Chris Angelico <rosuav@gmail.com> - 2015-03-17 00:29 +1100
              Re: Python 2 to 3 conversion - embrace the pain Terry Reedy <tjreedy@udel.edu> - 2015-03-16 13:59 -0400
        Re: Python 2 to 3 conversion - embrace the pain Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-16 18:56 +1100
          Re: Python 2 to 3 conversion - embrace the pain Paul Rubin <no.email@nospam.invalid> - 2015-03-16 01:25 -0700
            Re: Python 2 to 3 conversion - embrace the pain INADA Naoki <songofacandy@gmail.com> - 2015-03-16 18:13 +0900
              Re: Python 2 to 3 conversion - embrace the pain Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-16 22:55 +1100
            Re: Python 2 to 3 conversion - embrace the pain Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-17 01:25 +1100
              Re: Python 2 to 3 conversion - embrace the pain Paul Rubin <no.email@nospam.invalid> - 2015-03-16 15:36 -0700
                Re: Python 2 to 3 conversion - embrace the pain Terry Reedy <tjreedy@udel.edu> - 2015-03-16 22:28 -0400
                  Re: Python 2 to 3 conversion - embrace the pain wxjmfauth@gmail.com - 2015-03-17 01:31 -0700
                Re: Python 2 to 3 conversion - embrace the pain Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-17 22:26 +1100
                  Re: Python 2 to 3 conversion - embrace the pain wxjmfauth@gmail.com - 2015-03-17 07:03 -0700
                  Re: Python 2 to 3 conversion - embrace the pain Mario Figueiredo <marfig@gmail.com> - 2015-03-17 15:35 +0100
                  Re: Python 2 to 3 conversion - embrace the pain Paul Rubin <no.email@nospam.invalid> - 2015-03-19 16:23 -0700
                    Re: Python 2 to 3 conversion - embrace the pain Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-03-19 22:03 -0400
                      Re: Python 2 to 3 conversion - embrace the pain Mario Figueiredo <marfig@gmail.com> - 2015-03-20 03:54 +0100
            Re: Python 2 to 3 conversion - embrace the pain Michael Torrie <torriem@gmail.com> - 2015-03-16 11:20 -0600
              Re: Python 2 to 3 conversion - embrace the pain Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-17 07:36 +1100
                Re: Python 2 to 3 conversion - embrace the pain Michael Torrie <torriem@gmail.com> - 2015-03-16 20:14 -0600
                Re: Python 2 to 3 conversion - embrace the pain Cameron Simpson <cs@zip.com.au> - 2015-03-17 17:47 +1100
            Re: Python 2 to 3 conversion - embrace the pain Terry Reedy <tjreedy@udel.edu> - 2015-03-16 13:47 -0400
            Re: Python 2 to 3 conversion - embrace the pain Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-03-16 18:14 +0000
            Re: Python 2 to 3 conversion - embrace the pain INADA Naoki <songofacandy@gmail.com> - 2015-03-17 04:41 +0900
            Re: Python 2 to 3 conversion - embrace the pain Chris Angelico <rosuav@gmail.com> - 2015-03-17 09:02 +1100
              Re: Python 2 to 3 conversion - embrace the pain Mario Figueiredo <marfig@gmail.com> - 2015-03-17 04:04 +0100
                Re: Python 2 to 3 conversion - embrace the pain Michael Torrie <torriem@gmail.com> - 2015-03-16 21:33 -0600
                  Re: Python 2 to 3 conversion - embrace the pain Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-17 19:36 +1100
                Re: Python 2 to 3 conversion - embrace the pain Ben Finney <ben+python@benfinney.id.au> - 2015-03-17 14:42 +1100
                  Re: Python 2 to 3 conversion - embrace the pain Mario Figueiredo <marfig@gmail.com> - 2015-03-17 05:30 +0100
                    Re: Python 2 to 3 conversion - embrace the pain Cameron Simpson <cs@zip.com.au> - 2015-03-18 08:53 +1100
                Re: Python 2 to 3 conversion - embrace the pain Chris Angelico <rosuav@gmail.com> - 2015-03-17 14:49 +1100
                  Re: Python 2 to 3 conversion - embrace the pain Mario Figueiredo <marfig@gmail.com> - 2015-03-17 05:26 +0100
                    Re: Python 2 to 3 conversion - embrace the pain Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-03-17 04:36 +0000
                      Re: Python 2 to 3 conversion - embrace the pain Grant Edwards <invalid@invalid.invalid> - 2015-03-17 14:50 +0000
                        Re: Python 2 to 3 conversion - embrace the pain wxjmfauth@gmail.com - 2015-03-17 08:15 -0700
                        Re: Python 2 to 3 conversion - embrace the pain Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-03-17 18:36 -0400
                        Re: Python 2 to 3 conversion - embrace the pain Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-03-17 22:41 +0000
                        Re: Python 2 to 3 conversion - embrace the pain Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-03-18 08:04 -0400
                      Re: Python 2 to 3 conversion - embrace the pain Mario Figueiredo <marfig@gmail.com> - 2015-03-18 02:02 +0100
            [OT] Weaknesses of distro package managers - was Re: Python 2 to 3 conversion - embrace the pain Michael Torrie <torriem@gmail.com> - 2015-03-16 19:46 -0600
              Re: [OT] Weaknesses of distro package managers - was Re: Python 2 to 3 conversion - embrace the pain Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-17 19:39 +1100
                Re: [OT] Weaknesses of distro package managers - was Re: Python 2 to 3 conversion - embrace the pain Michael Torrie <torriem@gmail.com> - 2015-03-17 09:02 -0600
              Re: [OT] Weaknesses of distro package managers - was Re: Python 2 to 3 conversion - embrace the pain Michael Torrie <torriem@gmail.com> - 2015-03-19 16:37 -0600
                Re: [OT] Weaknesses of distro package managers - was Re: Python 2 to 3 conversion - embrace the pain wxjmfauth@gmail.com - 2015-03-20 02:40 -0700
                  Re: [OT] Weaknesses of distro package managers - was Re: Python 2 to 3 conversion - embrace the pain Mario Figueiredo <marfig@gmail.com> - 2015-03-20 15:59 +0100
                    Re: [OT] Weaknesses of distro package managers - was Re: Python 2 to 3 conversion - embrace the pain Mario Figueiredo <marfig@gmail.com> - 2015-03-20 16:03 +0100
                    Re: [OT] Weaknesses of distro package managers - was Re: Python 2 to 3 conversion - embrace the pain Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-03-20 15:42 +0000
                    Re: [OT] Weaknesses of distro package managers - was Re: Python 2 to 3 conversion - embrace the pain Chris Angelico <rosuav@gmail.com> - 2015-03-21 04:13 +1100
                    Re: [OT] Weaknesses of distro package managers - was Re: Python 2 to 3 conversion - embrace the pain wxjmfauth@gmail.com - 2015-03-20 12:21 -0700
            Re: [OT] Weaknesses of distro package managers - was Re: Python 2 to 3 conversion - embrace the pain Chris Angelico <rosuav@gmail.com> - 2015-03-17 12:57 +1100
              Re: [OT] Weaknesses of distro package managers - was Re: Python 2 to 3 conversion - embrace the pain Paul Rubin <no.email@nospam.invalid> - 2015-03-16 19:45 -0700
                Re: [OT] Weaknesses of distro package managers - was Re: Python 2 to 3 conversion - embrace the pain Michael Torrie <torriem@gmail.com> - 2015-03-16 21:05 -0600
            Re: [OT] Weaknesses of distro package managers - was Re: Python 2 to 3 conversion - embrace the pain Michael Torrie <torriem@gmail.com> - 2015-03-16 20:07 -0600
            Re: Python 2 to 3 conversion - embrace the pain Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-03-17 02:21 +0000
            Re: [OT] Weaknesses of distro package managers - was Re: Python 2 to 3 conversion - embrace the pain Ben Finney <ben+python@benfinney.id.au> - 2015-03-17 13:40 +1100
              Package manager cooperation? (was Weaknesses of distro package managers) Rustom Mody <rustompmody@gmail.com> - 2015-03-16 20:09 -0700
                Re: Package manager cooperation? (was Weaknesses of distro package managers) Michael Torrie <torriem@gmail.com> - 2015-03-16 21:32 -0600
                Re: Package manager cooperation? (was Weaknesses of distro package managers) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-03-17 04:03 +0000
                Re: Package manager cooperation? (was Weaknesses of distro package managers) Chris Angelico <rosuav@gmail.com> - 2015-03-17 15:18 +1100
                  Re: Package manager cooperation? (was Weaknesses of distro package managers) wxjmfauth@gmail.com - 2015-03-17 01:44 -0700
            Re: [OT] Weaknesses of distro package managers - was Re: Python 2 to 3 conversion - embrace the pain Michael Torrie <torriem@gmail.com> - 2015-03-16 20:51 -0600
            Re: [OT] Weaknesses of distro package managers - was Re: Python 2 to 3 conversion - embrace the pain Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-03-17 03:01 +0000
            Re: [OT] Weaknesses of distro package managers - was Re: Python 2 to 3 conversion - embrace the pain Michael Torrie <torriem@gmail.com> - 2015-03-16 21:05 -0600
              Re: [OT] Weaknesses of distro package managers - was Re: Python 2 to 3 conversion - embrace the pain Mario Figueiredo <marfig@gmail.com> - 2015-03-17 04:07 +0100
            Re: [OT] Weaknesses of distro package managers - was Re: Python 2 to 3 conversion - embrace the pain Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-03-17 03:17 +0000
            Re: [OT] Weaknesses of distro package managers - was Re: Python 2 to 3 conversion - embrace the pain Alexander <xr.lists@gmail.com> - 2015-03-17 16:44 +1300
          Re: Python 2 to 3 conversion - embrace the pain Chris Angelico <rosuav@gmail.com> - 2015-03-16 19:51 +1100
      Re: Python 2 to 3 conversion - embrace the pain Terry Reedy <tjreedy@udel.edu> - 2015-03-16 04:53 -0400
        Re: Python 2 to 3 conversion - embrace the pain Paul Rubin <no.email@nospam.invalid> - 2015-03-16 02:27 -0700

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

#87749

Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:
>> better to make a fork of the language
> You mean like Python 3?

No I mean like C to C++, or Lisp to Clojure, etc.  Or if you prefer, C
to OpenCL or maybe even C++ to Java or C to Go.  If you're going to
break old code, go big or go home ;-).

> There are still people using Python 1.5, some in production,

Yes, and Python 2 added stuff to Python 1.5 but it didn't break 1.5
programs (much), except for the ill-advised division change.  Which by
the way didn't introduce "true division"--rather, it replaced something
mathematically meaningful with the weird computer vagary of floating
point values.  True division would have meant exact rationals, something
that a really breaking change could have implemented.

>> C code then and now used implementation-dependent hacks ...
> People who really take backwards compatibility seriously make even their
> undocumented behaviour backwards compatible, 

The more important such hacks are still supported by compilers, though
sometimes you have to supply a command line option at compile time
to keep the hack working.

> the += operator was originally spelled =+ copying Ken Thompson's
> earlier language "B". That was changed in 1976.

That was before C was claiming to be mature and stable, so no prob.

> Post-standardisation, here are a few other backwards incompatibilities:

Hmm, maybe I'm behind the times.

> - C99 introduced variable-length arrays, but C11 relegated it to an
> optional feature which compilers are not required to support;

You mean https://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html ?
They standardized that and then un-standardized it?  Wow, that's
interesting and probably not so wise.

> - C99 changed the behaviour of floating point operations;

They weren't very well-defined before and I bet compilers supply
compatibility flags.

> - C11 finally removed `gets`.

I bet compiler libraries will keep supplying it forever though ;)

> But the biggest problem is that C compilers vary (sometimes greatly) in what
> subsets of the language they actually support. What works in compiler A may
> not even compile on compiler B, let alone behave the same.

Same as with CPython/Jython/IronPython/PyPy/MicroPython/Berp/???

>> I don't notice anyone wanting Python to change faster, in the sense of
>> breaking existing code more often. 
> Are you on the python-ideas list?

No, what's it like?  How often does anyone make a serious proposal for
more frequently breaking stuff?  How often do they want to do it?  

> after almost a decade of development, the Python 3 ecosystem is now in
> a fit state that people should prefer it for new projects. 

Given that Python 3 is a just few small tweaks added to Python 2, does
the "almost a decade of development" show that something went badly
wrong?  Would uptake had been better if it either 
  a) broke less stuff (maintaining more compatibility)
  b) broke more stuff (bringing greater benefits to switching)?

I think it's plausible that the answer is yes to both.

Also, ignoring whether people "should" prefer it for new projects: is
there info available about whether they actually do?  Someone named a
shop that deals with a lot of internationalization and benefited from
the unicode fixes, which is cool.  

I haven't been involved in any new python "projects" (meaning something
with more planning and lifecycle expectations than it takes to write yet
another throwaway script) in a while.  If management called me in about
a new project and asked whether to use Python 3, I'd have to consider it
a complicated decision, especially if the target platform wasn't one of
the widely supported ones: I did a fair amount of Python 2 on a custom
embedded hardware box and would have to experiment to find out if Python
3 even runs on that thing.  And if the idea is to break with the warty
cruft of Python 2, I'd have to consider further-out alternatives like Go
or Erlang, etc.

> Anyone remember the big backwards incompatible changes made to Visual
> Basic?  How long did that take to settle down afterwards?

No idea from me, I never used VB.

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

#87753

On Thu, 19 Mar 2015 16:23:04 -0700, Paul Rubin <no.email@nospam.invalid>
declaimed the following:

>Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:
>
>> Anyone remember the big backwards incompatible changes made to Visual
>> Basic?  How long did that take to settle down afterwards?
>
>No idea from me, I never used VB.

	VB6 was Win32API, native code... It was replaced by VB.NET -- .NET API,
"managed" code.

	Imagine if "CPython" 2.x were replaced with "Jython" 3.x, and most of
the Python standard library was replaced with Java packages.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#87755

On Thu, 19 Mar 2015 22:03:02 -0400, Dennis Lee Bieber
<wlfraed@ix.netcom.com> wrote:

>On Thu, 19 Mar 2015 16:23:04 -0700, Paul Rubin <no.email@nospam.invalid>
>declaimed the following:
>
>>Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:
>>
>>> Anyone remember the big backwards incompatible changes made to Visual
>>> Basic?  How long did that take to settle down afterwards?
>>
>>No idea from me, I never used VB.
>
>	VB6 was Win32API, native code... It was replaced by VB.NET -- .NET API,
>"managed" code.
>
>	Imagine if "CPython" 2.x were replaced with "Jython" 3.x, and most of
>the Python standard library was replaced with Java packages.

I think Steven was referring to the VB 3, 4, 5, and 6 releases (to
name the ones that went into mass distribution back then). Microsoft
was infamous for making each release non backwards compatible except
for the most trivial projects, sometimes making meaningless changes
that would break incompatibility for no reason at all; like changing
the vbp tag for the project title, for god knows why.

VB.NET, on the other hand, isn't comparable. It is not an upgrade to
VB. Both languages are completely distinct, sharing only a similar
syntax. For obvious reasons back in 2000, Microsoft wanted Visual
Basic developers to adopt the .Net framework experiment and even made
the first VB.NET version number one up from Visual Basic. But they are
completely different languages.

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

#87577

On 03/16/2015 03:13 AM, INADA Naoki wrote:
> I think application developers should use *only* Python 3 from this year.
> If we start moving, more library developers will be able to start
> writing Python 3 only code from next year.

An admirable sentiment, but I'm currently running the latest RHEL
release (v7) and Python3 is not part of the standard install.  I can get
it via Software Collections, but that installs to /opt and, by default,
does not integrate into the system environment (there are good reasons
for this of course).  So Python3 apps will never be integrated fully on
his major distribution.  And it is a major server platform.

RHEL 8 will turn this around completely, as Python 3 will be the default
system python, but that won't be out for several years.

A bit off topic here, but all of this highlights major weaknesses in the
Linux software distribution model. While we Linux nerds like to poke fun
at Windows for not even having a proper package manager until Windows
10, in fact the package manager is not always the best way to go.  Works
well for core system parts, and for distro maintainers.  But it sucks
miserably for developers, and to a lesser degree, end users.  I should
be able to have a stable core distro like RHEL 7 (or any distro), but
develop and distribute apps for Python 3 easily.  Say what you want
about Red Hat's Poettering, but what he says about this problem makes a
lot of sense:
http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html.

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

#87583

On Tue, 17 Mar 2015 04:20 am, Michael Torrie wrote:

> On 03/16/2015 03:13 AM, INADA Naoki wrote:
>> I think application developers should use *only* Python 3 from this year.
>> If we start moving, more library developers will be able to start
>> writing Python 3 only code from next year.
> 
> An admirable sentiment, but I'm currently running the latest RHEL
> release (v7) and Python3 is not part of the standard install.  I can get
> it via Software Collections, but that installs to /opt and, by default,
> does not integrate into the system environment (there are good reasons
> for this of course). So Python3 apps will never be integrated fully on 
> his major distribution.  And it is a major server platform.

I'm sorry, that makes no sense to me. What does it matter whether Python3 is
installed to /opt or /usr or /bin or /who/the/feck/cares, so long as your
application runs when you run it? It's just another dependency, and no more
than one call to yum away.

I must admit that the Linux filesystem layout strikes me as awfully pedantic
and fussy. We're happy to use our home directory as an undifferentiated bag
with no structure, dumping binaries, scripts, documents, data files, config
files and everything else into $HOME, but for applications we have:

/bin
/sbin
/usr/bin
/usr/sbin
/usr/local/bin
/usr/local/sbin
/opt 

and probably more, to say nothing of

/lib
/usr/lib
/usr/local/lib



Yesterday I wrote:

    Alas, too many (Linux) developers insist on using the system Python
    as their application language. In most cases they could trivially
    run "aptitude install python3" and be done with it, but that's an 
    extra dependency and therefore Bad.

I never imagined that anyone would argue that they can't install and use
Python3 because of the location where it is installed. As an application
developer, apart from ensuring that the PATH is setup correctly and maybe
having to adjust a few hash-bang lines, how does the location of the Python
binary affect you?



-- 
Steven

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

#87592

On 03/16/2015 02:36 PM, Steven D'Aprano wrote:
> I'm sorry, that makes no sense to me. What does it matter whether Python3 is
> installed to /opt or /usr or /bin or /who/the/feck/cares, so long as your
> application runs when you run it? It's just another dependency, and no more
> than one call to yum away.

Of course it matters.  How else will you refer to it in the #!
invocation?  If Python3 is in the system path then you can use a wrapper
script like Calibre does.  But in the case of RHEL with Software
Collections (which does use yum), it does not place it in the system path.

> Yesterday I wrote:
> 
>     Alas, too many (Linux) developers insist on using the system Python
>     as their application language. In most cases they could trivially
>     run "aptitude install python3" and be done with it, but that's an 
>     extra dependency and therefore Bad.
> 
> I never imagined that anyone would argue that they can't install and use
> Python3 because of the location where it is installed. As an application
> developer, apart from ensuring that the PATH is setup correctly and maybe
> having to adjust a few hash-bang lines, how does the location of the Python
> binary affect you?

Well the thing is that it's *not* in the PATH by default.  So it does
affect me. The official way to use Python 3 in RHEL Software Collection
is to invoke with with this command line:

scl enable python33 bash

This gives you a shell where python3 is in the path.  You can put
Python3 in the path permanently by modifying /etc/profile.  There are
good reasons for SCL doing things this way, and it's not the only way.
Just pointing out that distro life isn't always rosy.

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

#87626

On 17Mar2015 07:36, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
>I must admit that the Linux filesystem layout strikes me as awfully pedantic
>and fussy. We're happy to use our home directory as an undifferentiated bag
>with no structure, dumping binaries, scripts, documents, data files, config
>files and everything else into $HOME, but for applications we have:
>
>/bin
>/sbin
>/usr/bin
>/usr/sbin
>/usr/local/bin
>/usr/local/sbin
>/opt
>
>and probably more, to say nothing of
>
>/lib
>/usr/lib
>/usr/local/lib

Yeah, it is a bit nuts. A lot of that is history:

  /bin vs /sbin
    /sbin was staticly linked executables, which needed to work early in the 
    boot process (or in rescue situations) before (arbitrarily placed) dynamic 
    libraries were available; as a consequence, /sbin these days mostly 
    contains admin commands (necessary) versus /bin with the other commands 
    (less critical, just useful)
    Less of an issue these days with bigger drives, so /bin vs /sbin is mostly 
    historic and unnecessary

  / vs /usr (and therefore /bin vs /usr/bin etc)
    the root fs (/0 used to be very small, limiting what would fit
    /usr was larger and mounted later
    There are multiple reasons for this, including the size of the system you 
    need to repair to rescue (repair a small / vs something bigger) and 
    limiting damage (less I/O to /, therefore less risk of need of repair)
    and so forth.
    Less of an issue these days with bigger and faster drives, fo /bin vs 
    /usr/bin is historic and unnecessary

  / (and /usr) vs /usr/local
    This is architectural and important. /usr/local tends to be for extras not 
    supplied by the OS provider/vendor. So a bare supplies OS will have stuff 
    in / and /usr, but /usr/local will be an empty skeleton for people to add 
    stuff to without treading on the supplied and supported OS areas.

Yes, off topic, sorry.

Python 3 vs Python 2: a good thing IMO. The way the transition was done?  
Correct IMO. Add nonbreaking stuff to the 2.x series (with, yield from, extra 
libraries supporting interfaces coming in the 3.x series, so forth) but keep 
legacy code working unchanged. With 3.x, cut to changes that would break legacy 
code, but we now have a cleaner and better language.

And re Paul Rubin's "fork the language" remakr: Python 3.x _is_ the fork!

I try to make most of my code work in both py2 and py3; easier to run on 
multiple systems. But I definitely have code that works so much better in 
python 3 that I will never backport it; the example I have in mind started as 
python 2 and spent years in bytes/text indecision and confusion. Bite the 
bullet and go py3, an a whole class of pervasive issue just go away.

Cheers,
Cameron Simpson <cs@zip.com.au>

PARANOIDS!!!! They're EVERYWHERE!!!
        - bcash@crchh410.NoSubdomain.NoDomain (Brian Cash)

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

#87578

On 3/16/2015 5:13 AM, INADA Naoki wrote:

> Another experience is porting Flask application in my company from
> Python 2 to Python 3.
> It has 26k lines of code and 7.6k lines of tests.
>
> Since we don't need to support both of PY2 and PY3, we used 2to3.
> 2to3 changes 740 lines.

That is less than 3% of the lines.  Were any changes incorrect?  How 
many lines *not* flagged by 2to3 needed change?

> I had to replace google-api-client with
> requests+oauthlib since
> it had not supported PY3 yet.

Other than those needed for this change, which 2to3 could not anticipate 
or handle?

> After that, we encountered few trouble with untested code. But Porting
> effort is surprisingly small.
> We're happy now with Python 3.  We can write non-ascii string to log
> without fear of UnicodeError.
> We can use csv with unicode without hack.

People who use ascii only or perhaps one encoding everywhere severely 
underestimate the benefit of unicode strings (and utf-8) everywhere.

> Porting *modern* *application* code to *PY3 only* is easy, while
> porting libraries on the edge of
> bytes/unicode like google-api-client to PY2/3 is not easy.
>
> I think application developers should use *only* Python 3 from this year.
> If we start moving, more library developers will be able to start
> writing Python 3 only code from next year.

-- 
Terry Jan Reedy

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

#87580

On 16/03/2015 17:47, Terry Reedy wrote:
> On 3/16/2015 5:13 AM, INADA Naoki wrote:
>
>> Another experience is porting Flask application in my company from
>> Python 2 to Python 3.
>> It has 26k lines of code and 7.6k lines of tests.
>>
>> Since we don't need to support both of PY2 and PY3, we used 2to3.
>> 2to3 changes 740 lines.
>
> That is less than 3% of the lines.  Were any changes incorrect?  How
> many lines *not* flagged by 2to3 needed change?
>
>> I had to replace google-api-client with
>> requests+oauthlib since
>> it had not supported PY3 yet.
>
> Other than those needed for this change, which 2to3 could not anticipate
> or handle?
>

Any of the 47 open issues on the bug tracker to start with :(

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#87582

On Tue, Mar 17, 2015 at 2:47 AM, Terry Reedy <tjreedy@udel.edu> wrote:
> On 3/16/2015 5:13 AM, INADA Naoki wrote:
>
>> Another experience is porting Flask application in my company from
>> Python 2 to Python 3.
>> It has 26k lines of code and 7.6k lines of tests.
>>
>> Since we don't need to support both of PY2 and PY3, we used 2to3.
>> 2to3 changes 740 lines.
>
>
> That is less than 3% of the lines.  Were any changes incorrect?  How many
> lines *not* flagged by 2to3 needed change?

All changes are OK. Flask (and Werkzeug) handles most part of pain.
Application using Flask uses unicode most everywhere on Python 2 already.

Few changes 2to3 can't handle is like this:

-    reader = DictReader(open(file_path, 'r'), delimiter='\t')
+    reader = DictReader(open(file_path, 'r', encoding='utf-8'), delimiter='\t')

Since csv module in Python 2 doesn't support unicode, we had to parse
csv as bytestring.
And our server doesn't have utf-8 locale, we should specify encoding
explicitly on PY3.
There were few (less than 10, maybe) easy trouble like this.


>
>> I had to replace google-api-client with
>> requests+oauthlib since
>> it had not supported PY3 yet.
>
>
> Other than those needed for this change, which 2to3 could not anticipate or
> handle?
>
>> After that, we encountered few trouble with untested code. But Porting
>> effort is surprisingly small.
>> We're happy now with Python 3.  We can write non-ascii string to log
>> without fear of UnicodeError.
>> We can use csv with unicode without hack.
>
>
> People who use ascii only or perhaps one encoding everywhere severely
> underestimate the benefit of unicode strings (and utf-8) everywhere.


I agree. We may lost log easily on Python 2. It makes investigating bug hard.

    >>> import logging
    >>> logging.error("%s %s", u'こんにちは', 'こんにちは')
    Traceback (most recent call last):
    ...
      File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/logging/__init__.py",
line 335, in getMessage
        msg = msg % self.args
    UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in
position 0: ordinal not in range(128)
    Logged from file <stdin>, line 1


And log including unicode is hard to read.

    >>> logging.error("%s", [u'こんにちは'])
    ERROR:root:[u'\u3053\u3093\u306b\u3061\u306f']


Python 3 makes our development faster and easier.

Since old Python programmers knows how to avoid pitfalls in Python 2,
writing Python 2 is not a pain.
But when teaching Python to PHP programmer, teaching tons of pitfalls is pain.
This is why I think new applications should start with Python 3.

>
>> Porting *modern* *application* code to *PY3 only* is easy, while
>> porting libraries on the edge of
>> bytes/unicode like google-api-client to PY2/3 is not easy.
>>
>> I think application developers should use *only* Python 3 from this year.
>> If we start moving, more library developers will be able to start
>> writing Python 3 only code from next year.
>
>
> --
> Terry Jan Reedy
>
> --
> https://mail.python.org/mailman/listinfo/python-list



--
INADA Naoki  <songofacandy@gmail.com>

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

#87584

On Tue, Mar 17, 2015 at 4:20 AM, Michael Torrie <torriem@gmail.com> wrote:
> A bit off topic here, but all of this highlights major weaknesses in the
> Linux software distribution model. While we Linux nerds like to poke fun
> at Windows for not even having a proper package manager until Windows
> 10, in fact the package manager is not always the best way to go.  Works
> well for core system parts, and for distro maintainers.  But it sucks
> miserably for developers, and to a lesser degree, end users.  I should
> be able to have a stable core distro like RHEL 7 (or any distro), but
> develop and distribute apps for Python 3 easily.  Say what you want
> about Red Hat's Poettering, but what he says about this problem makes a
> lot of sense:
> http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html.

It most assuredly does NOT suck for end users. Apart from issues of
naming (grab "avconv" or "ffmpeg"?), it's easy - if someone needs to
do audio manipulation, I can tell him/her to "sudo apt-get install
sox" and that'll get the necessary program on any Debian-based distro,
and likewise one command for any Red Hat distro. I'm not sure what you
mean by "for developers" - do you mean that it's hard to package your
software for each distro? Because the package manager benefits you
even if you don't package your own program. Imagine you need a
PostgreSQL database for your Python application - which also means you
need psycopg2, of course. How do you go about writing installation
instructions?

* WINDOWS *
1) Install the latest Python 3 from https://www.python.org/downloads/windows/
2) Install the appropriate version of psycopg2 from
http://www.stickpeople.com/projects/python/win-psycopg/
3) Install the latest PostgreSQL from
http://www.postgresql.org/download/windows/
4) Install my program from blah blah blah

* LINUX: Debian-based *
1) As root, type: apt-get install postgresql python3-psycopg2
2) Install my program from blah blah blah

* LINUX: Red Hat-based *
1) As root, type: yum install postgresql python3-psycopg2
2) Install my program from blah blah blah

(I don't have a Red Hat system handy to check, so the above examples
might need to be tweaked. But you get the idea.)

Without actually going to any effort to build your own packages, you
can still take advantage of one-command installation of all your
dependencies. Without a package manager, you have to assemble them
from all over the internet.

I call that a benefit :)

ChrisA

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

#87600

On Tue, 17 Mar 2015 09:02:38 +1100, Chris Angelico <rosuav@gmail.com>
wrote:
>
>Imagine you need a
>PostgreSQL database for your Python application - which also means you
>need psycopg2, of course. How do you go about writing installation
>instructions?
>
>* WINDOWS *
>1) Install the latest Python 3 from https://www.python.org/downloads/windows/
>2) Install the appropriate version of psycopg2 from
>http://www.stickpeople.com/projects/python/win-psycopg/
>3) Install the latest PostgreSQL from
>http://www.postgresql.org/download/windows/
>4) Install my program from blah blah blah
>

Are you saying this is a problem for any developer? Especially
considering this is a one-time operation...

Or maybe you mean lazy developers. But lazy developers are an edge
case not worth being catered for.

>
>Without actually going to any effort to build your own packages, you
>can still take advantage of one-command installation of all your
>dependencies. Without a package manager, you have to assemble them
>from all over the internet.

With the advantage of storing them on a portable pen to install
somewhere else offline... But hey, that isn't good, right?

Anyways, on the specific case of Python packages, you are of course
wrong. First it was easy_install, now you have pip.

You also have chocolatey, nuget, ninite, npackd, etc. It's not that
you don't have package manager-like options in windows. It's just
that, like with linux unofficial, unsupported, edge, etc repos, you
rarely want to put your faith on a anonymous package developer or on a
bleeding edge package.

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

#87611

On 03/16/2015 09:04 PM, Mario Figueiredo wrote:
> Are you saying this is a problem for any developer? Especially
> considering this is a one-time operation...
> 
> Or maybe you mean lazy developers. But lazy developers are an edge
> case not worth being catered for.

I guess I'm saying the package managers are a problem for developers who
wish to distribute their products or projects to end users.

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

#87629

On Tuesday 17 March 2015 14:33, Michael Torrie wrote:

> On 03/16/2015 09:04 PM, Mario Figueiredo wrote:
>> Are you saying this is a problem for any developer? Especially
>> considering this is a one-time operation...
>> 
>> Or maybe you mean lazy developers. But lazy developers are an edge
>> case not worth being catered for.
> 
> I guess I'm saying the package managers are a problem for developers who
> wish to distribute their products or projects to end users.


I think you have this exactly backwards. It's easy enough to provide a repo 
for yum or apt. What's hard is interoperating with multiple slightly-
different OSes or distros.

I think this would be equally hard with, or without, a package manager.


-- 
Steve

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

#87613

Mario Figueiredo <marfig@gmail.com> writes:

> On Tue, 17 Mar 2015 09:02:38 +1100, Chris Angelico <rosuav@gmail.com>
> wrote:
> >
> >Imagine you need a PostgreSQL database for your Python application -
> >which also means you need psycopg2, of course. How do you go about
> >writing installation instructions?
> >
> >* WINDOWS *
> >1) Install the latest Python 3 from https://www.python.org/downloads/windows/
> >2) Install the appropriate version of psycopg2 from
> >http://www.stickpeople.com/projects/python/win-psycopg/
> >3) Install the latest PostgreSQL from
> >http://www.postgresql.org/download/windows/
> >4) Install my program from blah blah blah
> >
>
> Are you saying this is a problem for any developer?

Yes. They need to write installation instructions, and the more complex
those instructions are the fewer prospective users will bother.

The more complexities in the installation process, the more
opportunities there are for the recipient to make a mistake. Each
mistake is demoralising and will cause some proportion of people to give
up.

So if the installation process *necessitates* complex instructions,
that's a problem for the developer.

You can blame “lazy users” if you want to. That gets you no new users of
your program though.

-- 
 \      “I tell you the truth: some standing here will not taste death |
  `\    before they see the Son of Man coming in his kingdom.” —Jesus, |
_o__)                             c. 30 CE, as quoted in Matthew 16:28 |
Ben Finney

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

#87620

On Tue, 17 Mar 2015 14:42:42 +1100, Ben Finney
<ben+python@benfinney.id.au> wrote:

>Mario Figueiredo <marfig@gmail.com> writes:
>
>> On Tue, 17 Mar 2015 09:02:38 +1100, Chris Angelico <rosuav@gmail.com>
>> wrote:
>> >
>> >Imagine you need a PostgreSQL database for your Python application -
>> >which also means you need psycopg2, of course. How do you go about
>> >writing installation instructions?
>> >
>> >* WINDOWS *
>> >1) Install the latest Python 3 from https://www.python.org/downloads/windows/
>> >2) Install the appropriate version of psycopg2 from
>> >http://www.stickpeople.com/projects/python/win-psycopg/
>> >3) Install the latest PostgreSQL from
>> >http://www.postgresql.org/download/windows/
>> >4) Install my program from blah blah blah
>> >
>>
>> Are you saying this is a problem for any developer?
>
>Yes. They need to write installation instructions, and the more complex
>those instructions are the fewer prospective users will bother.
>

The prospective users in this context are software developers. If
software developers can't understand instructions and can't be
bothered following linear procedures, they cannot write good code.

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

#87650

On 17Mar2015 05:30, Mario Figueiredo <marfig@gmail.com> wrote:
>On Tue, 17 Mar 2015 14:42:42 +1100, Ben Finney
><ben+python@benfinney.id.au> wrote:
>>Mario Figueiredo <marfig@gmail.com> writes:
>>> On Tue, 17 Mar 2015 09:02:38 +1100, Chris Angelico <rosuav@gmail.com>
>>> wrote:
>>> >Imagine you need a PostgreSQL database for your Python application -
>>> >which also means you need psycopg2, of course. How do you go about
>>> >writing installation instructions?
>>> >
>>> >* WINDOWS *
>>> >1) Install the latest Python 3 from https://www.python.org/downloads/windows/
>>> >2) Install the appropriate version of psycopg2 from
>>> >http://www.stickpeople.com/projects/python/win-psycopg/
>>> >3) Install the latest PostgreSQL from
>>> >http://www.postgresql.org/download/windows/
>>> >4) Install my program from blah blah blah
>>> >
>>>
>>> Are you saying this is a problem for any developer?
>>
>>Yes. They need to write installation instructions, and the more complex
>>those instructions are the fewer prospective users will bother.
>
>The prospective users in this context are software developers. If
>software developers can't understand instructions and can't be
>bothered following linear procedures, they cannot write good code.

"Linear procedures" often only look that way because the list is shortened, 
yea, even unto just headings.

There can be multiple ways to do each step, especially if one is juggling (or 
considering juggling) multiple versions. If one has to iterate then each of 
these steps can have internal loops and the whole process can require 
backtracking to redo things. Possible issues include around buggy releases of 
components, unfortunate decisions about the install regime, issues with the 
local dev environment (eg compile steps requiring unmentioned or special 
packages in the platform which may not be installed from the supplier), build 
options on/off, build tools requiring special (and ideally, badly or un- 
documented) config options (I am looking at you, RHEL lib64 stuff with 
autoconf).

I distribute an adzapping tool. It has two install modes, the default simple 
one and the optional more configurable one. The simple one reads:

  - make sure you have squid installed
  - install the script (a single perl script) somewhere on your system
  - add a single line to your squid config

One recurring request from some users is separation of the zapping patterns 
from the script; as shipped it is a single file with the patterns embedded. I 
have resisted this _because_ it would make installs _much_ harder for users.

Alternative anecdote: long ago when escaping from CVS to a newer VCS, I looked 
at SVN.  It was popular, etc. But the install/build chain was insane. Many 
prerequisite libraries, none available from the OS supplier, all needing 
special build/installs, and there were certainly buggy prerequisite library 
releases to be tripped over and avoided. A nightmare.

Not worth the bother. And I bothered for a long time trying to get it 
installed.

Compare Mercurial. Really easy, worked immediately, etc. Guess which I use.

IMO Mercurial is better anyway, but SVN shot itself in the foot with the 
install requirements.

I'm capable of following linear procedures. But I'm also capable of deciding 
that procedures are unreasonably complex, especially when they have bugs.

Cheers,
Cameron Simpson <cs@zip.com.au>

Wagner's music is better than it sounds.        - Mark Twain

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

#87615

On Tue, Mar 17, 2015 at 2:04 PM, Mario Figueiredo <marfig@gmail.com> wrote:
> On Tue, 17 Mar 2015 09:02:38 +1100, Chris Angelico <rosuav@gmail.com>
> wrote:
>>
>>Imagine you need a
>>PostgreSQL database for your Python application - which also means you
>>need psycopg2, of course. How do you go about writing installation
>>instructions?
>>
>>* WINDOWS *
>>1) Install the latest Python 3 from https://www.python.org/downloads/windows/
>>2) Install the appropriate version of psycopg2 from
>>http://www.stickpeople.com/projects/python/win-psycopg/
>>3) Install the latest PostgreSQL from
>>http://www.postgresql.org/download/windows/
>>4) Install my program from blah blah blah
>>
>
> Are you saying this is a problem for any developer? Especially
> considering this is a one-time operation...

I'm talking about how you write your installation instructions. At
some point, an end user has to turn a bare system into a system
capable of running your application, and that process involves
installing your application and everything that it needs. It's not a
one-time operation for the dev himself/herself, it's a standard
action[1] that has to be done by every user of your software.

The simpler you can make those instructions, the easier it is for
people to use your program. So on Windows, that probably means you
have to bundle everything into a big fat .exe or .msi installer, which
is what leads to DLL Hell when everyone bundles their own
copies/versions of what ought to be DLLs. Either that, or you tell
people to go install the pieces separately... which is what I'm
talking about above.

At least with a package manager you can tie in with that for most of the work.

ChrisA

[1] In D&D terms, of course, a "standard action" is a lot quicker than
installing anything under Windows. But I digress.

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

#87619

On Tue, 17 Mar 2015 14:49:36 +1100, Chris Angelico <rosuav@gmail.com>
wrote:

>
>The simpler you can make those instructions, the easier it is for
>people to use your program. So on Windows, that probably means you
>have to bundle everything into a big fat .exe or .msi installer, which
>is what leads to DLL Hell when everyone bundles their own
>copies/versions of what ought to be DLLs. Either that, or you tell
>people to go install the pieces separately... which is what I'm
>talking about above.

"DLL Hell" has long been a deprecated term in the windows ecosystem.
Side-by-side assemblies and Windows File Protection System have been
in-place technologies since Windows 2000.

Installing application and dependencies on windows isn't really much
different from Linux, really. The linux package manager isn't much
different than modern windows msi installers with full support for
merged packages, versioning, rollback and uninstallation. With some
additional benefits over linux packages, like automatic on-demand
installation. But with some drawbacks to linux packages, like the
comparatively complexity of creating a msi package compared to a linux
package (really a byproduct of microsoft insanane insistence on the
registry technology)

It should really fall in disuse the idea of making qualitative
comparisons between linux packages and windows installations. It's old
and boring. And usually something coming out of the mouth of someone
who doesn't understand well one or both of the operating system.

Both systems work and work extremely well in their own ecosystems. And
the proof of that is that you don't witness any sort of push towards
the other format in either operating system, despite the fact that a
large number of software developers being literate both on Linux and
Windows.

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

#87621

On 17/03/2015 04:26, Mario Figueiredo wrote:
> On Tue, 17 Mar 2015 14:49:36 +1100, Chris Angelico <rosuav@gmail.com>
> wrote:
>
>>
>> The simpler you can make those instructions, the easier it is for
>> people to use your program. So on Windows, that probably means you
>> have to bundle everything into a big fat .exe or .msi installer, which
>> is what leads to DLL Hell when everyone bundles their own
>> copies/versions of what ought to be DLLs. Either that, or you tell
>> people to go install the pieces separately... which is what I'm
>> talking about above.
>
> "DLL Hell" has long been a deprecated term in the windows ecosystem.
> Side-by-side assemblies and Windows File Protection System have been
> in-place technologies since Windows 2000.
>
> Installing application and dependencies on windows isn't really much
> different from Linux, really. The linux package manager isn't much
> different than modern windows msi installers with full support for
> merged packages, versioning, rollback and uninstallation. With some
> additional benefits over linux packages, like automatic on-demand
> installation. But with some drawbacks to linux packages, like the
> comparatively complexity of creating a msi package compared to a linux
> package (really a byproduct of microsoft insanane insistence on the
> registry technology)
>
> It should really fall in disuse the idea of making qualitative
> comparisons between linux packages and windows installations. It's old
> and boring. And usually something coming out of the mouth of someone
> who doesn't understand well one or both of the operating system.
>
> Both systems work and work extremely well in their own ecosystems. And
> the proof of that is that you don't witness any sort of push towards
> the other format in either operating system, despite the fact that a
> large number of software developers being literate both on Linux and
> Windows.
>

Of course we could avoid all of these problems if we were to bring back 
the mainframe or mini and the dumb terminal.

Take cover, incoming :)

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

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

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

csiph-web