Python 2 to 3 conversion - embrace the pain

[Cameron Simpson]

On 17Mar2015 07:36, Steven D'Aprano <steve+comp.lang.python at 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 at zip.com.au>

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