Re: Python Policy: Things to consider for Stretch

2016-02-15 Thread Ben Finney 
Scott Kitterman  writes:

> On Tuesday, February 02, 2016 06:44:57 AM Ben Finney wrote:
> > Ben Finney  writes:
> > > * Address all the language around Python 2 versus Python 3 versus
> > > Python general, and re-order or re-word to focus *primarily* on
> > > Python 3, with Python 2 treated as the still-supported legacy
> > > system.
>
> I've merged these changes. I have a little bit of adjustment I want to
> do on top of it, but this helps a lot. Thanks,

You're welcome, and thank you for working to get this in.

-- 
 \“All opinions are not equal. Some are a very great deal more |
  `\   robust, sophisticated, and well supported in logic and argument |
_o__) than others.” —Douglas Adams |
Ben Finney

Re: Python Policy: Things to consider for Stretch

2016-02-15 Thread Barry Warsaw 
On Feb 16, 2016, at 11:54 AM, Paul Wise wrote:

>I always thought it strange to put site- in /usr/local since
>/usr/local already implies site/system-wide packages. Same for dist-
>since /usr already implies distribution packages.

For as long as I can remember, a from-source 'configure && make && make
install' always put Python in /usr/local by default.  I think it was pretty
much the defacto standard for non-vendor supplied software[*] back in the days
of IRIX, SunOS, and other early *nix OSes that Python was developed on.  So it
was therefore completely natural that you'd end up with a site-packages in
/usr/local.  It was only later that the /usr/local site-packages directory
ended up on a /usr pathed distro-provided Python, which of course led to the
previously discussed dist-packages, the location of which completely mirrors
site-packages.

>I find it weird that site- gets used in ~/ since they are clearly user
>packages not site/system-wide packages.

It's all just a big ball of cruft-on-cruft with backward compatibility
preventing most cullings.  Somewhere out there, the entire world financial
system probably still critically depends on a tiny bit of Python 1.3 that
nobody has anything but the .pyc files for any more. ;)

Cheers,
-Barry

[*] I can't even call it Free Software or Open Source because it predates
those terms.  I mean, I started out sharing split shar files on Usenet with my
UUCP address.  ObGOML.

Re: Python Policy: Things to consider for Stretch

2016-02-15 Thread Paul Wise 
On Tue, Feb 16, 2016 at 11:42 AM, Barry Warsaw wrote:

> I don't remember exactly why we called it 'site-packages' ...

Thanks for the history :)

I always thought it strange to put site- in /usr/local since
/usr/local already implies site/system-wide packages. Same for dist-
since /usr already implies distribution packages. I find it weird that
site- gets used in ~/ since they are clearly user packages not
site/system-wide packages.

Any thoughts on that?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Python Policy: Things to consider for Stretch

2016-02-15 Thread Barry Warsaw 
On Feb 15, 2016, at 07:42 PM, Barry Warsaw wrote:

>I don't remember exactly why we called it 'site-packages', but I believe it
>was an evolution from the earlier ni.py module, which was where dotted module
>paths first showed up in Python.

And which had a 'site-python' directory, which was kept at least for Python
1.5 also.

Cheers,
-Barry