Re: [Python-Dev] r84513 - python/branches/py3k/Doc/whatsnew/3.2.rst
On Sun, 5 Sep 2010 02:27:25 +0200 (CEST) raymond.hettinger wrote: > + > +The common directory is "pyshared" and the file names are made distinct by > +identifying the Python implementation (such as CPython, PyPy, Jython, etc.), > the > +major and minor version numbers, and optional build flags (such as "d" for > +debug, "m" for pymalloc, "u" for wide-unicode). For an arbtrary package, > "foo", > +you may see these files when the distribution package is installed:: > + > + /usr/share/pyshared/foo.cpython-32m.so > + /usr/share/pyshared/foo.cpython-33md.so Does it happen by default? I can't see any trace of "pyshared" in the Python source tree. Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] r84513 - python/branches/py3k/Doc/whatsnew/3.2.rst
Am 05.09.2010 13:18, schrieb Antoine Pitrou: > On Sun, 5 Sep 2010 02:27:25 +0200 (CEST) > raymond.hettinger wrote: >> + >> +The common directory is "pyshared" and the file names are made distinct by >> +identifying the Python implementation (such as CPython, PyPy, Jython, >> etc.), the >> +major and minor version numbers, and optional build flags (such as "d" for >> +debug, "m" for pymalloc, "u" for wide-unicode). For an arbtrary package, >> "foo", >> +you may see these files when the distribution package is installed:: >> + >> + /usr/share/pyshared/foo.cpython-32m.so >> + /usr/share/pyshared/foo.cpython-33md.so > > Does it happen by default? I can't see any trace of "pyshared" in the > Python source tree. No; it has to be implemented this way by distributors. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 3149 thoughts
I know the PEP is accepted, but I would still like to see some changes/clarifications. 1. What is the effect of this PEP on Windows? Is this a Linux-only feature? If not, who is going to provide the changes for Windows? (More specifically: if this is indeed meant for Windows, and if no Windows implementation arrives before 3.2b1, I'd ask that the changes be rolled back, and integration is deferred until there is Windows support) 2. Why does the PEP recommend installing stuff into /usr/share/pyshared? According to the Linux FHS, /usr/share is for Architecture- independent data, see http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA In particular, it's objective is that you can NFS-share it across, say, both SPARC Linux and x86 Linux. I believe the PEP would break this, as SPARC and x86 executables would override each other. 3. When the PEP recommends that stuff gets installed into pyshared, why does the patch then not implement this recommendation, but continues installing files into lib-dynload? Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3149 thoughts
Am 05.09.2010 19:22, schrieb "Martin v. Löwis":
> I know the PEP is accepted, but I would still like to see some
> changes/clarifications.
>
> 1. What is the effect of this PEP on Windows? Is this a Linux-only
>feature? If not, who is going to provide the changes for Windows?
>(More specifically: if this is indeed meant for Windows, and
>if no Windows implementation arrives before 3.2b1, I'd ask that
>the changes be rolled back, and integration is deferred until there
>is Windows support)
I don't think Windows support is planned or necessary; after all, isn't the
default installation mode on Windows to install every Python version into
its own root direction (C:\PythonXY)?
> 2. Why does the PEP recommend installing stuff into /usr/share/pyshared?
>According to the Linux FHS, /usr/share is for Architecture-
>independent data, see
>
> http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA
>In particular, it's objective is that you can NFS-share it across,
>say, both SPARC Linux and x86 Linux. I believe the PEP would break
>this, as SPARC and x86 executables would override each other.
Indeed. I think this is probably just an oversight and should be corrected
in the PEP. However, it's the distributions' call anyway.
> 3. When the PEP recommends that stuff gets installed into pyshared,
>why does the patch then not implement this recommendation, but
>continues installing files into lib-dynload?
That section is talking about files installed by distributions, which need
to take special steps to get everything into /usr/{lib,share}/pyshared; a
standard out-of-the-tarball install will not change the way it is installed.
It may well be that Barry had his Ubuntu hat on a bit too firmly when writing
that PEP :)
Georg
--
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of Python tracker Issues
On 3 September 2010 17:41, Paul Moore wrote: > On 3 September 2010 17:30, Victor Stinner > wrote: >> Remember also the buildbot report: >> http://code.google.com/p/bbreport/wiki/PythonBuildbotReport >> >> Eg. there are some "no space left on device" on "x86 XP-5 *" build slaves. > > Thanks, I wasn't aware of that. I'll look into those issues. Odd. There's 2GB free on the disk (not a lot, but it's only a 19GB disk and it's had the same amount of free space for ages). I suspect that it's something that has changed triggering an error which is getting reported as space but isn't actually (IIRC, you can get that error from things like broken pipes on Windows). I'll keep digging when I get the chance, but I've not got much free time just now, so it may be a while... Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3149 thoughts
>> 1. What is the effect of this PEP on Windows? Is this a Linux-only
>>feature? If not, who is going to provide the changes for Windows?
>>(More specifically: if this is indeed meant for Windows, and
>>if no Windows implementation arrives before 3.2b1, I'd ask that
>>the changes be rolled back, and integration is deferred until there
>>is Windows support)
>
> I don't think Windows support is planned or necessary; after all, isn't the
> default installation mode on Windows to install every Python version into
> its own root direction (C:\PythonXY)?
Yes. People are asking to change that to Program Files\Pythonxy, but
that wouldn't change anything wrt. the PEP.
Notice, however, that the PEP also talks about creating different names
for different compilation options of the same Python binary. This
applies to Windows as well (as the PEP actually points out: there is
_d.pyd and .pyd).
In any case, if the PEP is specific to Unix (or even to Linux?), it
should say so (either as a positive list, or a negative one; if
negative, it should also say whether it applies to OSX).
> That section is talking about files installed by distributions, which need
> to take special steps to get everything into /usr/{lib,share}/pyshared; a
> standard out-of-the-tarball install will not change the way it is installed.
>
> It may well be that Barry had his Ubuntu hat on a bit too firmly when writing
> that PEP :)
I think then that the PEP should better separate what is actually being
specified (and apparently, that's just the name of the shared objects),
from possible use case scenarios.
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3149 thoughts
On Mon, Sep 6, 2010 at 3:16 AM, Georg Brandl wrote: > Am 05.09.2010 19:22, schrieb "Martin v. Löwis": >> I know the PEP is accepted, but I would still like to see some >> changes/clarifications. >> >> 1. What is the effect of this PEP on Windows? Is this a Linux-only >> feature? If not, who is going to provide the changes for Windows? >> (More specifically: if this is indeed meant for Windows, and >> if no Windows implementation arrives before 3.2b1, I'd ask that >> the changes be rolled back, and integration is deferred until there >> is Windows support) > > I don't think Windows support is planned or necessary; after all, isn't the > default installation mode on Windows to install every Python version into > its own root direction (C:\PythonXY)? > >> 2. Why does the PEP recommend installing stuff into /usr/share/pyshared? >> According to the Linux FHS, /usr/share is for Architecture- >> independent data, see >> >> http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA >> In particular, it's objective is that you can NFS-share it across, >> say, both SPARC Linux and x86 Linux. I believe the PEP would break >> this, as SPARC and x86 executables would override each other. > > Indeed. I think this is probably just an oversight and should be corrected > in the PEP. However, it's the distributions' call anyway. Reading the related paragraph in the PEP, it seems to me that the use of package as in "these distributions install third party (i.e. non-standard library) packages ..." is too vague. On Ubuntu at least, the package content is spread out over different paths, and only *some* files of the package are put into ...pyshared (namely, the ones that can indeed be shared across different versions, that is onlythe .py files in general, with the .so and the .pyc in /usr/lib/...). I guess this is obvious for Barry and other people accustomed with packaging on debian-like systems, but not so much for others. Maybe the PEP would benefit from a stronger example (for example how is a simple package with a C extension actually installed on the system), but OTOH, this keeps changing between debian/ubuntu versions, so a complete example may be more confusing. cheers, David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
