Re: [Python-Dev] PEP 3147: PYC Repository Directories
On Wed, Feb 03, 2010 at 06:14:44PM +1100, Ben Finney wrote: > Barry Warsaw writes: > > > I suppose this is going to be very subjective, but in skimming the > > thread it seems like most people like putting the byte code cache > > artifacts in subdirectories (be they siblings or folder-per-folder). > > I don't understand the distinction you're making between those two > options. Can you explain what you mean by each of “siblings” and > “folder-per-folder”? sibilings: the original proposal, i.e.: foo.py foo.pyr/ MAGIC1.pyc MAGIC1.pyo ... bar.py bar.pyr/ MAGIC1.pyc MAGIC1.pyo ... folder-per-folder: foo.py bar.py __pyr__/ foo.MAGIC1.pyc foo.MAGIC1.pyo foo.MAGIC2.pyc bar.MAGIC1.pyc ... IIUC Personally I'm +1 on the folder-per-folder option. Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.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] PEP 3147: PYC Repository Directories
On approximately 2/2/2010 7:05 PM, came the following characters from the keyboard of Guido van Rossum: On Tue, Feb 2, 2010 at 5:41 PM, Glenn Linderman wrote: On approximately 2/2/2010 4:28 PM, came the following characters from the keyboard of Guido van Rossum: Argh. zipfiles are way to complex to be writing. Agreed. But in reading that, it somehow triggered a question: does zipimport only work for zipfiles, or does it work for any archive format that Python stdlib knows how to decode? And if only the former, why are they so special? The former. They are special because (unlike e.g. tar files) you can read the table of contents of a zipfile without parsing the entire file. They are not unique in this... most archive formats except tar have a directory. But that is likely a good reason not to support tar for this purpose, especially since tar usually comes found as .tar.Z or .tar.gz or .tar.bz2 etc. and would require two passes before the data could be found at all. Also because they are universally supported which makes it unnecessary to support other formats. Again, contrast tar files which are virtually unheard of on Windows. This may well be true, at least for some definitions of Universal. However, for the definition of Universal that matters to the discussion, is all the platforms on which Python is supported... and certainly all those platforms have support for all the archive formats in Python's stdlib, eh? Oh! Sorry, I had jumped to the conclusion that the stdlib (because of the batteries included philosophy) supported things like 7z and rar files, since they've been around for years, but I see there is a limited selection there. OK, I found the ticket that suggests adding 7z and nosied myself. Didn't bother to look for rar, because I'm a 7z fan, and it has better compression factors in most cases. -- Glenn “Everyone is entitled to their own opinion, but not their own facts. In turn, everyone is entitled to their own opinions of the facts, but not their own facts based on their opinions.” -- Guy Rocha, retiring NV state archivist ___ 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 3147: PYC Repository Directories
On 03/02/2010 06:50, Barry Warsaw wrote: I have to say up front that I'm somewhat shocked at how quickly this thread has exploded! Since I'm sprinting this week, I haven't thoroughly read every message and won't have time tonight to answer every question, but I'll try to pick out some common ideas. I really appreciate everyone's input and will try to clarify the PEP where I can. It is probably not clear enough from the PEP, but I actually don't expect that most individual Python developers will use this feature. This is why the -R flag exists and the behavior is turned off by default. The fact that it doesn't affect most developers makes it the *perfect* opportunity to bikeshed... :-) Michael When I'm developing some Python code in my home directory, I usually only use one Python version and even if I'm going to test it with multiple Python versions, I won't need to do this *simultaneously*. I will generally blow away all build artifacts (including, but not limited to .pyc files) and then rebuild with the different Python version. I think that this feature will be limited mostly to distros, which have different use cases than individual developers. But these are important use cases for Python to support nonetheless. My rationale for choosing the file system layout in the PEP was to try to present something more familiar to today's Python and to avoid radical reorganization of the way Python caches its byte code. Thus having a sibling directory that differs from the source just by extension seemed more natural to me. Encoding the magic number in the file name under .pyr would I thought make the look up scheme more efficient since the import machinery can craft the file name directly. I agree it's not very human friendly because nobody really knows which magic numbers are associated with which Python versions and flags. As to the question of sibling directories or folder-per-folder I think performance issues should be the deciding factor. There are file system limitations to consider (but also a wide variety of file systems in use). Do the number of stat calls predominate the performance costs? Maybe it makes sense to implement the two different approaches and do some measurements. -Barry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies ("BOGUS AGREEMENTS") that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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 3147: PYC Repository Directories
> On 03/02/2010 06:50, Barry Warsaw wrote:
>> As to the question of sibling directories or folder-per-folder I think
>> performance issues should be the deciding factor. There are file system
>> limitations to consider (but also a wide variety of file systems in
>> use). Do
>> the number of stat calls predominate the performance costs? Maybe it
>> makes
>> sense to implement the two different approaches and do some measurements.
How about using an optionally relative cache dir setting to let
the user decide ?
import imp, os
# Get cache dir, default to module_dir
cache_dir = os.environ.get('PYTHONCACHEDIR', '.')
# Get names and versions
module_cache_type = 'pyc'
module_cache_version = imp.get_magic().encode('hex')
module_name = module.__name__
module_cache_file = '%s.%s.%s' % (module_name, module_cache_version,
module_cache_type)
module_dir = os.path.split(module.__file__)[0]
# Determine cache dir and cache file pathname
module_cache_dir = os.path.abspath(os.path.join(module_dir, cache_dir))
module_cache_pathname = os.path.join(module_cache_dir, module_cache_file)
# Write PYC data to module_cache_pathname
...
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Feb 03 2010)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free !
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
___
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 3146: Merge Unladen Swallow into CPython
Reid Kleckner wrote: > On Tue, Feb 2, 2010 at 8:57 PM, Collin Winter wrote: >>> Wouldn't it be possible to have the compiler approach work >>> in three phases in order to reduce the memory footprint and >>> startup time hit, ie. >>> >>> 1. run an instrumented Python interpreter to collect all >>>the needed compiler information; write this information into >>>a .pys file (Python stats) >>> >>> 2. create compiled versions of the code for various often >>>used code paths and type combinations by reading the >>>.pys file and generating an .so file as regular >>>Python extension module >>> >>> 3. run an uninstrumented Python interpreter and let it >>>use the .so files instead of the .py ones >>> >>> In production, you'd then only use step 3 and avoid the >>> overhead of steps 1 and 2. >> >> That is certainly a possibility if we are unable to reduce memory >> usage to a satisfactory level. I've added a "Contingency Plans" >> section to the PEP, including this option: >> http://codereview.appspot.com/186247/diff2/8004:7005/8006. > > This would be another good research problem for someone to take and > run. The trick is that you would need to add some kind of "linking" > step to loading the .so. Right now, we just collect PyObject*'s, and > don't care whether they're statically allocated or user-defined > objects. If you wanted to pursue offline feedback directed > compilation, you would need to write something that basically can map > from the pointers in the feedback data to something like a Python > dotted name import path, and then when you load the application, look > up those names and rewrite the new pointers into the generated machine > code. It sounds a lot like writing a dynamic loader. :) You lost me there :-) I am not familiar with how U-S actually implements the compilation step and was thinking of it working at the functions/methods level and based on input/output parameter type information. Most Python functions and methods have unique names (when combined with the module and class name), so these could be used for the referencing and feedback writing. The only cases where this doesn't work too well is dynamic programming of the sort done in namedtuples: where you dynamically create a class and then instantiate it. Type information for basic types and their subclasses can be had dynamically (there's also a basic type bitmap for faster lookup) or in a less robust way by name. For the feedback file the names should be a good reference. > It sounds like a huge amount of work, and we haven't approached it. > On the other hand, it sounds like it might be rewarding. Indeed. Perhaps this could be further investigated in a SoC project ?! -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 03 2010) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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 3147: PYC Repository Directories
Barry Warsaw python.org> writes: > > As to the question of sibling directories or folder-per-folder I think > performance issues should be the deciding factor. There are file system > limitations to consider (but also a wide variety of file systems in use). Do > the number of stat calls predominate the performance costs? Maybe it makes > sense to implement the two different approaches and do some measurements. How about doing measurements /with the current implementation/? Everyone seems to worry about stat() calls but there doesn't seem to be any figures to evaluate their significance. Thanks 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
[Python-Dev] python -U
Le Tue, 02 Feb 2010 22:57:11 -0800, Barry Warsaw a écrit : > On Jan 31, 2010, at 01:44 PM, Nick Coghlan wrote: > >>We deliberate don't document -U because its typical effect is "break the >>world" - it makes all strings unicode in 2.x. > > As an aside, I think this should be documented *somewhere* other than > just in import.c! I'd totally forgotten about it until I read the > source and almost missed it. Either it should be documented or it > should be ripped out. The -U option is already gone in 3.x. ___ 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 3147: PYC Repository Directories
Ben Finney wrote: > I don't think keeping the cache files in a mass of intertwingled extra > subdirectories is the way to solve that problem. That speaks, rather, to > the need for Python to be able to find the file on behalf of the user > and blow it away on request, so the user doesn't need to go searching. > > Possible interface (with spelling of options chosen hastily):: > > $ python foo.py# Use cached byte code if available. > $ python --force-compile foo.py# Unconditionally compile. > > If removing the byte code file, without running the module, is what's > desired:: > > $ python --delete-cache foo.py # Delete cached byte code. > $ rm $(python --show-cache-file foo.py) # Same as above. > > That should cover just about any common need for the user to know > exactly which byte code file corresponds to a given source file. That, > in turn, frees us to choose a less obtrusive location for the byte code > files than mingled in with the source. That's nice in theory, but tricky in practice given the intended flexibility of the import system (i.e. we don't want to perpetrate new import features that aren't part of the common importer interface, so any such proposal would need to come complete with suggested extensions to the PEP 302 importer protocol). It's also the case that having to run Python to manage my own filesystem would very annoying. If a dev has a broken .pyc that prevents the affected Python build from even starting how are they meant to use the nonfunctioning interpreter to find and delete the offending file? How is someone meant to find and delete the .pyc files if they prefer to use a graphical file manager over (or in conjunction with) the command line? We can provide a utility script in the Python distribution to copy a source tree without the Python cache directories easily enough, which would be far simpler than providing the extra tools to cherry pick compilation or deletion of individual cache files. 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] __file__
Barry Warsaw python.org> writes: > > Python 3 uses the .py file for __file__ but I'd like to see a transition to > __source__ for that, with __cache__ for the location of the PVM, JVM, LLVM or > whatever compilation cache artifact file. Well, I don't think we need another transition... Just keep __file__ for the source file, and add a __cache__ or __compiled__ attribute for the compiled file(s). Since there might be several compiled files for a single source file (for example, a .pyc along with a JITted native .so), __cache__ should probably be a tuple rather than a string. Regards 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
[Python-Dev] The fate of the -U option
Barry Warsaw wrote: > On Jan 31, 2010, at 01:44 PM, Nick Coghlan wrote: > >> We deliberate don't document -U because its typical effect is "break the >> world" - it makes all strings unicode in 2.x. > > As an aside, I think this should be documented *somewhere* other than just in > import.c! I'd totally forgotten about it until I read the source and almost > missed it. Either it should be documented or it should be ripped out. Ripping it out is probably a reasonable idea given that there is a much better approach available now (i.e. trying to run under Py3k) that actually has a vague hope of working. Then again, if 2.7 really is the last non-maintenance 2.x release, what's to be gained by messing with it? 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
Re: [Python-Dev] PEP 3147: PYC Repository Directories
Floris Bruynooghe wrote: > Personally I'm +1 on the folder-per-folder option. Of all the proposed options, I also dislike the SVN/CVS style folder structure the least ;) Cheers, Nick. P.S. Translation of the double negative: I don't find any of the solutions, even the current .pyc/.pyo approach, to be particularly elegant, so I can't really say I like any of them in an absolute sense. However, having a single cache folder inside each Python source folder seems to strike the best balance between keeping a tidy filesystem and still being able to locate a cached file given only the location of the source file (or vice-versa) without using any Python-specific tools, so it is the approach I personally prefer. -- 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
Re: [Python-Dev] PEP 3147: PYC Repository Directories
Bob Ippolito wrote: > I like this option as well, but why not just name the directory .pyc > instead of __pyr__ or .pyr? That way people probably won't even have > to reconfigure their tools to ignore it :) This actually came up in another part of the thread. The conclusion was that, since the cached Python files can significantly affect the way Python executes, it would be better not to use dot-files or set the hidden attribute in the folder's metadata (on filesystems that support that). 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
Re: [Python-Dev] PEP 3147: PYC Repository Directories
Glenn Linderman wrote: > On approximately 2/2/2010 7:05 PM, came the following characters from > the keyboard of Guido van Rossum: >> On Tue, Feb 2, 2010 at 5:41 PM, Glenn >> Linderman wrote: >>> Agreed. But in reading that, it somehow triggered a question: >>> does zipimport only work for zipfiles, or does it work for any >>> archive format that Python stdlib knows how to decode? And if >>> only the former, why are they so special? >>> >> The former. >> >> They are special because (unlike e.g. tar files) you can read the >> table of contents of a zipfile without parsing the entire file. > > They are not unique in this... most archive formats except tar have a > directory. But that is likely a good reason not to support tar for > this purpose, especially since tar usually comes found as .tar.Z or > .tar.gz or .tar.bz2 etc. and would require two passes before the data > could be found at all. It's also because nobody has done the work to hook up any additional archive formats (as zipimport needs to work for importing the standard library itself, it isn't quite as simple as just importing an extra module to do the manipulation. Extending the test suite to cover a new archive format would require some work as well). Given that zip files already work and are almost universal, I figure folks have just opted to use that and then found other things to do with their coding time :) 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
Re: [Python-Dev] PEP 3147: PYC Repository Directories
Barry Warsaw wrote: > Encoding the magic number in the file name under .pyr would I thought make the > look up scheme more efficient since the import machinery can craft the file > name directly. I agree it's not very human friendly because nobody really > knows which magic numbers are associated with which Python versions and flags. Having a lookup dictionary from Python version + C API magic numbers to the magic strings used in cache filenames in the import engine shouldn't be too tricky. I'll admit it wasn't until the thread had already been going for a while that I realised that, though :) 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
Re: [Python-Dev] Absolute imports in Python 2.x?
On Tue, Feb 2, 2010 at 1:20 PM, Eric Smith wrote: > Mark Dickinson wrote: >> >> What are the current plans for PEP 328 (the absolute imports PEP) in >> Python 2.x? > Not sure about the decision one way or the other. But if there's not going > to be a 2.8, and if DeprecationWarnings are off by default anyway, I'm not > sure it makes any sense to add a DeprecationWarning in 2.7. From my quick > testing, -3 doesn't warn about relative imports. Perhaps a better strategy > in this particular case is to make -3 give that warning? Well, if there's any possibility at all of a Python 2.8 (and it's not clear to me whether this has been absolutely ruled out) then it's conceivable that the people producing it might want to make imports absolute for 2.8, perhaps as part of an effort to minimize 2.x -> 3.x differences. A DeprecationWarning in 2.7 would help with that. On the other hand, it's easy enough to use the 'from __future__ import' in 2.x code. At any rate, it's clear that there should be a -3 warning. I'll open an issue. > Aside: > We really need a better way to track things we need to do in the next > version of Python so things like this don't fall through the cracks. We > added a 3.2 version tag before 3.1 was released so that we could add a few > "remember to do this in 3.2" issues dealing with deprecations. Perhaps it's > time to add a 3.3 version tag? I don't think we should add a 2.8 tag, that > would give false hope. Agreed on all points. Would it be terrible to simply add all relevant tags the moment a PEP is accepted? E.g., if a PEP pronounces some particular behaviour deprecated in Python 3.3 and removed in Python 3.4, then corresponding release blockers for 3.3 and 3.4 could be opened as part of implementing the PEP. Mark ___ 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] __file__
On Wed, Feb 3, 2010 at 3:07 PM, Antoine Pitrou wrote: > Since there might be several compiled files for a single source file (for > example, a .pyc along with a JITted native .so), __cache__ should probably be > a > tuple rather than a string. But presumably there is only one compiled file that is in use by the current Python instance? Schiavo Simon ___ 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] Absolute imports in Python 2.x?
Mark Dickinson wrote: > Agreed on all points. Would it be terrible to simply add all relevant > tags the moment a PEP is accepted? E.g., if a PEP pronounces some > particular behaviour deprecated in Python 3.3 and removed in Python > 3.4, then corresponding release blockers for 3.3 and 3.4 could be > opened as part of implementing the PEP. That strikes me as a really good idea, since the tracker already serves as a global "to do" list for the project (heck, I've used it as a semi-private to do list at times, when I've thought of things I need to fix when I don't have the roundtuits free to actually fix them). 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
Re: [Python-Dev] Python 2.6.5
On Feb 2, 2010, at 1:08 PM, Barry Warsaw wrote: > I'm thinking about doing a Python 2.6.5 release soon. I've added the > following dates to the Python release schedule Google calendar: > > 2009-03-01 Python 2.6.5 rc 1 > 2009-03-15 Python 2.6.5 final > > This allows us to spend some time on 2.6.5 at Pycon if we want. Please let > me know if you have any concerns about those dates. This patch is still waiting a review and backporting from trunk. http://mail.python.org/pipermail/python-dev/2009-October/092771.html Can we get it in? Zvezdan ___ 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] Absolute imports in Python 2.x?
Mark Dickinson wrote: On Tue, Feb 2, 2010 at 1:20 PM, Eric Smith wrote: Mark Dickinson wrote: What are the current plans for PEP 328 (the absolute imports PEP) in Python 2.x? Not sure about the decision one way or the other. But if there's not going to be a 2.8, and if DeprecationWarnings are off by default anyway, I'm not sure it makes any sense to add a DeprecationWarning in 2.7. From my quick testing, -3 doesn't warn about relative imports. Perhaps a better strategy in this particular case is to make -3 give that warning? Well, if there's any possibility at all of a Python 2.8 (and it's not clear to me whether this has been absolutely ruled out) then it's conceivable that the people producing it might want to make imports absolute for 2.8, perhaps as part of an effort to minimize 2.x -> 3.x differences. A DeprecationWarning in 2.7 would help with that. Certainly the DeprecationWarning couldn't hurt. On the other hand, it's easy enough to use the 'from __future__ import' in 2.x code. At any rate, it's clear that there should be a -3 warning. I'll open an issue. Thanks. I'll look at implementing it (and the DeprecationWarning) at PyCon. Agreed on all points. Would it be terrible to simply add all relevant tags the moment a PEP is accepted? E.g., if a PEP pronounces some particular behaviour deprecated in Python 3.3 and removed in Python 3.4, then corresponding release blockers for 3.3 and 3.4 could be opened as part of implementing the PEP. +1. ___ 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] The fate of the -U option
Nick Coghlan wrote: > Barry Warsaw wrote: >> On Jan 31, 2010, at 01:44 PM, Nick Coghlan wrote: >> >>> We deliberate don't document -U because its typical effect is "break the >>> world" - it makes all strings unicode in 2.x. It only affects string literals, not all strings. >> As an aside, I think this should be documented *somewhere* other than just in >> import.c! I'd totally forgotten about it until I read the source and almost >> missed it. Either it should be documented or it should be ripped out. > > Ripping it out is probably a reasonable idea given that there is a much > better approach available now (i.e. trying to run under Py3k) that > actually has a vague hope of working. > > Then again, if 2.7 really is the last non-maintenance 2.x release, > what's to be gained by messing with it? Nothing much, but then it's been undocumented for a number of releases in order to be able to remove it at some point, so +1 to get rid off it for 2.7. Note that in Python 2.7 you can use from __future__ import unicode_literals on a per module basis to achieve much the same effect. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 03 2010) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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] The fate of the -U option
On 02:52 pm, [email protected] wrote: Note that in Python 2.7 you can use from __future__ import unicode_literals on a per module basis to achieve much the same effect. In Python 2.6 as well. Jean-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] The fate of the -U option
[email protected] wrote: > On 02:52 pm, [email protected] wrote: >> >> Note that in Python 2.7 you can use >> >> from __future__ import unicode_literals >> >> on a per module basis to achieve much the same effect. > > In Python 2.6 as well. Right, but there are a few issues in 2.6 that will be fixed in 2.7. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 03 2010) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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] The fate of the -U option
On 03:21 pm, [email protected] wrote: [email protected] wrote: On 02:52 pm, [email protected] wrote: Note that in Python 2.7 you can use from __future__ import unicode_literals on a per module basis to achieve much the same effect. In Python 2.6 as well. Right, but there are a few issues in 2.6 that will be fixed in 2.7. Ah. I don't see anything on the "What's New" page. Got a link? Jean-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 3147: PYC Repository Directories
On Feb 03, 2010, at 11:31 PM, Nick Coghlan wrote: >Having a lookup dictionary from Python version + C API magic numbers to >the magic strings used in cache filenames in the import engine shouldn't >be too tricky. I'll admit it wasn't until the thread had already been >going for a while that I realised that, though :) I agree, and it's clear that would be much more user friendly. I've added a note to my working copy of the PEP and leave that as a possible design change. I'm still not certain what the right mapping would be though. Python version numbers don't seem quite right, but maybe they are a "good enough" solution. -Barry signature.asc Description: PGP signature ___ 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 3147: PYC Repository Directories
On Feb 03, 2010, at 12:57 PM, Antoine Pitrou wrote: >How about doing measurements /with the current implementation/? Everyone >seems to worry about stat() calls but there doesn't seem to be any figures to >evaluate their significance. Yes, very good idea, if for no other reason than to give us a baseline for comparison. Added to the PEP. -Barry signature.asc Description: PGP signature ___ 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] The fate of the -U option
[email protected] wrote: > On 03:21 pm, [email protected] wrote: >> [email protected] wrote: >>> On 02:52 pm, [email protected] wrote: Note that in Python 2.7 you can use from __future__ import unicode_literals on a per module basis to achieve much the same effect. >>> >>> In Python 2.6 as well. >> >> Right, but there are a few issues in 2.6 that will be fixed >> in 2.7. > > Ah. I don't see anything on the "What's New" page. Got a link? http://mail.python.org/pipermail/python-dev/2009-January/085110.html http://bugs.python.org/issue4978 and related: http://bugs.python.org/issue2931 http://bugs.python.org/issue4319 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 03 2010) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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] Rational for PEP 3147 (PYC Respository Directories)
Hi Barry, Thanks for doing the work of writing a PEP. The rational section could use some strengthing, I think. Who is benefiting from this feature? Is it the distribution package maintainers? Maybe people who use a distribution packaged Python and install packages from PyPI. It's not clear to me, anyhow. Who will set the -R flag or the PYTHONPYR environment variable? If you could add some example use cases that would be very helpful. Neil ___ 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] The fate of the -U option
On Feb 03, 2010, at 11:10 PM, Nick Coghlan wrote: >Ripping it out is probably a reasonable idea given that there is a much >better approach available now (i.e. trying to run under Py3k) that >actually has a vague hope of working. > >Then again, if 2.7 really is the last non-maintenance 2.x release, >what's to be gained by messing with it? Well, in case we decide to do it, this bug tracks that effort: http://bugs.python.org/issue7847 -Barry signature.asc Description: PGP signature ___ 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] Rational for PEP 3147 (PYC Respository Directories)
Neil Schemenauer arctrix.com> writes: > > Thanks for doing the work of writing a PEP. The rational section > could use some strengthing, I think. Who is benefiting from this > feature? Is it the distribution package maintainers? Maybe people > who use a distribution packaged Python and install packages from > PyPI. It's not clear to me, anyhow. It would also be nice to have other packagers' take on this (Redhat, Mandriva, etc.). But of course you aren't responsible if they don't show up. cheers 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] The fate of the -U option
On Feb 03, 2010, at 04:21 PM, M.-A. Lemburg wrote: >[email protected] wrote: >> On 02:52 pm, [email protected] wrote: >>> >>> Note that in Python 2.7 you can use >>> >>> from __future__ import unicode_literals >>> >>> on a per module basis to achieve much the same effect. >> >> In Python 2.6 as well. > >Right, but there are a few issues in 2.6 that will be fixed >in 2.7. The one that bites me most often is that in 2.6, keyword arguments must be strs; unicodes are not accepted: -snip snip- from __future__ import unicode_literals def func(foo, bar): print foo, bar kw = {'foo': 7, 'bar': 9} func(**kw) -snip snip- That will raise a TypeError in 2.6 but works in 2.7. Is it appropriate and feasible to back port that to Python 2.6? I remember talking about this a while back but I don't remember what we decided and I can't find a bug on the issue. -Barry signature.asc Description: PGP signature ___ 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] The fate of the -U option
On Wed, Feb 3, 2010 at 9:09 AM, Barry Warsaw wrote: > On Feb 03, 2010, at 04:21 PM, M.-A. Lemburg wrote: > >>[email protected] wrote: >>> On 02:52 pm, [email protected] wrote: Note that in Python 2.7 you can use from __future__ import unicode_literals on a per module basis to achieve much the same effect. >>> >>> In Python 2.6 as well. >> >>Right, but there are a few issues in 2.6 that will be fixed >>in 2.7. > > The one that bites me most often is that in 2.6, keyword arguments must be > strs; unicodes are not accepted: > > -snip snip- > from __future__ import unicode_literals > > def func(foo, bar): > print foo, bar > > kw = {'foo': 7, 'bar': 9} > func(**kw) > -snip snip- > > That will raise a TypeError in 2.6 but works in 2.7. Is it appropriate and > feasible to back port that to Python 2.6? I remember talking about this a > while back but I don't remember what we decided and I can't find a bug on the > issue. I don't know about feasible but I think it's (borderline) appropriate. There are various other paths that lead to this error and it feels to me it's just a long-standing bug that we never took care of until 2.7. However, I don't think it needs to support non-ASCII characters in the keywords (even though 2.7 does seem to support those). -- --Guido van Rossum (python.org/~guido) ___ 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 3146: Merge Unladen Swallow into CPython
On Wed, Feb 3, 2010 at 6:51 AM, M.-A. Lemburg wrote: > You lost me there :-) > > I am not familiar with how U-S actually implements the compilation > step and was thinking of it working at the functions/methods level > and based on input/output parameter type information. Yes, but it's more like for every attribute lookup we ask "what was the type of the object we did the lookup on?" So, we simply take a reference to obj->ob_type and stuff it in our feedback record, which is limited to just three pointers. Then when we generate code, we may emit a guard that compares obj->ob_type in the compiled lookup to the pointer we recorded. We also need to place a weak reference to the code object on the type so that when the type is mutated or deleted, we invalidate the code, since its assumptions are invalid. > Most Python functions and methods have unique names (when > combined with the module and class name), so these could > be used for the referencing and feedback writing. Right, so when building the .so to load, you would probably want to take all the feedback data and find these dotted names for the pointers in the feedback data. If you find any pointers that can't be reliably identified, you could drop it from the feedback and flag that site as polymorphic (ie don't optimize this site). Then you generate machine code from the feedback and stuff it in a .so, with special relocation information. When you load the .so into a fresh Python process with a different address space layout, you try to recover the pointers to the PyObjects mentioned in the relocation information and patch up the machine code with the new pointers, which is very similar to the job of a linker. If you can't find the name or things don't look right, you just drop that piece of native code. > The only cases where this doesn't work too well is dynamic > programming of the sort done in namedtuples: where you > dynamically create a class and then instantiate it. It might actually work if the namedtuple is instantiated at module scope before loading the .so. > Type information for basic types and their subclasses can > be had dynamically (there's also a basic type bitmap for > faster lookup) or in a less robust way by name. If I understand you correctly, you're thinking about looking the types up by name or bitmap in the machine code. I think it would be best to just do the lookup once at load time and patch the native code. >> It sounds like a huge amount of work, and we haven't approached it. >> On the other hand, it sounds like it might be rewarding. > > Indeed. Perhaps this could be further investigated in a SoC > project ?! Or maybe a thesis. I'm really walking out on a limb, and this idea is quite hypothetical. :) Reid ___ 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 391 - Please Vote!
On Thu, Jan 14, 2010 at 6:56 AM, Jesse Noller wrote: > On Thu, Jan 14, 2010 at 9:08 AM, Vinay Sajip wrote: >>> From: Jesse Noller >> >>> I'm generally +1 - but given I know that Django 1.2 is slated to >>> implement something somewhat similar, I'm interested to hear how this >>> proposal meshes with their plan(s).. >> >> Django 1.2 will most likely not implement logging - they're now in feature >> freeze for big features. See Russ Magee's post: >> >> http://groups.google.com/group/django-developers/msg/4ef81a2160257221 >> >> They're waiting for a Python decision and (from Russ Magee's post) seem to >> be in favour of the changes proposed in PEP 391. If we get these changes >> into Python soon, then Django 1.3 may be able to make use of them in its >> logging (which encompasses not just configuring Django logging in a >> settings.py, but also using logging internally throughout Django where it >> makes sense to do so). >> >> Assuming PEP 391 gets the nod, then after implementing the changes into >> Python, I plan to work with the Django community to get improved logging >> support in Django for 1.3. >> >> Regards, >> >> Vinay Sajip >> > > Cool, +1 then :) Having read the PEP I heartily approve. The PEP can be moved to Accepted state. This can be implemented in Python 2.7 and 3.2, right? -- --Guido van Rossum (python.org/~guido) ___ 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] Rational for PEP 3147 (PYC Respository Directories)
On 2/3/2010 12:35 PM, Neil Schemenauer wrote: Hi Barry, Thanks for doing the work of writing a PEP. The rational section could use some strengthing, I think. Who is benefiting from this feature? The original proposal of changing .pyc to a directory would be negative to me so I would not use the option. I am pretty sure that I would consider the alternate proposal of one cache subdirectory per source directory to be a plus for me. Giving that I only put .py files in a directory, the directory listing (skipping subdirs which Windows sorts at the top) would then be a listing of my .py files without the noise of duplicates. Finding files in /Lib for source viewing would also be much easier. No noise, and twice as much real info on the screen at once. I am assuming that having two directories open, each have as large, would have negligable time and space impact. Terry Jan Reedy ___ 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] python -U
>> As an aside, I think this should be documented *somewhere* other than >> just in import.c! I'd totally forgotten about it until I read the >> source and almost missed it. Either it should be documented or it >> should be ripped out. > > The -U option is already gone in 3.x. Precisely my view. 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] The fate of the -U option
>> That will raise a TypeError in 2.6 but works in 2.7. Is it appropriate and
>> feasible to back port that to Python 2.6? I remember talking about this a
>> while back but I don't remember what we decided and I can't find a bug on the
>> issue.
>
> I don't know about feasible but I think it's (borderline) appropriate.
I fail to see the point there as well. There will be about two more 2.6
releases until we stop fixing bugs in it, and start recommending 2.7.
So who would be helped if such a feature would be added to 2.6?
> There are various other paths that lead to this error and it feels to
> me it's just a long-standing bug that we never took care of until 2.7.
> However, I don't think it needs to support non-ASCII characters in the
> keywords (even though 2.7 does seem to support those).
Is it really necessary to ban them? In the regular keyword argument
syntax (arg=value), the lexer will reject them. If you pass them through
a dictionary, why go through the dictionary and ban those that you don't
like? If the callee also uses the **kw syntax, they may actually be able
to receive them.
Notice that this works also in 2.5:
py> def foo(**kw):pass
...
py> foo(**{'':None})
py> foo(**{'\0':None})
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 391 - Please Vote!
On Thu, Jan 14, 2010 at 4:23 AM, Vinay Sajip wrote: > In October 2009 I created PEP 391 to propose a new method of configuring > logging using dictionaries: > > http://www.python.org/dev/peps/pep-0391/ > > In November 2009 I posted to this list that the PEP was ready for review. > > I have had numerous helpful comments from some of you, and I have > incorporated most of them into updates to the PEP. Though I have the feeling > from community discussions that the PEP has been generally favourably > received - well I would think that, wouldn't I? ;-) - I've not asked for a > vote and so I don't know the state of community consensus regarding this PEP. > > So, can you please indicate your vote for or against incorporating PEP 391 > into Python? It would be nice if I could incorporate the changes before 2.7a3 > is released! Ideally, I would like to check in the changes unless there are > objections to doing so. All those who think that logging is currently hard to > configure will benefit from these changes, so here's the opportunity to pipe > up and improve things. > Probably the only thing that I found a little bit weird is the use of `()` for custom instances (no big deal ;o). In general I think it's great !!! -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: TracGViz plugin downloaded more than 1000 times (> 300 from PyPI) - http://feedproxy.google.com/~r/simelo-en/~3/06Exn-JPLIA/tracgviz-plugin-downloaded-more-than.html ___ 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] Python 2.6.5
> This patch is still waiting a review and backporting from trunk. > > http://mail.python.org/pipermail/python-dev/2009-October/092771.html > > Can we get it in? Only if one of the Mac people checks it in. As they are *REALLY* scarce, the answer is probably "no". I'd offer a special version of the five-for-one deal: review five Mac issues, and I review this one, despite not being one of the core Mac people. 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 391 Acceptance - Thanks!
- Original Message > From: Guido van Rossum > To: Jesse Noller > Cc: Vinay Sajip ; [email protected] > >> Assuming PEP 391 gets the nod, then after implementing the changes into > Python, I plan to work with the Django community to get improved logging > support > in Django for 1.3. > > Having read the PEP I heartily approve. The PEP can be moved to > Accepted state. This can be implemented in Python 2.7 and 3.2, right? > --Guido van Rossum (python.org/~guido) Guido, That's great - thanks very much! I'll get on with integrating the PEP 391 implementation into trunk right away, and it should be in good time for 2.7/3.2. Regards, Vinay ___ 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] Python 2.6.5
On Feb 3, 2010, at 3:07 PM, Martin v. Löwis wrote: >> This patch is still waiting a review and backporting from trunk. >> >> http://mail.python.org/pipermail/python-dev/2009-October/092771.html >> >> Can we get it in? > > Only if one of the Mac people checks it in. It's already checked in the trunk by Ronald. He marked it "needs review" for 2.6. So, he obviously expects someone else to review it, otherwise he could have checked it into 2.6 branch as he did in trunk and 3.x. > As they are *REALLY* scarce, the answer is probably "no". Barry's answer was "yes" back in October. Read the rest of the thread, please. I just wanted to send a reminder about that. ___ 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] __file__
On Wed, Feb 3, 2010 at 05:07, Antoine Pitrou wrote: > Barry Warsaw python.org> writes: >> >> Python 3 uses the .py file for __file__ but I'd like to see a transition to >> __source__ for that, with __cache__ for the location of the PVM, JVM, LLVM or >> whatever compilation cache artifact file. > > Well, I don't think we need another transition... Just keep __file__ for the > source file, and add a __cache__ or __compiled__ attribute for the compiled > file(s). So what happens when only bytecode is present? As of right now __file__ is set to the path of the bytecode if no source exists (needed for reloading along with backwards-compatibility). Would you set __file__ = __compiled__? Or would __file__ be set to None? I am going to assume the former for backwards-compatibility, but I figured I would bring up the issue as it means getting only the source path would become ``__file__ if __file__ != __compiled__ else None``. > > Since there might be several compiled files for a single source file (for > example, a .pyc along with a JITted native .so), __cache__ should probably be > a > tuple rather than a string. Maybe, but only one of them will be used. Having to check for all of the possible compiled versions of a module is just a waste of time; you should only care about what import used to load the module. -Brett ___ 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] Absolute imports in Python 2.x?
On Wed, Feb 3, 2010 at 05:57, Nick Coghlan wrote: > Mark Dickinson wrote: >> Agreed on all points. Would it be terrible to simply add all relevant >> tags the moment a PEP is accepted? E.g., if a PEP pronounces some >> particular behaviour deprecated in Python 3.3 and removed in Python >> 3.4, then corresponding release blockers for 3.3 and 3.4 could be >> opened as part of implementing the PEP. > > That strikes me as a really good idea, since the tracker already serves > as a global "to do" list for the project (heck, I've used it as a > semi-private to do list at times, when I've thought of things I need to > fix when I don't have the roundtuits free to actually fix them). > And with all the proper dependency linkage it will make it obvious when the PEP is fully implemented. +1 from me. -Brett ___ 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 3147: PYC Repository Directories
Barry Warsaw wrote: > On Feb 03, 2010, at 11:31 PM, Nick Coghlan wrote: > >> Having a lookup dictionary from Python version + C API magic numbers to >> the magic strings used in cache filenames in the import engine shouldn't >> be too tricky. I'll admit it wasn't until the thread had already been >> going for a while that I realised that, though :) > > I agree, and it's clear that would be much more user friendly. I've added a > note to my working copy of the PEP and leave that as a possible design > change. I'm still not certain what the right mapping would be though. Python > version numbers don't seem quite right, but maybe they are a "good enough" > solution. If we ditch the -U option for 2.7, then we'll only have one magic number per CPython version. I've been using "cpython-27" in my examples. On the issue of __file__, I'd suggesting not being too hasty in deprecating that in favour of __source__. While I can see a lot of value in having it point to the source file more often with a different attribute that points to the cached file, I don't see a lot of gain to compensate for the pain of changing the name of __file__ itself. 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
Re: [Python-Dev] PEP 3147: PYC Repository Directories
On Wed, Feb 3, 2010 at 05:27, Nick Coghlan wrote: > Glenn Linderman wrote: >> On approximately 2/2/2010 7:05 PM, came the following characters from >> the keyboard of Guido van Rossum: >>> On Tue, Feb 2, 2010 at 5:41 PM, Glenn >>> Linderman wrote: Agreed. But in reading that, it somehow triggered a question: does zipimport only work for zipfiles, or does it work for any archive format that Python stdlib knows how to decode? And if only the former, why are they so special? >>> The former. >>> >>> They are special because (unlike e.g. tar files) you can read the >>> table of contents of a zipfile without parsing the entire file. >> >> They are not unique in this... most archive formats except tar have a >> directory. But that is likely a good reason not to support tar for >> this purpose, especially since tar usually comes found as .tar.Z or >> .tar.gz or .tar.bz2 etc. and would require two passes before the data >> could be found at all. > > It's also because nobody has done the work to hook up any additional > archive formats (as zipimport needs to work for importing the standard > library itself, it isn't quite as simple as just importing an extra > module to do the manipulation. Extending the test suite to cover a new > archive format would require some work as well). > > Given that zip files already work and are almost universal, I figure > folks have just opted to use that and then found other things to do with > their coding time :) > If people really need alternative archive formats they can use the importers package: http://packages.python.org/importers/ . If someone really wants to use another format they can use the ABCs in the package to easily write their own importer. It also contains a sqlite3 importer and its own zip importer. -Brett > 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/brett%40python.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] PEP 3147: PYC Repository Directories
Nick Coghlan writes: > P.S. Translation of the double negative: I don't find any of the > solutions, even the current .pyc/.pyo approach, to be particularly > elegant, so I can't really say I like any of them in an absolute > sense. However, having a single cache folder inside each Python source > folder seems to strike the best balance between keeping a tidy > filesystem and still being able to locate a cached file given only the > location of the source file (or vice-versa) without using any > Python-specific tools, so it is the approach I personally prefer. Something I think is being lost here: AFAICT, the impetus behind this PEP is to allow OS distributions to decouple the location of the compiled bytecode files from the location of the source code files. (If I'm mistaken, then clearly I don't understand the PEP's purpose at all and I'd love to have this misconception corrected.) If that's so, then I don't see how what you suggest above is any significat progress toward that goal. It still tightly couples the locations of the source code files and the complied bytecode files. Having a distinct cache of compiled bytecode files addresses this better. -- \ “I find the whole business of religion profoundly interesting. | `\ But it does mystify me that otherwise intelligent people take | _o__)it seriously.” —Douglas Adams | Ben Finney ___ 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 3147: PYC Repository Directories
On Wed, Feb 3, 2010 at 12:47 PM, Nick Coghlan wrote: > On the issue of __file__, I'd suggesting not being too hasty in > deprecating that in favour of __source__. While I can see a lot of value > in having it point to the source file more often with a different > attribute that points to the cached file, I don't see a lot of gain to > compensate for the pain of changing the name of __file__ itself. Can you clarify? In Python 3, __file__ always points to the source. Clearly that is the way of the future. For 99.99% of uses of __file__, if it suddenly never pointed to a .pyc file any more (even if one existed) that would be just fine. So what's this talk of switching to __source__? -- --Guido van Rossum (python.org/~guido) ___ 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] The fate of the -U option
On Wed, Feb 3, 2010 at 12:00 PM, "Martin v. Löwis" wrote:
>>> That will raise a TypeError in 2.6 but works in 2.7. Is it appropriate and
>>> feasible to back port that to Python 2.6? I remember talking about this a
>>> while back but I don't remember what we decided and I can't find a bug on
>>> the
>>> issue.
>>
>> I don't know about feasible but I think it's (borderline) appropriate.
>
> I fail to see the point there as well. There will be about two more 2.6
> releases until we stop fixing bugs in it, and start recommending 2.7.
>
> So who would be helped if such a feature would be added to 2.6?
Presumably the people who asked for it want it. Regardless of what you
(or I) recommend, 2.6 will be in use for a long time.
>> There are various other paths that lead to this error and it feels to
>> me it's just a long-standing bug that we never took care of until 2.7.
>> However, I don't think it needs to support non-ASCII characters in the
>> keywords (even though 2.7 does seem to support those).
>
> Is it really necessary to ban them?
No, that's not what I meant -- I just meant that it wasn't necessary
to support non-ASCII if it would in any way complicate the patch.
> In the regular keyword argument
> syntax (arg=value), the lexer will reject them. If you pass them through
> a dictionary, why go through the dictionary and ban those that you don't
> like? If the callee also uses the **kw syntax, they may actually be able
> to receive them.
>
> Notice that this works also in 2.5:
>
> py> def foo(**kw):pass
> ...
> py> foo(**{'':None})
> py> foo(**{'\0':None})
OTOH a more conservative solution would convert the keywords to str
instances so that the receiving end (the body of foo) would never see
Unicode objects even while allowing (some) Unicode objects on the
sending end (foo's caller).
--
--Guido van Rossum (python.org/~guido)
___
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] __file__
> On Wed, Feb 3, 2010 at 05:07, Antoine Pitrou wrote: >> Barry Warsaw python.org> writes: >>> Python 3 uses the .py file for __file__ but I'd like to see a transition to >>> __source__ for that, with __cache__ for the location of the PVM, JVM, LLVM >>> or >>> whatever compilation cache artifact file. >> Well, I don't think we need another transition... Just keep __file__ for the >> source file, and add a __cache__ or __compiled__ attribute for the compiled >> file(s). > > So what happens when only bytecode is present? As of right now > __file__ is set to the path of the bytecode if no source exists > (needed for reloading along with backwards-compatibility). Would you > set __file__ = __compiled__? This is what I would propose. There are also shared libraries, so __file__ should really point to the file that is being executed. In the case of a source file, claiming that this is the one that gets executed is fairly accurate even if we had actually loaded the byte code from the cache. The only case when this may be wrong is when somebody sets the timestamp of the source file backwards, or the timestamp of the byte code file forwards. For this case, a second attribute could help (and I would set *that* to None if we only wrote the pyc file, but didn't read it - a library functions would be able to tell where the pyc file should have been written to). > Maybe, but only one of them will be used. Having to check for all of > the possible compiled versions of a module is just a waste of time; > you should only care about what import used to load the module. I agree. 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 3147: PYC Repository Directories
Guido van Rossum wrote: > On Wed, Feb 3, 2010 at 12:47 PM, Nick Coghlan wrote: >> On the issue of __file__, I'd suggesting not being too hasty in >> deprecating that in favour of __source__. While I can see a lot of value >> in having it point to the source file more often with a different >> attribute that points to the cached file, I don't see a lot of gain to >> compensate for the pain of changing the name of __file__ itself. > > Can you clarify? In Python 3, __file__ always points to the source. > Clearly that is the way of the future. For 99.99% of uses of __file__, > if it suddenly never pointed to a .pyc file any more (even if one > existed) that would be just fine. So what's this talk of switching to > __source__? I originally proposed it, not knowing that Python 3 already changed the meaning of __file__ for byte code files. What I really wanted to suggest is that it should be possible to tell what gets really executed, plus what source file had been considered. So if __file__ is always the source file, a second attribute should tell whether a byte code file got read (so that you can delete that in case you doubt it's current, for example). 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 3147: PYC Repository Directories
Guido van Rossum wrote: > On Wed, Feb 3, 2010 at 12:47 PM, Nick Coghlan wrote: >> On the issue of __file__, I'd suggesting not being too hasty in >> deprecating that in favour of __source__. While I can see a lot of value >> in having it point to the source file more often with a different >> attribute that points to the cached file, I don't see a lot of gain to >> compensate for the pain of changing the name of __file__ itself. > > Can you clarify? In Python 3, __file__ always points to the source. > Clearly that is the way of the future. For 99.99% of uses of __file__, > if it suddenly never pointed to a .pyc file any more (even if one > existed) that would be just fine. So what's this talk of switching to > __source__? > In Barry's rough notes that he added to the PEP he said he thought __file__ had become too ambiguous and was going to suggest changing the name to __source__. That struck me as an overreaction to a very mild ambiguity (one that will only lessen with time if a new attribute is added to point to the cached file that was actually executed). 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
Re: [Python-Dev] __file__
On Wed, Feb 3, 2010 at 13:30, "Martin v. Löwis" wrote: >> On Wed, Feb 3, 2010 at 05:07, Antoine Pitrou wrote: >>> Barry Warsaw python.org> writes: Python 3 uses the .py file for __file__ but I'd like to see a transition to __source__ for that, with __cache__ for the location of the PVM, JVM, LLVM or whatever compilation cache artifact file. >>> Well, I don't think we need another transition... Just keep __file__ for the >>> source file, and add a __cache__ or __compiled__ attribute for the compiled >>> file(s). >> >> So what happens when only bytecode is present? As of right now >> __file__ is set to the path of the bytecode if no source exists >> (needed for reloading along with backwards-compatibility). Would you >> set __file__ = __compiled__? > > This is what I would propose. There are also shared libraries, so > __file__ should really point to the file that is being executed. In the > case of a source file, claiming that this is the one that gets executed > is fairly accurate even if we had actually loaded the byte code from the > cache. I like that explanation that __file__ contains what is semantically being run and using __compiled__ to simply represent what was actually loaded. > The only case when this may be wrong is when somebody sets the > timestamp of the source file backwards, or the timestamp of the byte > code file forwards. For this case, a second attribute could help (and I > would set *that* to None if we only wrote the pyc file, but didn't read > it - a library functions would be able to tell where the pyc file should > have been written to). Well, if you are mucking with file timestamps while loading code you are just asking for trouble, so I don't think we need to worry about it. -Brett > >> Maybe, but only one of them will be used. Having to check for all of >> the possible compiled versions of a module is just a waste of time; >> you should only care about what import used to load the module. > > I agree. > > 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 3147: PYC Repository Directories
Ben Finney wrote: > Nick Coghlan writes: > >> P.S. Translation of the double negative: I don't find any of the >> solutions, even the current .pyc/.pyo approach, to be particularly >> elegant, so I can't really say I like any of them in an absolute >> sense. However, having a single cache folder inside each Python source >> folder seems to strike the best balance between keeping a tidy >> filesystem and still being able to locate a cached file given only the >> location of the source file (or vice-versa) without using any >> Python-specific tools, so it is the approach I personally prefer. > > Something I think is being lost here: AFAICT, the impetus behind this > PEP is to allow OS distributions to decouple the location of the > compiled bytecode files from the location of the source code files. (If > I'm mistaken, then clearly I don't understand the PEP's purpose at all > and I'd love to have this misconception corrected.) No, the purpose is to allow the same source file to be shared between multiple versions of the Python interpreter without their compiled files conflicting as they do now. It's the support for multiple .pyc and .pyo files per .py file that is the significant change, not the specific location of those files. Being able to get rid of the existing .pyc/.pyo clutter at the same time is just a bonus. 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
Re: [Python-Dev] __file__
Brett Cannon wrote: > On Wed, Feb 3, 2010 at 05:07, Antoine Pitrou wrote: >> Barry Warsaw python.org> writes: >>> Python 3 uses the .py file for __file__ but I'd like to see a transition to >>> __source__ for that, with __cache__ for the location of the PVM, JVM, LLVM >>> or >>> whatever compilation cache artifact file. >> Well, I don't think we need another transition... Just keep __file__ for the >> source file, and add a __cache__ or __compiled__ attribute for the compiled >> file(s). > > So what happens when only bytecode is present? As of right now > __file__ is set to the path of the bytecode if no source exists > (needed for reloading along with backwards-compatibility). Would you > set __file__ = __compiled__? Or would __file__ be set to None? I am > going to assume the former for backwards-compatibility, but I figured > I would bring up the issue as it means getting only the source path > would become ``__file__ if __file__ != __compiled__ else None``. My suggestion was that __file__ be set to the expected location of the source file regardless of whether or not the source file actually exists. Given the new location of the compiled files under PEP 3147 there is no 100% backwards compatible option for __file__ in this case, since they will be at a different depth in the directory hierarchy. Reload can easily enough be updated to fall back to __compiled__ if __file__ is missing, which is a much easier fix than trying to update any third party manipulations of __file__ that expect it to be pointing to a file in the same directory as the source file. 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
Re: [Python-Dev] __file__
Le Wed, 03 Feb 2010 15:55:54 +0200, Simon Cross a écrit : > On Wed, Feb 3, 2010 at 3:07 PM, Antoine Pitrou > wrote: >> Since there might be several compiled files for a single source file >> (for example, a .pyc along with a JITted native .so), __cache__ should >> probably be a tuple rather than a string. > > But presumably there is only one compiled file that is in use by the > current Python instance? We could imagine an implementation which would load the .pyc file and then overload some (but only some) of the declarations there with some specialized native code from a .so file. This is just speculation however. Regards 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] __file__
On Wed, Feb 3, 2010 at 13:52, Nick Coghlan wrote: > Brett Cannon wrote: >> On Wed, Feb 3, 2010 at 05:07, Antoine Pitrou wrote: >>> Barry Warsaw python.org> writes: Python 3 uses the .py file for __file__ but I'd like to see a transition to __source__ for that, with __cache__ for the location of the PVM, JVM, LLVM or whatever compilation cache artifact file. >>> Well, I don't think we need another transition... Just keep __file__ for the >>> source file, and add a __cache__ or __compiled__ attribute for the compiled >>> file(s). >> >> So what happens when only bytecode is present? As of right now >> __file__ is set to the path of the bytecode if no source exists >> (needed for reloading along with backwards-compatibility). Would you >> set __file__ = __compiled__? Or would __file__ be set to None? I am >> going to assume the former for backwards-compatibility, but I figured >> I would bring up the issue as it means getting only the source path >> would become ``__file__ if __file__ != __compiled__ else None``. > > My suggestion was that __file__ be set to the expected location of the > source file regardless of whether or not the source file actually > exists. Given the new location of the compiled files under PEP 3147 > there is no 100% backwards compatible option for __file__ in this case, > since they will be at a different depth in the directory hierarchy. > But what does "expected location" mean? If I am importing foo.bar where foo.__path__ has multiple path entries, which one is supposed to be used to set the hypothetical location of source for __file__? I guess going with the first one would be somewhat reasonable, but it's definitely a guess. -Brett > Reload can easily enough be updated to fall back to __compiled__ if > __file__ is missing, which is a much easier fix than trying to update > any third party manipulations of __file__ that expect it to be pointing > to a file in the same directory as the source file. ___ 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] __file__
On 03/02/2010 22:05, Brett Cannon wrote: On Wed, Feb 3, 2010 at 13:52, Nick Coghlan wrote: Brett Cannon wrote: On Wed, Feb 3, 2010 at 05:07, Antoine Pitrou wrote: Barry Warsaw python.org> writes: Python 3 uses the .py file for __file__ but I'd like to see a transition to __source__ for that, with __cache__ for the location of the PVM, JVM, LLVM or whatever compilation cache artifact file. Well, I don't think we need another transition... Just keep __file__ for the source file, and add a __cache__ or __compiled__ attribute for the compiled file(s). So what happens when only bytecode is present? As of right now __file__ is set to the path of the bytecode if no source exists (needed for reloading along with backwards-compatibility). Would you set __file__ = __compiled__? Or would __file__ be set to None? I am going to assume the former for backwards-compatibility, but I figured I would bring up the issue as it means getting only the source path would become ``__file__ if __file__ != __compiled__ else None``. My suggestion was that __file__ be set to the expected location of the source file regardless of whether or not the source file actually exists. Given the new location of the compiled files under PEP 3147 there is no 100% backwards compatible option for __file__ in this case, since they will be at a different depth in the directory hierarchy. But what does "expected location" mean? If I am importing foo.bar where foo.__path__ has multiple path entries, which one is supposed to be used to set the hypothetical location of source for __file__? I guess going with the first one would be somewhat reasonable, but it's definitely a guess. Isn't __file__ usually baked into .pyc files at compile time? (At least I assumed that from the incorrect tracebacks on Windows when you ship just .pyc files.) Michael -Brett Reload can easily enough be updated to fall back to __compiled__ if __file__ is missing, which is a much easier fix than trying to update any third party manipulations of __file__ that expect it to be pointing to a file in the same directory as the source file. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] __file__
On Wed, Feb 3, 2010 at 14:40, Michael Foord wrote: > On 03/02/2010 22:05, Brett Cannon wrote: >> >> On Wed, Feb 3, 2010 at 13:52, Nick Coghlan wrote: >> >>> >>> Brett Cannon wrote: >>> On Wed, Feb 3, 2010 at 05:07, Antoine Pitrou wrote: > > Barry Warsaw python.org> writes: > >> >> Python 3 uses the .py file for __file__ but I'd like to see a >> transition to >> __source__ for that, with __cache__ for the location of the PVM, JVM, >> LLVM or >> whatever compilation cache artifact file. >> > > Well, I don't think we need another transition... Just keep __file__ > for the > source file, and add a __cache__ or __compiled__ attribute for the > compiled > file(s). > So what happens when only bytecode is present? As of right now __file__ is set to the path of the bytecode if no source exists (needed for reloading along with backwards-compatibility). Would you set __file__ = __compiled__? Or would __file__ be set to None? I am going to assume the former for backwards-compatibility, but I figured I would bring up the issue as it means getting only the source path would become ``__file__ if __file__ != __compiled__ else None``. >>> >>> My suggestion was that __file__ be set to the expected location of the >>> source file regardless of whether or not the source file actually >>> exists. Given the new location of the compiled files under PEP 3147 >>> there is no 100% backwards compatible option for __file__ in this case, >>> since they will be at a different depth in the directory hierarchy. >>> >>> >> >> But what does "expected location" mean? If I am importing foo.bar >> where foo.__path__ has multiple path entries, which one is supposed to >> be used to set the hypothetical location of source for __file__? I >> guess going with the first one would be somewhat reasonable, but it's >> definitely a guess. >> > > Isn't __file__ usually baked into .pyc files at compile time? (At least I > assumed that from the incorrect tracebacks on Windows when you ship just > .pyc files.) Yes, but import.c back-patches before loading to get around this. This will eventually get fixed, though: see http://bugs.python.org/issue6811 . -Brett > > Michael > > >> -Brett >> >> >> >>> >>> Reload can easily enough be updated to fall back to __compiled__ if >>> __file__ is missing, which is a much easier fix than trying to update >>> any third party manipulations of __file__ that expect it to be pointing >>> to a file in the same directory as the source file. >>> > >> ___ >> Python-Dev mailing list >> [email protected] >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk >> > > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > READ CAREFULLY. By accepting and reading this email you agree, on behalf of > your employer, to release me from all obligations and waivers arising from > any and all NON-NEGOTIATED agreements, licenses, terms-of-service, > shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, > non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have > entered into with your employer, its partners, licensors, agents and > assigns, in perpetuity, without prejudice to my ongoing rights and > privileges. You further represent that you have the authority to release me > from any BOGUS AGREEMENTS on behalf of your employer. > > > ___ 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] __file__
At 10:40 PM 2/3/2010 +, Michael Foord wrote: Isn't __file__ usually baked into .pyc files at compile time? (At least I assumed that from the incorrect tracebacks on Windows when you ship just .pyc files.) That's code.co_filename, which is not necessarily the same as __file__. ___ 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] __file__
> On Wed, Feb 3, 2010 at 14:40, Michael Foord > wrote: >> Isn't __file__ usually baked into .pyc files at compile time? (At least I >> assumed that from the incorrect tracebacks on Windows when you ship just >> .pyc files.) On Wed, Feb 3, 2010 at 2:48 PM, Brett Cannon wrote: > Yes, but import.c back-patches before loading to get around this. This will > eventually get fixed, though: see http://bugs.python.org/issue6811 . Actually not quite. __file__ never comes from the .pyc file, it always gets set by the import process. What comes from the .pyc file (and what that bug is asking to fix fix) is the co_filename attribute of the marshalled code objects. (BTW I have my own reasons for wanting the latter to be fixed.) -- --Guido van Rossum (python.org/~guido) ___ 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] Python 2.6.5
On 3 Feb, 2010, at 21:27, Zvezdan Petkovic wrote: > On Feb 3, 2010, at 3:07 PM, Martin v. Löwis wrote: > >>> This patch is still waiting a review and backporting from trunk. >>> >>> http://mail.python.org/pipermail/python-dev/2009-October/092771.html >>> >>> Can we get it in? >> >> Only if one of the Mac people checks it in. > > It's already checked in the trunk by Ronald. > He marked it "needs review" for 2.6. > So, he obviously expects someone else to review it, otherwise he could have > checked it into 2.6 branch as he did in trunk and 3.x. I closed the issue as fixed because I had no intention of backporting it as this is a new feature (using libedit didn't work in earlier 2.6 versions and only works on the trunk after patching the readline module). > >> As they are *REALLY* scarce, the answer is probably "no". > > Barry's answer was "yes" back in October. I will backport the patch if Barry says it's fine. Feel free to ping me if that doesn't happen before the end of next week. Ronald smime.p7s Description: S/MIME cryptographic signature ___ 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 3147: PYC Repository Directories
Thanks for the explanation. Nick Coghlan writes: > Being able to get rid of the existing .pyc/.pyo clutter at the same > time is just a bonus. Okay. I maintain (unsurprisingly) that replacing it with subdirectory clutter is a poor bargain. But I have nothing new to add on that score for now. -- \ “A man may be a fool and not know it — but not if he is | `\ married.” —Henry L. Mencken | _o__) | Ben Finney ___ 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] Forking and Multithreading - enemy brothers
Jesse Noller gmail.com> writes: > We already have an implementation that spawns a > subprocess and then pushes the required state to the child. The > fundamental need for things to be pickleable *all the time* kinda > makes it annoying to work with. > just a lurker here... but this topic hits home with me so thought I'd chime in. I'm a windows user and I would *love* to use multiprocessing a lot more because *in theory* it solves a lot of the problems I deal with very nicely (lot sof financial data number crunching). However, the pickling requirement makes it very very difficult to actually get any reasonably complex code to work properly with it. A lot of the time the functions I want to call in the spawned processes are actually fairly self contained and don't need most of the environment of the parent process shoved into it, so it's annoying that it fails because some data I don't even need in the child process can't be pickled. What about having an option to skip all the parent environment data pickling and require the user to manually invoke any imports that are needed in the target functions as the first step inside their target function? for example... def target_function(object_from_module_xyz): import xyz return object_from_module_xyz.do_something() and if I forgot to import all the stuff necessary for the arguments being passed into my function to work, then it's my own problem. Although maybe there is some obvious problem with this that I am not seeing. Anyway, just food for thought. - Matt ___ 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
