Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)
outbound x = 1 x = 2 evaluating using Jeremy Hilton's' list: 1. is a real word 2. For me - in python - it would mean: Is found in 'outer' scope and is already bound. And the literal meaning of 'outbound 'headed away' [1] is pretty darn close to what I mean when I spell the usual mutables kluge. 3 statement is positive form 4. I like it could not find a use of outbound in python source (2.4.3) [1] http://dictionary.reference.com/search?q=outbound Robin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 2.5b3, commit r46372 regressed PEP 302 machinery (sf not letting me post)
Hi,
Appologies for the lack of an sf#. I tried to submit this there but
couldn't. (sf is logging me out each time I visit a new page and it is
refusing my attempt to post anonymously).
Python 2.5b3 (trunk:51136M, Aug 7 2006, 10:48:15)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
The need for speed patch commited in revision r46372 included a change
whose intent was to reduce the number of open calls. The `continue`
statement at line 1283 in import.c:r51136 has the effect of skipping
the builtin import machinery if the find_module method of a custom
importer returns None.
In Python 2.4.3, if find_module returned None the builtin machinery is
allowed to process the path tail.
In my particular case I am working on an importer that deals with kid
templates that may or may not exist as .py[c] files.
The short of it is that in Python 2.4.3 this produces a usable module
``__import__('foo.a/templateuri')`` wheras in 2.5b3 I get import
error. The python 2.4.3 implementation *allows* module paths that are
not seperated with '.' Python 2.5b3 does not allow this and it does
not look like this was an intentional change. I believe this point
about 'illeagal' module paths is actualy independent of the regresion
I am asserting. Detailed session logs are attatched (following the sf
guidance even though I'm posting to py-dev)
The 'use case' for the importer is: Robin wants to package a default
template file as normal python module and provide a custom importer
that allows users of his package to reference both: there own
templates and html files on the file system in arbitrary locations AND
the stock templates provided as python modules under the same name
space. He would like to leave normal imports to the standard
machinery.
Cheers,
Robin
bugreport.rst
Description: Binary data
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5b3, commit r46372 regressed PEP 302 machinery (sf not letting me post)
This has an sf number now #1537167, and hopefully a clearer
explanation of what I think the problem is. This is not a duplicate of
the earlier "PEP 302 Fix" thread.
Thanks,
Robin
On 07/08/06, Robin Bryce <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Appologies for the lack of an sf#. I tried to submit this there but
> couldn't. (sf is logging me out each time I visit a new page and it is
> refusing my attempt to post anonymously).
>
> Python 2.5b3 (trunk:51136M, Aug 7 2006, 10:48:15)
> [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
>
>
> The need for speed patch commited in revision r46372 included a change
> whose intent was to reduce the number of open calls. The `continue`
> statement at line 1283 in import.c:r51136 has the effect of skipping
> the builtin import machinery if the find_module method of a custom
> importer returns None.
>
> In Python 2.4.3, if find_module returned None the builtin machinery is
> allowed to process the path tail.
>
> In my particular case I am working on an importer that deals with kid
> templates that may or may not exist as .py[c] files.
>
> The short of it is that in Python 2.4.3 this produces a usable module
> ``__import__('foo.a/templateuri')`` wheras in 2.5b3 I get import
> error. The python 2.4.3 implementation *allows* module paths that are
> not seperated with '.' Python 2.5b3 does not allow this and it does
> not look like this was an intentional change. I believe this point
> about 'illeagal' module paths is actualy independent of the regresion
> I am asserting. Detailed session logs are attatched (following the sf
> guidance even though I'm posting to py-dev)
>
> The 'use case' for the importer is: Robin wants to package a default
> template file as normal python module and provide a custom importer
> that allows users of his package to reference both: there own
> templates and html files on the file system in arbitrary locations AND
> the stock templates provided as python modules under the same name
> space. He would like to leave normal imports to the standard
> machinery.
>
> Cheers,
>
> Robin
>
>
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
> Actually, I meant that (among other things) it should be clarified that > it's alright to e.g. put .pyc and data files inside Python library > directories, and NOT okay to split them up. Phillip, Just to be clear: I understand you are not in favour of re-packaging data from python projects (projects in the distutils sense), separately and I strongly agree with this view. Are you opposed to developers choosing to *not* bundle data as python package data ? How much, if any, of the setuptools / distutils conventions do you think could sensibly peculate up to the LSB ? There are a couple of cases in ubuntu/debian (as of 6.10 edgy) that I think are worth considering: python2.4 profile (pstats) etc, was removed due to licensing issues rather than FHS. Should not be an issue for python2.5 but what, in general, can a vendor do except break python if their licensing policy cant accommodate all of pythons batteries ? python2.4 distutils is excluded by default. This totally blows in my view but I appreciate this one is a minefield of vendor packaging politics. It has to be legitimate for Python / setuptools too provide packaging infrastructure and conventions that are viable on more than linux. Is it unreasonable for a particular vendor to decide that, on their platform, the will disable Python's packaging conventions ? Is there any way to keep the peace on this one ? Cheers, Robin On 27/11/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 02:38 PM 11/27/2006 +0100, Jan Matejek wrote: > >-BEGIN PGP SIGNED MESSAGE- > >Hash: SHA1 > > > >Phillip J. Eby napsal(a): > > > Just a suggestion, but one issue that I think needs addressing is the FHS > > > language that leads some Linux distros to believe that they should change > > > Python's normal installation layout (sometimes in bizarre ways) (...) > > > Other vendors apparently also patch Python in various > > > ways to support their FHS-based theories of how Python should install > > > files. > > > >+1 on that. There should be a clear (and clearly presented) idea of how > >Python is supposed to be laid out in the distribution-provided /usr > >hierarchy. And it would be nice if this idea complied to FHS. > > > >It would also be nice if somebody finally admitted the existence of > >/usr/lib64 and made Python aware of it ;e) > > Actually, I meant that (among other things) it should be clarified that > it's alright to e.g. put .pyc and data files inside Python library > directories, and NOT okay to split them up. > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/robinbryce%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
On 28/11/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > I personally agree that "Linux standards" should specify a standard > layout for a Python installation, and that it should be the one that > "make install" generates (perhaps after "make install" is adjusted). > Whether or not it is the *LSB* that needs to specify that, I don't > know, because the LSB does not specify a file system layout. Instead, > it incorporates the FHS - which might be the right place to define > the layout of a Python installation. For the LSB, it's more import > that "import httplib" gives you something working, no matter where > httplib.py comes from (or whether it comes from httplib.py at all). Yes, especially with the regard to the level you pitch for LSB. I would go as far as to say that if this "contract in spirit" is broken by vendor repackaging they should: * Call the binaries something else because it is NOT python any more. * Setup the installation layout so that it does NOT conflict or overlap with the standard layout. * Call the whole package something else. But I can't see that happening. Is it a bad idea to suggest that: Python grows a vendor_variant attribute somewhere in the standard lib; That its content is completely dictated by a new ./configure argument which is the empty string by default; And, request that it is left empty by re-packagers if the installation is 'reasonably standard' ? I would strongly prefer _not_ write code that is conditional on such an attribute. However if there was a clear way for a vendor to communicate "This is not a standard python runtime" to the python run time, early failure (in the application) with informative error messages becomes much more viable. Eg sys.vendor_variant would be orthogonal to sys.version and sys.version_info Given: python -c "import sys; print sys.version" GCC 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5) A regex on sys.version does not seem like a good way to get positive confirmation I'm using the "Canonical" variant (pun intended) python -c "from distutils.util import get_platform; print get_platform()" Tells me nothing about the vendor of my linux distribution. Except, ironically, when it says ImportError Cheers, Robin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python and the Linux Standard Base (LSB)
Fair enough. Robin On 30/11/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Robin Bryce schrieb: > > Yes, especially with the regard to the level you pitch for LSB. I > > would go as far as to say that if this "contract in spirit" is broken > > by vendor repackaging they should: > > * Call the binaries something else because it is NOT python any more. > > * Setup the installation layout so that it does NOT conflict or > > overlap with the standard layout. > > * Call the whole package something else. > > I think that would be counter-productive. If applied in a strict > sense, you couldn't call it Python anymore if it isn't in /usr/local. > I see no point to that. > > It shouldn't be called Python anymore if it doesn't implement > the Python language specification. No vendor is modifying it > in such a way that > > print "Hello" > > stops working. > > > Is it a bad idea to suggest that: Python grows a vendor_variant > > attribute somewhere in the standard lib; That its content is > > completely dictated by a new ./configure argument which is the empty > > string by default; And, request that it is left empty by re-packagers > > if the installation is 'reasonably standard' ? > > I'm not sure in what applications that would be useful. > > > I would strongly prefer _not_ write code that is conditional on such > > an attribute. However if there was a clear way for a vendor to > > communicate "This is not a standard python runtime" to the python run > > time, early failure (in the application) with informative error > > messages becomes much more viable. > > Again: none of the vendors modifies Python in a way that what > you get is "not a standard Python runtime". They *all* > are "standard Python runtimes". > > Regards, > Martin > ___ Python-Dev mailing list Python-Dev@python.org 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 3103: A Switch/Case Statement
> PEP 3103, When to Freeze the Dispatch Dict/Option 1 2 things resonated with me for Raymond's proposal and the follow up: - It seemed agnostic to almost all of the independently contentious issues. - "is defined tightly enough to allow room for growth and elaboration over time" [Raymond]. In particular it left room for const/static/only/cached/etc to come along later. I think its worth acknowledging this in the PEP. Is nothing better than something in this case ? I don't know. > I think we need a PEP for const/static/only/cached/precomputed or > whatever people like to call it. > > Once we have (say) static, I think making the case expressions static > by default would still cover all useful cases, and would allow us to > diagnose duplicate cases reliably (which the if/elif chain semantics > don't allow IIUC). If the expectation is that static/const will evolve as a sibling pep, does this not make Raymond's suggestion any more appealing, even a little ? Is it unacceptable - or impractical - to break the addition of switch to python in two (minor version separated) steps ? Robin ___ Python-Dev mailing list Python-Dev@python.org 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 3103: A Switch/Case Statement
> But what's the point? We have until Python 3000 anyway. Ah, my mistake. In my enthusiasm, I foolishly got the time frames of peps 3103 & 275 mixed up. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
