Re: [Python-Dev] Does Zip Importer have to be Special?
On 24/07/2014 9:42 pm, Nick Coghlan wrote: On 25 Jul 2014 03:51, "Brett Cannon" wrote: The problem with all of this is you are essentially asking for a hook to let you have code have access to the interpreter state before it is fully initialized. Zipimport and the various bits of code that get loaded during startup are special since they are coded to avoid touching anything that isn't ready to be used. So if we expose something that allows access prior to full initialization it would have to be documented as having no guarantees of interpreter state, etc. so we are not held to some API that makes future improvements difficult. Note that this is *exactly* the problem PEP 432 is designed to handle: separating the configuration of the core interpreter from the configuration of the operating system interfaces, so the latter can run relatively normally (at least compared to today). The implementation of PEP 432 would be great. As you say, though it's a niche problem compared to something like packaging, which is why it got bumped down my personal priority list. I haven't even got back to the first preparatory step I identified which is to separate out our main functions to a separate "Programs" directory so it's easier to distinguish "embeds Python" sections of the code from the more typical "is part of Python" and "extends Python" code. Is there any way for somebody you don't trust :) to be able to help move it forward? Phil ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Does Zip Importer have to be Special?
On 24/07/2014 7:26 pm, Brett Cannon wrote: On Thu Jul 24 2014 at 2:12:20 PM, Phil Thompson wrote: On 24/07/2014 6:48 pm, Brett Cannon wrote: > IOW allowing for easy patching of Python is probably the best option I > can > think of. Would tweaking importlib._bootstrap._install() to accept > specified values for sys.meta_path and sys.path_hooks be enough so that > you > can change the call site for those functions? My importer runs under PathFinder so it needs sys.path as well (and doesn't need sys.meta_path). sys.path can be set via PYTHONPATH, etc. so that shouldn't be as much of an issue. I prefer to have Py_IgnoreEnvironmentFlag set. Also I'm not clear at what point I would import my custom importer? Phil ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Does Zip Importer have to be Special?
On 25 July 2014 19:33, Phil Thompson wrote: > On 24/07/2014 9:42 pm, Nick Coghlan wrote: >> As you say, though it's a niche problem compared to something like >> packaging, which is why it got bumped down my personal priority list. I >> haven't even got back to the first preparatory step I identified which is >> to separate out our main functions to a separate "Programs" directory so >> it's easier to distinguish "embeds Python" sections of the code from the >> more typical "is part of Python" and "extends Python" code. > > > Is there any way for somebody you don't trust :) to be able to help move it > forward? This thread prompted me to finally commit one of the smaller pieces of preparatory refactoring, moving the 3 applications we have that embed the CPython runtime out to a separate directory: http://bugs.python.org/issue18093 (that seems like a trivial change, but I found it made a surprisingly big difference when trying to keep the various moving parts of the initialisation sequence straight in my head) The other preparatory refactoring would be to split the monster pythonrun.c file in 2, by creating a separate "lifecycle.c" file. In my original PEP 432 branch I split it into 3 (pythonrun.c, bootstrap.c, shutdown.c) but that's actually quite an intrusive change - you end up have to expose a lot of otherwise static variables to the linker so the startup and shutdown code can both see them. Splitting in two should achieve most of the same benefits (i.e. separating the lifecycle management of the interpreter itself from the normal runtime operation code) without having to expose so much additional information to the linker (and hence change the names to include the _Py prefix). The origin of those refactorings is the fact that attempting to merge the default branch into my PEP 432 development branch (https://bitbucket.org/ncoghlan/cpython_sandbox/branch/pep432_modular_bootstrap) was generally a pain due to the merge conflicts around the structural changes. Doing the structural refactorings *first* makes it more feasible to work on the patch and do regular merges in from default. Since these are areas that aren't likely to change in a maintenance release, the risk of merge conflicts when merging forward from 3.4 to default is low even with code moved around on default. By contrast, I regularly hit significant problems when trying to merge from default to the feature branch. The existing feature branch is dated enough now (more than 18 months since the last commit!) that I wouldn't try to use it directly. Instead, I'd recommend starting a new clone based on the GitHub or BitBucket mirror (according to version control system and hosting service preference), and then use the current PEP draft and my old feature branch as a point of reference for starting another implementation attempt. (You may also be able to find some interested collaborators on http://bugs.python.org/issue13533, as I suspect PEP 432 is a prerequisite to resolving their issues as well) Cheers, Nick. P.S. I'm also starting to think that PEP 432 may pave the way for a locale independent startup sequence, which would let us offer a "-X utf8" option to tell the interpreter to ignore the OS locale settings entirely when deciding which encodings to use for various things. That would be a possible future enhancement rather than something to pursue in the initial implementation, though. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2014-07-18 - 2014-07-25)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open4591 ( +2)
closed 29248 (+60)
total 33839 (+62)
Open issues with patches: 2160
Issues opened (42)
==
#19884: Importing readline produces erroneous output
http://bugs.python.org/issue19884 reopened by haypo
#22010: Idle: better management of Shell window output
http://bugs.python.org/issue22010 opened by terry.reedy
#22011: test_os extended attribute setxattr tests can fail with ENOSPC
http://bugs.python.org/issue22011 opened by Hibou57
#22012: struct.unpack('?', '\x02') returns (False,) on Mac OSX
http://bugs.python.org/issue22012 opened by wayedt
#22013: Add at least minimal support for thread groups
http://bugs.python.org/issue22013 opened by rhettinger
#22014: Add summary table for OS exception <-> errno mapping
http://bugs.python.org/issue22014 opened by ncoghlan
#22016: Add a new 'surrogatereplace' output only error handler
http://bugs.python.org/issue22016 opened by ncoghlan
#22018: Add a new signal.set_wakeup_socket() function
http://bugs.python.org/issue22018 opened by haypo
#22021: shutil.make_archive() root_dir do not work
http://bugs.python.org/issue22021 opened by DemoHT
#22023: PyUnicode_FromFormat is broken on python 2
http://bugs.python.org/issue22023 opened by alex
#22024: Add to shutil the ability to wait until files are definitely d
http://bugs.python.org/issue22024 opened by zach.ware
#22025: webbrowser.get(command_line) does not support Windows-style pa
http://bugs.python.org/issue22025 opened by dan.oreilly
#22027: RFC 6531 (SMTPUTF8) support in smtplib
http://bugs.python.org/issue22027 opened by zvyn
#22028: Python 3.4.1 Installer ended prematurely (Windows msi)
http://bugs.python.org/issue22028 opened by DieInSente
#22029: argparse - CSS white-space: like control for individual text b
http://bugs.python.org/issue22029 opened by paul.j3
#22033: Subclass friendly reprs
http://bugs.python.org/issue22033 opened by serhiy.storchaka
#22034: posixpath.join() and bytearray
http://bugs.python.org/issue22034 opened by serhiy.storchaka
#22035: Fatal error in dbm.gdbm
http://bugs.python.org/issue22035 opened by serhiy.storchaka
#22038: Implement atomic operations on non-x86 platforms
http://bugs.python.org/issue22038 opened by Vitor.de.Lima
#22039: PyObject_SetAttr doesn't mention value = NULL
http://bugs.python.org/issue22039 opened by pitrou
#22041: http POST request with python 3.3 through web proxy
http://bugs.python.org/issue22041 opened by AlexMJ
#22042: signal.set_wakeup_fd(fd): set the fd to non-blocking mode
http://bugs.python.org/issue22042 opened by haypo
#22043: Use a monotonic clock to compute timeouts
http://bugs.python.org/issue22043 opened by haypo
#22044: Premature Py_DECREF while generating a TypeError in call_tzinf
http://bugs.python.org/issue22044 opened by Knio
#22045: Python make issue
http://bugs.python.org/issue22045 opened by skerr
#22046: ZipFile.read() should mention that it might throw NotImplement
http://bugs.python.org/issue22046 opened by detly
#22047: argparse improperly prints mutually exclusive options when the
http://bugs.python.org/issue22047 opened by Sam.Kerr
#22049: argparse: type= doesn't honor nargs > 1
http://bugs.python.org/issue22049 opened by Chris.Bruner
#22051: Turtledemo: stop reloading demos
http://bugs.python.org/issue22051 opened by terry.reedy
#22052: Comparison operators called in reverse order for subclasses wi
http://bugs.python.org/issue22052 opened by mark.dickinson
#22054: Add os.get_blocking() and os.set_blocking() functions
http://bugs.python.org/issue22054 opened by haypo
#22057: The doc say all globals are copied on eval(), but only __built
http://bugs.python.org/issue22057 opened by amishne
#22058: datetime.datetime() should accept a datetime.date as init para
http://bugs.python.org/issue22058 opened by facundobatista
#22059: incorrect type conversion from str to bytes in asynchat module
http://bugs.python.org/issue22059 opened by hoxily
#22060: Clean up ctypes.test, use unittest test discovery
http://bugs.python.org/issue22060 opened by zach.ware
#22062: Fix pathlib.Path.(r)glob doc glitches.
http://bugs.python.org/issue22062 opened by terry.reedy
#22063: asyncio: sock_xxx() methods of event loops should make the soc
http://bugs.python.org/issue22063 opened by haypo
#22064: Misleading message from 2to3 when skipping optional fixers
http://bugs.python.org/issue22064 opened by ncoghlan
#22065: Update turtledemo menu creation
http://bugs.python.org/issue22065 opened by terry.reedy
#22066: subprocess.communicate() does not receive full output from the
http://bugs.python.org/issue22066 opened by juj
#22067: time_test fails after strptime()
http://bugs.python.org/issue22067 opened by serhiy.storchaka
#2206
