[issue17636] Modify IMPORT_FROM to fallback on sys.modules
Changes by Phil Connell pconn...@gmail.com: -- nosy: +pconnell ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1387483] sys.path
Charles-François Natali added the comment: I am not sure about what use cases could be broken by the above change, do you have examples? Normal use cases of symbolic links have to do with linking entire folders, not individual files, and that behaviour would not be broken by such a hypothetical change, I think. For example: /tmp/ foo/ foo.py libfoo.py foo.py - /tmp/foo/foo.py With foo.py containing import libfoo. Now, calling /tmp/foo.py works because sys.path[0] == dirname(realpath(/tmp/foo.py)) == dirname(/tmp/foo/foo.py) == /tmp/foo. If we change sys.path[0] to not dereference the symlink (that's how I understood your suggestion, maybe I got it wrong), it will now be /tmp, and importing libfoo will fail. That's AFAICT exacyly the problem reported by the OP on OS-X. -- title: sys.path[0] when executed thru a symbolic link - sys.path ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1387483 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1387483] sys.path[0] when executed thru a symbolic link
Charles-François Natali added the comment: I've no clue what happened to the issue title (I just replied to the email, and the title changed)... -- title: sys.path - sys.path[0] when executed thru a symbolic link ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1387483 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6419] Broken test_kqueue.py on OpenBSD
Charles-François Natali added the comment: test_kqueue now passes on NetBSD (can't tell for OpenBSD, all buildbots are offline). I'm closing this, feel free to repon in case of problem. -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6419 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17638] test_ssl failure
New submission from Charles-François Natali: test_ssl is failing on one the NetBSD buildbots: http://buildbot.python.org/all/builders/x86%20NetBSD%205.1.2%20%5BSB%5D%203.x/builds/1129/steps/test/logs/stdio == ERROR: test_options (test.test_ssl.ContextTests) -- Traceback (most recent call last): File /home/cpython/buildslave/3.x.snakebite-netbsd51-x86-1/build/Lib/test/test_ssl.py, line 87, in f return func(*args, **kwargs) File /home/cpython/buildslave/3.x.snakebite-netbsd51-x86-1/build/Lib/test/test_ssl.py, line 420, in test_options ctx.options = (ctx.options ~ssl.OP_NO_SSLv2) | ssl.OP_NO_TLSv1 ValueError: can't clear options before OpenSSL 0.9.8m Antoine, I think I saw commits from you some time ago to deal with this SSL version thing... -- components: Tests keywords: buildbot messages: 186066 nosy: neologix, pitrou priority: normal severity: normal status: open title: test_ssl failure type: behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17638 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17638] test_ssl failure
Antoine Pitrou added the comment: Well, that exception is raised when the OpenSSL version doesn't have the HAVE_SSL_CTX_CLEAR_OPTIONS macro, which appeared in 0.9.8m. But the OpenSSL version on that buildbot identifies itself as OpenSSL 0.9.9-dev 09 May 2008, which is logically posterior to 0.9.8m. I don't know how to handle this in a non-hackish way, except by just ignoring the issue :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17638 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1387483] sys.path[0] when executed thru a symbolic link
Kristján Valur Jónsson added the comment: Thanks for your example. That's AFAICT exacyly the problem reported by the OP on OS-X. You are right, I mis-read the original problem. IMHO, the example you quote is unexpected. The purpose of symbolic links is to create a virtual image of a structure. a structure like you describe: /scripts/ foo.py - /otherplace/foo.py contains only a foo.py in its apparent location (scripts). I would not expect the file to be able to import stuff from /otherplace unless that stuff were also present in /scripts In other words: symlinking individual files normally works like you are pulling that file in, not hopping into that file's real location. This behaviour is unexpected because I know of no other language tools that behave in this way: /code/ myfile.c - /sources/myfile.c mylib.h - /libs/mylib.h libmylib.so - /libs/libmylib.so an #include mylib.h in myfile.c would look for the file in /code and find it. a cc myfile.c -lmylib would find the libmylib.so in /code Since this is not the original problem described, I'll open up a separate defect report. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1387483 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17639] symlinking .py files creates unexpected sys.path[0]
New submission from Kristján Valur Jónsson: When .py files are assembled into a directory structure using direct symbolic links to the files, something odd happens to sys.path[0]. Consider this file structure: /pystuff/ foo.py - /scripts/foo.py bar.py - /libs/bar.py foo.py contains the line: import bar python /pystuff/foo.py will now fail, because when foo.py is run, sys.path[0] will contain /scripts, rather than the expected /pystuff. It would appear that the algorithm for finding sys.path[0] is: sys.path[0] = os.dirname(os.realpath(filename)). IMO, it should be: sys.path[0] = os.realpath(os.dirname(filename)). I say that this behaviour is unexpected, because symlinking to individual files normally has the semantics of pulling that file in rather than hopping to that file's real dir. As an example, the following works C, and other languages too, I should imagine: /code/ myfile.c - /sources/myfile.c mylib.h - /libs/mylib.h libmylib.so - /libs/libmylib.so an #include mylib.h in myfile.c would look for the file in /code and find it. a cc myfile.c -lmylib would find the libmylib.so in /code This problem was observed on linux, when running hadoop script jobs. The hadoop code (cloudera CDH4) creates a symlink copy of your file structure, where each file is individually symlinked to an place in a file cache, where each file may sit in a different physical dir, like this: tmp1/ a.py - /secret/filecache/0001/a.py b.py - /secret/filecache/0002/b.py c.py - /secret/filecache/0003/c.py Suddenly, importing b and c from a.py won't work. if a, b, and c were .h files, then #include b.h from a.h would work. -- components: Interpreter Core, Library (Lib) messages: 186069 nosy: kristjan.jonsson, ncoghlan, neologix priority: normal severity: normal status: open title: symlinking .py files creates unexpected sys.path[0] type: behavior versions: Python 2.7, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17639 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17639] symlinking .py files creates unexpected sys.path[0]
Kristján Valur Jónsson added the comment: btw, this is the opposite issue to issue #1387483 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17639 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1387483] sys.path[0] when executed thru a symbolic link
Kristján Valur Jónsson added the comment: Closign this again. Opened up a new issue: http://bugs.python.org/issue17639 -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1387483 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17634] Win32: shutil.copy leaks file handles to child processes
Richard Oudkerk added the comment: This problem also affects processes started by multiprocessing (although it is fixed in http://hg.python.org/sandbox/sbt#spawn). As far as I am concerned O_NOINHERIT should really have been applied by default in Python 3. You only get inheritable fds on Windows if you use the msvcrt's spawn*() functions. But in Python 3 os.spawn*() is implemented on top of subprocess so the fds are never inherited (even if the underlying handles are). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17634 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17636] Modify IMPORT_FROM to fallback on sys.modules
Kristján Valur Jónsson added the comment: Like I mentioned on python-dev, it worries me a bit that this could be considered unexpected, i.e. when there is a conflict between a legitimage attribute member of a module, and a submodule of the same name. Also, I wonder if this isn't a bigger change to the import mechanism, than simply: | Another would be | to always require an 'as' clause in this case, so that you would have | to write' |import .foo as foo which would possibly only require a change to the syntax. -- nosy: +kristjan.jonsson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17634] Win32: shutil.copy leaks file handles to child processes
STINNER Victor added the comment: See also the PEP 433 which proposes to disable file descriptor inherance by default. 2013/4/5 Richard Oudkerk rep...@bugs.python.org: Richard Oudkerk added the comment: This problem also affects processes started by multiprocessing (although it is fixed in http://hg.python.org/sandbox/sbt#spawn). As far as I am concerned O_NOINHERIT should really have been applied by default in Python 3. You only get inheritable fds on Windows if you use the msvcrt's spawn*() functions. But in Python 3 os.spawn*() is implemented on top of subprocess so the fds are never inherited (even if the underlying handles are). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17634 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17634 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17453] logging.config.fileConfig error
Hervé Coatanhay added the comment: Yes it does. I fixed my configuration generation and everything is running as expected. Thanks. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17453 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17639] symlinking .py files creates unexpected sys.path[0]
Nick Coghlan added the comment: Adding Guido Ned, as my recollection is that some of the weirdness in the sys.path[0] symlink resolution was to placate the test suite on Mac OS X (at least, that was a cause of failures in the initial runpy module implementation until Guido tracked down the discrepancy in symlink resolution between direct script execution and runpy). How does the test suite react if you change the order of application to resolve symlinks only after dropping the file name from the path? -- nosy: +gvanrossum, ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17639 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17639] symlinking .py files creates unexpected sys.path[0]
Changes by Ralf Schmitt python-b...@systemexit.de: -- nosy: +schmir ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17639 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17636] Modify IMPORT_FROM to fallback on sys.modules
Brett Cannon added the comment: It won't conflict with attributes. Only if the attribute does not exist on the module already will it fall back to sys.modules. If the import finished then any attribute created from the import will already be there and thus not be an issue. But to make sure this isn't a problem we can make sure there is a test in this instance. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17636] Modify IMPORT_FROM to fallback on sys.modules
Kristján Valur Jónsson added the comment: While I'm happy that this is being ackowledged as a problem, I'm not sure changing the import x from y semantics is necessarily a good idea. I mean, it is obvious to me that it means import x, then getattr(x, y). I presume that is the meaning most people associate with it. Certainly, y can be any old module attribute. To change it to actually fall back to a submodule, well. I suppose if you could explain it roughly like y = getattr(x, 'y', x.y) then it would be ok. But I can think of contrived examples where this could break things: #a.py: from .b import util #b.py from . import a from .util import util Because of the circular import order, b.util will not exist as an attribute on b when a does its import. So a.util will end up being util instead of util.util as one might expect. I'm basically saying that it is possible that the fallback to submodule will occur, where the successful getattr would occur later and return something different than the submodule. Possible. But perhaps very much an edge case :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17639] symlinking .py files creates unexpected sys.path
Charles-François Natali added the comment: How does the test suite react if you change the order of application to resolve symlinks only after dropping the file name from the path? Note that this will break things, see e.g. http://bugs.python.org/issue1387483#msg186063 The only backward compatible way to handle this would be to add both directories to sys.path, hoping that there's no module with the same name in both directories. -- title: symlinking .py files creates unexpected sys.path[0] - symlinking .py files creates unexpected sys.path ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17639 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17636] Modify IMPORT_FROM to fallback on sys.modules
Brett Cannon added the comment: By declaring what the semantics will be to make the case even possible we are not breaking anything but making something possible. IOW it isn't even an edge case to me since there is no working case to compare against. =) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17637] Mention What's New in devguide's patch guidelines
Antoine Pitrou added the comment: This is more the duty of the committer IMO. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17637 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17636] Modify IMPORT_FROM to fallback on sys.modules
Changes by Barry A. Warsaw ba...@python.org: -- nosy: +barry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17637] Mention What's New in devguide's patch guidelines
Brett Cannon added the comment: Yes, but that doesn't mean it shouldn't be written down in the devguide (with appropriate note) that committers need to be thinking about this. Start good habits early. =) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17637 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17640] from distutils.util import byte_compile hangs
New submission from Dmitry Sivachenko: The following problem exists in python3.3.0 and python3.3.1rc1. From the command line it works: root@dhcp175-40-red:~ # python3 Python 3.3.1rc1 (default, Apr 5 2013, 18:03:56) [GCC 4.2.1 20070831 patched [FreeBSD]] on freebsd10 Type help, copyright, credits or license for more information. from distutils.util import byte_compile From script it hangs: root@dhcp175-40-red:~ # cat /tmp/comp.py from distutils.util import byte_compile files = [ '/usr/local/lib/python3.3/site-packages/yaml/__init__.py',] byte_compile(files, optimize=1, force=None, prefix=None, base_dir=None, verbose=1, dry_run=0, direct=1) # python3 /tmp/comp.py -- Now it hangs forever, if I press Ctrl+D, I get: Traceback (most recent call last): File /tmp/comp.py, line 1, in module from distutils.util import byte_compile File /usr/local/lib/python3.3/distutils/util.py, line 9, in module import imp File /usr/local/lib/python3.3/imp.py, line 28, in module import tokenize File /usr/local/lib/python3.3/tokenize.py, line 37, in module __all__ = token.__all__ + [COMMENT, tokenize, detect_encoding, AttributeError: 'module' object has no attribute '__all__' -- assignee: eric.araujo components: Distutils messages: 186084 nosy: Dmitry.Sivachenko, eric.araujo, tarek priority: normal severity: normal status: open title: from distutils.util import byte_compile hangs type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17640 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17639] symlinking .py files creates unexpected sys.path
Guido van Rossum added the comment: Do not fix this. It is an intentional feature. There is a common pattern where one or more Python scripts are collected in some bin directory (presumably on the user's $PATH) as symlinks into the directory where they really live (not on $PATH, nor on sys.path). The other files needed by the script(s) are in the latter directory, and so it needs to be on sys.path[0]. If you change the symlink resolution, sys.path[0] will point to the bin directory and the scripts won't be able to find the rest of their modules. While there are probably better patterns to solve the problem that this intends to solve, the pattern is commonly used and I do not want it to be broken. If you are using symlinks for other purposes, well, too bad. -- resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17639 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17639] symlinking .py files creates unexpected sys.path
Nick Coghlan added the comment: I'll add it to the list of docs updates for post-PEP 432 (similar to the import system in general finally getting reference docs in 3.3 following the migration to importlib, I hope to have improved import state initialisation docs for 3.4 if I successfully tame the interpreter initialisation code) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17639 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17639] symlinking .py files creates unexpected sys.path
Kristján Valur Jónsson added the comment: 1) _I_ am not using symlinks this way. The hadoop scheduling processor is. This means that we cannot use Python for it withouth hacking the scripts for the special case. Presumably applications are not generally breaking when run in an artificial file tree populated with symlinked files into arbitrary real locations, but Python is. Only Python seems to care about the _real_ location of the file, as opposed to the apparent location. 2) This particular use case is quite unobvious, and goes against the spirit of symbolic links. They are meant to be transparent for applications. Consider e.g. the analogue to e.g. C header files. Only Python seems to care about the _real_ location of the file, as opposed to the apparent location. Effectively, Python is actively using the knowledge of these links as a sort of dynamic sys.path modifying tool. I agree that it is not good to break existing usage, however misguided it may be. But in that case, isn't it possible to disable this symlink dereference via e.g. an option? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17639 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17637] Mention What's New in devguide's patch guidelines
Antoine Pitrou added the comment: Then it should probably go in http://docs.python.org/devguide/committing.html -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17637 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17639] symlinking .py files creates unexpected sys.path
Nick Coghlan added the comment: Not currently, because interpreter startup is a mess already. Overriding sys.path[0] initialisation is on the list for 3.4 already, I'm just advising strongly against piling any more complexity on top of the current rickety structure until we do something about the foundation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17639 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17639] symlinking .py files creates unexpected sys.path
Guido van Rossum added the comment: I'm sure there's some change that can be made to the scripts that solves this locally, without requiring any changes to Python. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17639 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17576] PyNumber_Index() is not int-subclass friendly (or operator.index() docos lie)
Changes by Ethan Furman et...@stoneleaf.us: -- nosy: +stoneleaf ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17576 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17639] symlinking .py files creates unexpected sys.path
Kristján Valur Jónsson added the comment: Yes, of course. But I still maintain that the failure of python to work with a linktree of .py files, where the destination position of said links is arbitrary, is rather unusual, and IMHO violates the principle of least surprise. In this case, the existence of the virtual linktree is apparently an implementation detail of the hadoop implementation, not something that we as hadoop users were supposed to know or care about. Exploiting the OS file system implementation detail of a symbolic link as a language import feature is an example of an unusual coupling indeed, in my opinion. Even import-guru Nick didn't seem to be aware of this feature. It's great that we plan at least to document this unix-only feature at some point. Cheers! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17639 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13922] argparse handling multiple -- in args improperly
paul j3 added the comment: There are several problems with the patch provided in msg156315 This description: Added patch so that only the first '--' is removed by an argparse.PARSE or argparse.REMAINDER argument. should read Added patch so that only the first '--' is removed by arguments that are not argparse.PARSER or argparse.REMAINDER . The test that adds a third subparser with a nargs='...' argument does not test this change. It exercises both nargs types that are not affected by the change in argparse.py. As such older versions of argparse pass this test. I thinking argparse.py change is correct (delete only the 1st '--'), though I'm not sure it addresses the concern of the original poster. -- nosy: +paul.j3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13922 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17636] Modify IMPORT_FROM to fallback on sys.modules
Phillip J. Eby added the comment: On Fri, Apr 5, 2013 at 9:07 AM, Kristján Valur Jónsson rep...@bugs.python.org wrote: But I can think of contrived examples where this could break things: #a.py: from .b import util #b.py from . import a from .util import util Because of the circular import order, b.util will not exist as an attribute on b when a does its import. So a.util will end up being util instead of util.util as one might expect. Not quite. It will only do this if the '.b.util' module is *in sys.modules* at the time that a is being imported, which also means that .b.util has to be imported somewhere *before* .a, in order to end up with a stale value. As written, your example actually works correctly if .a is imported first, and fails with an ImportError if .b is imported first. In fact, this example is kind of useful for proving the change *correct*, not broken. At the very least, it shows that you'll have to be more inventive to come up with a breaking case. ;-) Consider that for any module x.y, x must be in sys.modules before x.y can. Therefore, any from x import taking place before x is fully loaded will either happen before x.y is fully loaded, during the load, or after it, and the following cases apply: 1. If it happens before, then it fails with an ImportError as is the case today. 2. If it happens during (i.e. there is a cycle with x.y rather than with just x), then the import returns the module. 3. If it happens after, then either the x.y attribute is bound to the submodule, or has been rebound to something else, or deleted. 4. If after and deleted, the import returns the module. 5. If after and rebound, the import returns the changed attribute (just like today) 6. If after and normally bound, the import returns the module (just like today) The only cases in which the behavior changes from today are cases 2 and 4, which would both fail today with an ImportError. Case 4 also doesn't make much sense, since 'import x.y' would still permit access to the module -- so it'd have to be an odd situation in which you didn't want 'from import' (and *only* from import) to fail. So let's consider case 2, which would have to be written something like: #a.py from .b import util #b.py from .util import util #b/util.py from .. import a def util(): pass #__main__.py import b So, import b leads to starting the load of b.util, which leads to importing a, which succeeds and sees the b.util module instead of the b.util:util function. But, because of the circularity, this will *also* happen if you import a first. So 'a' will *always* see b.util rather than b.util:util, unless you remove the circularity. If you remove the circularity, then 'a' will always see b.util:util as the value of util. So case 2 does not lead to a hard-to-debug ordering dependency, it leads to an immediately discoverable change in behavior the moment you start importing a from b.util. The tl;dr version of the above is that you will only receive a module instead of an attribute if the module that's about to be replaced just imported *you* during its initial loading, and if it does that, it'll do it no matter what order the imports occur in, making the problem occur immediately and consistently as soon as you introduce the circularity. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16480] pyvenv 3.3 fails to create symlinks for virtualenv/local/{bin, lib} to virtualenv/{bin, lib}
Marten Lehmann added the comment: Which bug ID? Couldn't find it anywhere in the previous comments. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16480 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17636] Modify IMPORT_FROM to fallback on sys.modules
Phillip J. Eby added the comment: Actually, after a little reflection, I can see that there are more complex conditions to analyze, if 'b' doesn't import 'b.util', but some other module imports b and sets b.util. But that's just freaking insane and whoever does that probably deserves whatever they get, especially since a later 'import b.util' would blow away the modified attribute. So, this note is just to satisfy myself that the change doesn't introduce any *new* weirdness unless you are in a case where the parent imports and replaces the child, and the child is involved in an import cycle. If the parent doesn't import the child but just assigns an attribute, it's already broken the minute somebody else imports the child, and the same thing applies if something else sets the attribute without importing the child first, and if it imports the child first, then the previous analysis (mostly) applies, but either way that code is broken and will have plenty of other ordering dependencies to debug on its own. ;-) (No wonder Nick said nobody wanted to touch this... the analysis alone is a killer. ;-) Luckily, it seems we're good to go unless somebody can find a case I missed.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17636] Modify IMPORT_FROM to fallback on sys.modules
Phillip J. Eby added the comment: ...and I thought of *one* more way to trigger the changed behavior, which looks like: #b.py from .b import util import .a util = util.util #b/util.py def util(): pass (with the other files the same as before). I'm including it only for completeness' sake, because my original enumeration of cases ignored the possibility that 'a' could be doing the import *after* b.util is loaded and bound, but *before* it's rebound. However, it doesn't produce any new or problematic effects: it's essentially the same as if 'a' were imported from 'b.util'. Once again, regardless of the order in which imports happen, 'a' ends up with 'b.util' the moment the circularity is introduced, and it stays that way. It's also hard to argue that a case written this way isn't getting exactly what it *says* it wants. In fact, it looks like code that was deliberately written to *force* a to end up with the original b.util instead of the replaced one. ;-) Final (hopefully) conclusion: this change replaces the FAQ of Don't use 'from-import' for circular imports with the hopefully-less-FA'd Q of when from-import is part of an import cycle, it works *exactly* like regular import, so you're going to get a submodule rather than an attribute. If you need the attribute instead, move the import so that it happens after the attribute is set up. (Which is exactly the same advice that would apply in a cycle with any other unitialized attribute, whether you were using from-import or not.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17641] ssl module doc unification
New submission from Giampaolo Rodola': I noticed 2.X version of ssl module doc does not mention different socket methods (sendall(), accept(), etc) whereas the 3.X version does. Patch in attachment unifies the 2 docs. -- assignee: docs@python components: Documentation keywords: easy, needs review messages: 186097 nosy: docs@python, ezio.melotti, giampaolo.rodola, pitrou priority: normal severity: normal status: open title: ssl module doc unification versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17641 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17636] Modify IMPORT_FROM to fallback on sys.modules
Kristján Valur Jónsson added the comment: Wow, Good analysis Phillip. So, we agree that the fallback still is a sensible fallback? Then everything is fine and I'll put my official +1 stamp of approval on this. Now... should we consider the current behavious to be a bug? 2.7 sure could do with some fixing :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Jeff Kaufman added the comment: What would it take to get this moving again? -- nosy: +Jeff.Kaufman ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6696] Profile objects should be documented
Tom Pinckney added the comment: Updated based on Ezio's comments. -- Added file: http://bugs.python.org/file29683/patch3.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6696 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
R. David Murray added the comment: Someone needs to write the PEP. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2292 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17636] Modify IMPORT_FROM to fallback on sys.modules
Phillip J. Eby added the comment: I don't care much one way or the other about it being considered a bug in 2.x, but it might be worth considering a bug in 3.x. Either way, though, the language reference for from import should reflect the change, and alternative implementations should be informed of the update. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17636] Modify IMPORT_FROM to fallback on sys.modules
Brett Cannon added the comment: It is not a bug but a change in semantics to accommodate a use-case so this will only be going into Python 3.4. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17636 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17343] Add a version of str.split which returns an iterator
Raymond Hettinger added the comment: -1 on os.walk returning an iterator. The API is already a bit challenging for some and our experience with itertools.groupby() is that returning an inner iterator can be very confusing. -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17343 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17343] Add a version of str.split which returns an iterator
Alex Gaynor added the comment: Raymond: Is that for the wrong ticket, or was the message incorrect? :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17343 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17343] Add a version of str.split which returns an iterator
Raymond Hettinger added the comment: Alex, it was response to Terry's message: http://bugs.python.org/issue17343#msg183782 FWIW, I'm +1 on an iterator version of str.split(). I'm not sure yet that it would be worthwhile to propagate the idea to other string-like objects though. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17343 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17641] ssl module doc unification
Antoine Pitrou added the comment: The patch seems to be missing. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17641 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17641] ssl module doc unification
Giampaolo Rodola' added the comment: Shame on me and my scatterbrained head! =) -- keywords: +patch Added file: http://bugs.python.org/file29684/ssl-doc.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17641 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17620] Python interactive console doesn't use sys.stdin for input
Changes by Tshepang Lekhonkhobe tshep...@gmail.com: -- nosy: +tshepang ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17620 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17641] ssl module doc unification
Antoine Pitrou added the comment: Giampaolo Rodola' added the comment: Shame on me and my scatterbrained head! =) Thanks, looks fine to me! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17641 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17637] Mention What's New in devguide's patch guidelines
Changes by Tshepang Lekhonkhobe tshep...@gmail.com: -- nosy: +tshepang ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17637 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13922] argparse handling multiple -- in args improperly
paul j3 added the comment:
There's another 'feature' to the patch proposed here. It only deletes the
first '--' in the list of strings passed to '_get_values' for a particular
action.
parser = argparse.ArgumentParser()
parser.add_argument('foo')
parser.add_argument('bar', nargs='*')
print(parser.parse_args('-- 1 -- 2 3 4'.split(' ')))
# Namespace(bar=['2', '3', '4'], foo='1')
'_get_values' first gets ('foo',['--','1']), then ('bar',['--','2','3','4'])
print(parser.parse_args('-- -- 1 -- 2 -- 3 4'.split(' ')))
# with this '1st only' change
# Namespace(bar=['1', '2', '--', '3', '4'], foo='--')
# without it, deleting all '--'; note foo is empty
# Namespace(bar=['1', '2', '3', '4'], foo=[])
And to confuse things a bit more:
print(parser.parse_args('1 -- 2 3 4'.split(' ')))
# Namespace(bar=['2', '3', '4'], foo='1')
passes ['1','--'] with 'foo'
If 'bar' nargs='...', bar gets all of the '--' (with or without this patch).
The handling of '--' is complex because it is used in one place to mean,
'everything else is an argument', effectively adding '-AA...' to the
arg_strings_pattern. It also matches with the nargs_pattern (e.g.
'(-*A-*)...'). And then it may or may not be removed in _get_values().
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13922
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17469] Fix sys.getallocatedblocks() when running on valgrind
Roundup Robot added the comment: New changeset 2bf154ca43c6 by Antoine Pitrou in branch 'default': Issue #17469: Fix _Py_GetAllocatedBlocks() and sys.getallocatedblocks() when running on valgrind. http://hg.python.org/cpython/rev/2bf154ca43c6 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17469 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17469] Fix sys.getallocatedblocks() when running on valgrind
Antoine Pitrou added the comment: Patch committed, thank you! -- resolution: - fixed stage: - committed/rejected status: open - closed versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17469 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16551] Cleanup the pure Python pickle implementation
Antoine Pitrou added the comment: Patch looks fine to me. Do you want to go ahead? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16551 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16804] python3 -S -m site fails
Antoine Pitrou added the comment: Patch works ok here, but should there be a test too? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16804 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15596] pickle: Faster serialization of Unicode strings
Antoine Pitrou added the comment: Ping? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15596 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16102] uuid._netbios_getnode() is outdated
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +brian.curtin, tim.golden ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16102 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16432] Template strings documentation in Python 3 refers to % substitution in present tense
Changes by Andrew Gorcester andrew.gorces...@gmail.com: -- resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16432 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17641] ssl module doc unification
Roundup Robot added the comment: New changeset 03c65fc349c0 by Giampaolo Rodola' in branch '2.7': #17641: 2.X / 3.X ssl doc unification http://hg.python.org/cpython/rev/03c65fc349c0 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17641 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17641] ssl module doc unification
Changes by Giampaolo Rodola' g.rod...@gmail.com: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17641 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17449] dev guide appears not to cover the benchmarking suite
Changes by Edmond Burnett eburn...@gmail.com: -- nosy: +edmond.burnett ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17449 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17639] symlinking .py files creates unexpected sys.path
Nick Coghlan added the comment: The reason I haven't documented sys.path[0] initialisation is because I know I don't fully understand it. Path initialisation in general has a lot of historical quirks, particularly once symlinks are involved. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17639 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16389] re._compiled_typed's lru_cache causes significant degradation of the mako_v2 bench
Changes by Serhiy Storchaka storch...@gmail.com: -- resolution: - fixed stage: test needed - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16389 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
