[Python-Dev] nonlocals() function?
What do we think of adding a built-in nonlocals() function that would be similar to globals() and locals()? Like those functions, it would return a dictionary of variable names and their values. Since we now have the nonlocal statement, it would be consistent to keep the three scopes local/nonlocal/global with parallel capabilities. And it might sometimes be useful for code inside a nested function to see what variables are available at the enclosing level. Steve Bonner ___ 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] nonlocals() function?
Steve Bonner wrote: > What do we think of adding a built-in nonlocals() function that would > be similar to globals() and locals()? Like those functions, it would > return a dictionary of variable names and their values. Since we now > have the nonlocal statement, it would be consistent to keep the > three scopes local/nonlocal/global with parallel capabilities. And it > might sometimes be useful for code inside a nested function to see > what variables are available at the enclosing level. That isn't as easy as it may sound. locals() and globals() are each single namespaces, while the nonlocals may actually span multiple namespaces. Python actually deals with this at compilation time and when the function object is created - the interpreter knows the names of all the nonlocal cells that need to be connected, and creates the appropriate links to the cells in the outer scopes. That situation doesn't translate well to dict-style access - while the whole local namespace is readily accessible to the interpreter, as is a pointer to the module namespace (for globals()), no such convenient data source exists for the full set of possible nonlocal references from an arbitrary function. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ 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] delaying 2.7 beta 1
I am delaying the release of 2.7 beta 1 pending the fixing of http://bugs.python.org/issue8108 and the greening of the buildbots. -- Regards, Benjamin ___ 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] delaying 2.7 beta 1
2010/4/3 Benjamin Peterson : > I am delaying the release of 2.7 beta 1 pending the fixing of > http://bugs.python.org/issue8108 and the greening of the buildbots. After consultation with Antoine I've lowered #8108's priority. I will see if the buildbots shape up... -- Regards, Benjamin ___ 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] Proposing PEP 376
2010/4/2 P.J. Eby : [..] > First, I notice the RECORD paths are listed as being relative to sys.prefix; > I was under the impression that these paths were supposed to be relative to > the base installation location of the library (i.e. site-packages in the > default case). > > That is, that while paths not under sys.prefix were to be absolute, the > paths under sys.prefix were relative to the install location. (Since one of > the original motivating use cases for relative paths in RECORD was to > support relocatable installations, and sharing installations across > platforms, when the code is platform independent code.) Also, the spec > doesn't address installation to paths that aren't under sys.prefix, or what > happens if you use "setup.py install --prefix". > > I'm wondering if perhaps this should be restated as something like: > > * Paths under the base installation location are relative to the base > * Paths not under the base installation location, but under the installation > prefix, are also stored relative to the base, IF the base location is a > subpath of the installation prefix > * All other paths are absolute. > > Where "base location" is the effective --install-lib directory, and prefix > is the effective --prefix. (Which default of course to site-package and > sys.prefix respectively, but the spec shouldn't be in terms of those > defaults.) Sounds like a better solution. > > Second, the RECORD spec is not clear on what happens to the hash field on > .pyc/.pyo files. Is it supposed to be an empty string, a hash of an empty > file, a hash value that's ignored, or...? The example misses pyc/pyo files. Those would have no hash, and I also think the size should be omited as well. I'll update the example. > > Third, what is a "local absolute path"? This term appears several places > but is not defined. It sounds like maybe you mean a path using the local > platform separator, as opposed to a '/'-separated relative path. If that's > the case, this should probably be spelled out somewhere early on and then > referenced in context. Yes, this is it. It was defined somewhere but removed at some point by mistake IIRC. I'll add that > > Fourth, the PEP says the implementation will support zipfiles, but the draft > implementation doesn't appear to support zipimport subdirectories. > (Zipimport paths can be /path/to/some.zip/subdir, and this base is then > used for importing, just as if the zipfile were a normal parent directory.) > If this is an intentional omission, it should probably be mentioned in the > PEP. The implementation so far will load zip files founded in the paths, see ZippedDistributionDir/ZippedDistribution. I am wondering though, if we shouldn't omit this zip story for PEP 376 altogether, and work later on something more generic wrt import protocols where modules/packages could be stored anywhere. IOW, PEP 376 could focus exclusively on a pure filesystem site-packages. > > Okay, on to the minor corrections. The following uses of "package" should > be replaced by "project" or "distribution": > > "If a package that was already installed on the system as a dependency" > "in other words, whether the package was installed by user request" > "$ python -m distutils.uninstall packagename" yes, will edit this. > Anyway, that's my first pass through; I think the RECORD section may need > further fleshing out (e.g., specifying a particular csv-module dialect) in > order to ensure that the spec is sufficiently rigorous for multiple tools to > consume/produce compatible files. Yes, and we should list those tools somewhere in the PEP I guess Regards Tarek -- Tarek Ziadé | http://ziade.org ___ 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] Proposing PEP 376
On Fri, Apr 2, 2010 at 1:56 AM, Glyph Lefkowitz wrote: > First: thank you distutils-sig, and especially Tarek, for spearheading this > effort! Thanks :) > I'm particularly excited about the "Distribution" object that this PEP > specifies. I've been waiting for a long time to be able to load an object > describing a distribution, rather than running setup.py and hoping that it > mutated the right state! Notice that this Distribution class will work with installed distributions, where the info where built by running setup.py. As opposed to distritbutions that are not yet installed where these infos are still hidden in setup.py. Although we are currently working in distutils2 to get rid of setup.py and have a pure static metadata file. > On Apr 1, 2010, at 5:51 PM, Tarek Ziadé wrote: > > - to provide a basic *uninstaller* feature in the distutils2 project. > > Second: It seems to me that a major missing feature in the PEP is the > ability to run some code during installation and uninstallation, especially > since it is so easy to run ad-hoc code in setup.py with no way of un-doing > what it did. That was a feature request for distutils: install/removal hooks like what RPM or the msi installer offers. I think this could be done in distutils2 no matter what happens to the PEP. I am adding this in the bug tracker. > Third: The PEP is silent on what happens to files whose hash _has_ changed > from its install-time value. I guess the implied plan would be to leave > them in place. However, this may have nasty side-effects; for example, if > the files are test files, then they might be loaded during test discovery, > and report exceptions since the code that they're testing has been removed. > My suggestion would be to have a specific "quarantine" area where the > distutils uninstaller can put modified files that would have been removed as > part of a specific distribution, so they aren't still present on PYTHONPATH. > I can also think of reasons why you might not want to do this, but either > way, the consequence of changing an installed file should be made explicitly > clear in the PEP: if they are to be left in place, it should emphasize that > point. The strategy about what should be done with modified files upon uninstallation is up to the implementation I guess. But the PEP should mention what Distutils2 basic uninstall function should do. The quarantine strategy sounds like a great idea. I propose to add this in the PEP in the implementation details section, and say in the specs that it's up to the implementation to decide. > Finally, one minor bit of bikeshedding, of which I promise to say nothing > more if there is not unanimous agreement: I dislike the use of "get_" in > function names, since it adds more characters without really adding more > information. get_file_users is particularly bad, since it makes me think > that it's going to return a list of processes with a file open, or a list of > UIDs or something like that. I suggest these names instead: > get_distributions() -> active_distributions() > get_distribution(name) -> active_distribution_named(name) > get_file_users(path) -> distributions_using_path(path) > where "active" means "on the current sys.path and thereby accessible by > 'import'". "active" sounds superfluous too I think, since all distributions that are found *are* active. So it could be "distributions()". But I am not comfortable with this single word because it sounds to me like a sequence object rather than a function. But that might be just me.. > This naming would also make the behavior of get_file_users a bit > clearer; if the intention is to return only active, loadable distributions > (you don't want to be able to use get_file_users to inspect other Python > installations or virtualenvs) it could be called > active_distributions_using_path. +1 on distributions_using_path() > Thanks again to the PEP's author and many contributors, Thanks for the feedback ! -- Tarek Ziadé | http://ziade.org ___ 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] Odd lines in unicodedata_db.h
I've just downloaded the daily snapshot at
http://svn.python.org/snapshots/python.tar.bz2
In the header file /python/Modules/unicodedata_db.h, there are the
following lines in the change_records_3_2_0 struct:
{ 255, 255, 255, 255, 1.0 },
{ 255, 255, 255, 255, 2.0 },
{ 255, 255, 255, 255, 3.0 },
{ 255, 255, 255, 255, 4.0 },
...
{ 255, 255, 255, 255, 1e+16 },
{ 255, 255, 255, 255, 1e+20 },
Looks like a bug to me.
___
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
