[issue38884] __import__ is not thread-safe on Python 3
Change by Geoffrey Bache : -- nosy: +gjb1002 ___ Python tracker <https://bugs.python.org/issue38884> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35943] PyImport_GetModule() can return partially-initialized module
Geoffrey Bache added the comment: @Valentyn Tymofieiev - true, and thanks for the tip, though the symptoms described there are somewhat different from what I'm observing. Also, my problem seems to be dependent on zipping the Python code, which that one isn't. -- ___ Python tracker <https://bugs.python.org/issue35943> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35943] PyImport_GetModule() can return partially-initialized module
Geoffrey Bache added the comment: Oops, I mean we call PyImport_ImportModule and get these issues when the files are zipped. Unless that calls PyImport_GetModule internally I guess it's not related to this then. -- ___ Python tracker <https://bugs.python.org/issue35943> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35943] PyImport_GetModule() can return partially-initialized module
Geoffrey Bache added the comment: I have been experiencing what I thought was this issue in my embedded Python code. We have been using Python 3.7, so I thought upgrading to 3.8.1 would fix it, but it doesn't seem to have made any difference. My C++ code essentially can call PyImport_GetModule() from two threads simultaneously on the same module A. The symptoms I see are that one of them then gets a stacktrace in module B (imported by A), saying that some symbol defined near the end of B does not exist. I've also noticed that this happens far more often on deployed code (where Python modules end up in a zip file) than when run directly in development (where the modules are just normal files). I can't see any difference in the frequency between 3.7.5 and 3.8.1. Any ideas? Should I reopen this? -- nosy: +gjb1002 ___ Python tracker <https://bugs.python.org/issue35943> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15451] PATH is not honored in subprocess.Popen in win32
Changes by Geoffrey Bache gjb1...@users.sourceforge.net: -- nosy: +gjb1002 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15451 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12739] read stuck with multithreading and simultaneous subprocess.Popen
Changes by Geoffrey Bache gjb1...@users.sourceforge.net: -- nosy: +gjb1002 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12739 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12739] read stuck with multithreading and simultaneous subprocess.Popen
Geoffrey Bache added the comment: Just ran into this on Python 2.6 also. -- versions: +Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12739 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12739] read stuck with multithreading and simultaneous subprocess.Popen
Geoffrey Bache added the comment: Thanks Victor, yes I already created my own lock which fixed the issue for me. Maybe it would be worth adding a note to the documentation about this in the meantime (especially for Python 2)? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12739 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14418] Document differences in SocketServer between Python 2.6 and 2.7
New submission from Geoffrey Bache gjb1...@users.sourceforge.net: Here I'm referring to the section about RequestHandler objects under the SocketServer page. http://docs.python.org/release/2.7.2/library/socketserver.html#requesthandler-objects This appears to be the same in Python 2.6 and Python 2.7. But the objects don't behave the same, in two respects: 1) For finish() If setup() or handle() raise an exception, this function will not be called. This is true in Python 2.6. It appears to no longer be true in Python 2.7, where finish() is called in a finally clause. 2) For handle(). The default implementation does nothing. This is true up to a point, but using the default implementation has different effects. Specifically, if I try to read from a socket when the server has not written anything, I get an exception in Python 2.6 and an empty string in Python 2.7. Consider this code: ## server.py from SocketServer import TCPServer, StreamRequestHandler import sys, socket server = TCPServer((socket.gethostname(), 0), StreamRequestHandler) host, port = server.socket.getsockname() address = host + : + str(port) print Started server at, address sys.stdout.flush() server.serve_forever() ## client.py import sys, socket servAddr = sys.argv[1] host, port = servAddr.split(:) serverAddress = (host, int(port)) sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.connect(serverAddress) sock.sendall(Some Message) sock.shutdown(1) response = sock.makefile().read() print Got reply:, response sock.close() and compare the following: $ python2.7 server.py Started server at 127.0.1.1:42759 $ python2.7 client.py 127.0.1.1:42759 Got reply: $ python2.6 server.py Started server at 127.0.1.1:42758 $ python client.py 127.0.1.1:42758 Traceback (most recent call last): File client.py, line 12, in module response = sock.makefile().read() File /usr/lib/python2.7/socket.py, line 351, in read data = self._sock.recv(rbufsize) socket.error: [Errno 104] Connection reset by peer (doesn't matter which Python runs the client in the last case) I am unsure whether this is a bug in Python 2.6, or really what the reasoning behind the behaviour difference is, but I think this change in behaviour is worth a small note in the documentation (how it will behave if you try to read when nothing has been written) -- assignee: docs@python components: Documentation messages: 156869 nosy: docs@python, gjb1002 priority: normal severity: normal status: open title: Document differences in SocketServer between Python 2.6 and 2.7 versions: Python 2.6, Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13597] Improve documentation of stdout/stderr buffering in Python 3.x
Geoffrey Bache gjb1...@users.sourceforge.net added the comment: Thanks. I'm not sure what you've written about the -u flag is correct though currently. From experimenting I believe it changes buffering of stdout and stderr to line-buffering also when directed to file, i.e. it does affect the behaviour of the text-layer. Some other changes might be needed also, but perhaps they should wait until we know whether issue13601 will be accepted. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13597 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13601] sys.stderr should be unbuffered (or always line-buffered)
Geoffrey Bache gjb1...@users.sourceforge.net added the comment: I'm hesitant to make it line-buffered by default when directed to a file, since this could significantly slow down a program that for some reason produces super-voluminous output (e.g. when running a program with heavy debug logging turned on). Is that really the purpose of standard error though? Heavy debug output, in my experience, is usually sent to standard output or to another file. Also, did anyone ever complain about this as a problem, given it is the default behaviour of Python 2? In my view the requirements of seeing errors when they happen, and guaranteeing that they will always be seen no matter what happens afterwards, should weigh more heavily than this. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13601 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13597] Improve documentation of stdout/stderr buffering in Python 3.x
Geoffrey Bache gjb1...@users.sourceforge.net added the comment: The changes are good as far as they go, but they only affect the documentation of sys.stderr and sys.stdout. I also suggested changes to the documentation of the -u flag, and to What's New in Python 3.0, can someone look at that also? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13597 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13601] sys.stderr should always be line-buffered
Geoffrey Bache gjb1...@users.sourceforge.net added the comment: I think we all agree line-buffering is sufficient, so I change the title. -- title: sys.stderr should be unbuffered (or always line-buffered) - sys.stderr should always be line-buffered ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13601 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13601] sys.stderr should be unbuffered (or always line-buffered)
Changes by Geoffrey Bache gjb1...@users.sourceforge.net: -- nosy: +gjb1002 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13601 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13597] Improve documentation of stdout/stderr buffering in Python 3.x
Geoffrey Bache gjb1...@users.sourceforge.net added the comment: I would certainly be in favour of restoring the python 2.x behaviour, at least where standard error is concerned. When writing Python programs, it's important to see exceptions immediately, and not lose them entirely in some circumstances. I reported this as a documentation bug because I got the impression it was deliberate, mostly from reading http://bugs.python.org/issue4705 and the comp.lang.python thread in the description, but I personally think the Python 2.x behaviour was preferable. -- components: -IO nosy: -benjamin.peterson, pitrou, pjenvey, stutzbach versions: +Python 3.1, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13597 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13597] Improve documentation of stdout/stderr buffering in Python 3.x
Geoffrey Bache gjb1...@users.sourceforge.net added the comment: Ooops, seems like I just ran into a bug in the bug tracker too, it seems to have backed out other people's changes. Restoring them... -- components: +IO nosy: +benjamin.peterson, pitrou, pjenvey, stutzbach versions: -Python 3.1, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13597 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13597] Improve documentation of stdout/stderr buffering in Python 3.x
New submission from Geoffrey Bache gjb1...@users.sourceforge.net: The default buffering of standard output and standard error has changed in Python 3.x with respect to Python 2.x, and I have been unable to find decent documentation of either the current behaviour, or the change. (See also http://groups.google.com/group/comp.lang.python/browse_thread/thread/43476d4682059f53#) Part 1 - the change --- From rude experiment it seems that: a) In Python 2.x, standard error was always unbuffered while standard output was buffered by default. In python3, both are buffered. In both cases, buffered means line-buffered when writing to the console and not line-buffered when redirected to files. b) In Python 2.x, the -u flag meant everything was totally unbuffered. In Python 3.x, it means that both stdout and stderr are line-buffered also when redirected to files. One important consequence of (a) is, if stderr is redirected to a file, your program throws an exception and is then subsequently terminated with SIGTERM, you will not see the exception. This will not be expected for someone used to the Python 2.x behaviour. What's New in Python 3.0 has this to say about the change (in the section marked Changes Already Present In Python 2.6 # PEP 3116: New I/O Library. The io module is now the standard way of doing file I/O, and the initial values of sys.stdin, sys.stdout and sys.stderr are now instances of io.TextIOBase. [...] This seems wrong in that, while the io module was present in Python 2.6, the change noted to sys.stdin, sys.stdout and sys.stderr was not. Also, it is far from obvious from this note that any externally observable behaviour has changed. I suggest changing this to a) note the buffering changes listed above b) note the change in meaning of the -u flag c) Move this to its own section which is not part of changes to Python 2.6 (it's OK to keep the note about the new io module there) Part 2 - the behaviour -- a) The documentation for sys.stdout and sys.stderr does not say anything about their default buffering properties in various situations, nor how this can modified by setting the -u flag. b) The documentation for -u is misleading: Force the binary layer of the stdin, stdout and stderr streams (which is available as their buffer attribute) to be unbuffered. The text I/O layer will still be line-buffered. The still in the last sentence is only relevant when stdout/stderr are writing to the console. If they are redirected to file, -u *modifies the behaviour such that* the text I/O layer will be line-buffered. -- assignee: docs@python components: Documentation messages: 149408 nosy: docs@python, gjb1002 priority: normal severity: normal status: open title: Improve documentation of stdout/stderr buffering in Python 3.x type: behavior versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13597 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13074] Improve documentation of locale encoding functions
New submission from Geoffrey Bache gjb1...@users.sourceforge.net:
The locale module provides locale.getdefaultlocale and
locale.getpreferredencoding. The encodings returned by each are generally
subtly different ('ISO8859-1' vs 'ISO-8859-1'), but the difference between
these methods is not explained.
A comment by Martin von Löwis from 2003 in http://bugs.python.org/issue813449
indicates that getdefaultlocale should not be used in new code, if this is
really the case then this should be in the docs.
Anyone reading the docs from the top will currently encounter getdefaultlocale
first and believe that this is the way to get the encoding.
--
assignee: docs@python
components: Documentation
messages: 144677
nosy: docs@python, gjb1002
priority: normal
severity: normal
status: open
title: Improve documentation of locale encoding functions
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13074
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13076] Bad links to 'time' in datetime documentation
New submission from Geoffrey Bache gjb1...@users.sourceforge.net: Reading through the datetime module documentation, various places that refer to datetime.time objects are in fact links to the time module. They should refer to the appropriate section on the same page. -- messages: 144689 nosy: gjb1002 priority: normal severity: normal status: open title: Bad links to 'time' in datetime documentation versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13076 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13076] Bad links to 'time' in datetime documentation
Changes by Geoffrey Bache gjb1...@users.sourceforge.net: -- assignee: - docs@python components: +Documentation nosy: +docs@python ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13076 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10927] Allow universal line endings in filecmp module
New submission from Geoffrey Bache gjb1...@users.sourceforge.net: It would be useful to compare the contents of two files while not caring what platform they were produced on, perhaps a universal_line_endings parameter to e.g. filecmp.cmp and possibly other methods. At the moment opening the files with rb is hardcoded in filecmp.py. If there is another way to achieve this, please enlighten me... -- components: Library (Lib) messages: 126405 nosy: gjb1002 priority: normal severity: normal status: open title: Allow universal line endings in filecmp module type: feature request ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10927 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10374] setup.py caches outdated scripts in the build tree
New submission from Geoffrey Bache gjb1...@users.sourceforge.net: I have the following setup.py script: #!/usr/bin/env python from distutils.core import setup scripts=[hello.py] setup(scripts=scripts) I have two different python installations (using virtualenv) where I wish to install this program. So I do ~/tmp/test_setup/python1/bin/python setup.py install which creates a file at /users/geoff/tmp/test_setup/python1/bin/hello.py, that looks like this: #!/users/geoff/tmp/test_setup/python1/bin/python print Hello So far so good. But then I also install it somewhere else: ~/tmp/test_setup/python2/bin/python setup.py install which creates a file at /users/geoff/tmp/test_setup/python2/bin/hello.py which refers to python1, i..e it has the same contents as the first one. Which is clearly not what I want. The cached script in the build tree appears not to get updated once it exists. -- assignee: tarek components: Distutils messages: 120864 nosy: eric.araujo, gjb1002, tarek priority: normal severity: normal status: open title: setup.py caches outdated scripts in the build tree type: behavior versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10374 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2972] arguments and default path not set in site.py and sitecustomize.py
Geoffrey Bache gjb1...@users.sourceforge.net added the comment: Thanks for the tips, looks like we have the basis for a solid workaround here. Perhaps that could be encapsulated and added as sys.raw_argv or something in future? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2972 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2972] arguments and default path not set in site.py and sitecustomize.py
Geoffrey Bache gjb1...@users.sourceforge.net added the comment: I also just ran into this. Is it likely that an enhancement request to provide access to the raw command line, as requested by the previous commenter, would be accepted? It's sometimes useful to have some idea about what kind of Python process is being started at this point. -- nosy: +gjb1002 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2972 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2972] arguments and default path not set in site.py and sitecustomize.py
Geoffrey Bache gjb1...@users.sourceforge.net added the comment: Interesting. Any idea if something similar is possible on Linux? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2972 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9943] TypeError message became less helpful in Python 2.7
Geoffrey Bache gjb1...@users.sourceforge.net added the comment: I agree with Nick :) Though I'd say fixing a regression should take priority over further enhancing the messages. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9943] TypeError message became less helpful in Python 2.7
Geoffrey Bache gjb1...@users.sourceforge.net added the comment: I think the unhelpful part is mostly that it does not distinguish between argument types any more when the distinction is important in this context. In fact, it could be argued that what it said isn't even true: f() takes exactly 0 arguments (2 given) f() doesn't take exactly 0 arguments. It takes any number of arguments, so long as they are keyword arguments. Surely you agree that the Python 2.6 error describes the problem more accurately? As for your examples, the message in the first one has changed from TypeError: f() takes exactly 1 non-keyword argument (4 given) to TypeError: f() takes exactly 1 argument (5 given) which is possibly a marginal improvement, although taken together I would say this isn't an improvement, especially as I think examples like my first one are more widespread (OK, I didn't even know this syntax was legal...) Your second example is only legal syntax in Python 3, so I don't really get the point with respect to comparing Python 2.6 and Python 2.7. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9943] TypeError message became less helpful in Python 2.7
New submission from Geoffrey Bache gjb1...@users.sourceforge.net: Consider the following code: ### keywords.py def f(**kw): print arg, kw f(hello, keyword=True) and compare the behaviour in Python 2.6 and Python 2.7: $ python keywords.py Traceback (most recent call last): File keywords.py, line 5, in module f(hello, keyword=True) TypeError: f() takes exactly 0 non-keyword arguments (1 given) $ python2.7 keywords.py Traceback (most recent call last): File keywords.py, line 5, in module f(hello, keyword=True) TypeError: f() takes exactly 0 arguments (2 given) The error message from 2.6 is I would say a more accurate description of the situation. -- components: Interpreter Core messages: 117327 nosy: gjb1002 priority: normal severity: normal status: open title: TypeError message became less helpful in Python 2.7 type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1820] Enhance Object/structseq.c to match namedtuple and tuple api
Changes by Geoffrey Bache gjb1...@users.sourceforge.net: -- nosy: +gjb1002 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1820 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2118] smtplib.SMTP() raises socket.error rather than SMTPConnectError
Changes by Geoffrey Bache gjb1...@users.sourceforge.net: -- nosy: +gjb1002 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2118 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4057] Popen(..., cwd=...) does not set PWD environment variable
Geoffrey Bache gjb1...@users.sourceforge.net added the comment: I tried that and it didn't work, though not for this reason. I'm also trying to read the output from the subprocess via a pipe and that wasn't being collected for some reason. I didn't really track down why so far, if it makes or breaks this bug I can do so though. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4057 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4057] Popen(..., cwd=...) does not set PWD environment variable
Geoffrey Bache gjb1...@users.sourceforge.net added the comment: You misunderstand: I am not reading $PWD. I need to call a C program as a subprocess, which is written by a third party and which determines its current working directory by reading $PWD. os.chdir will not have any effect on this script, nor will passing cwd to subprocess.call. I have to write os.environ[PWD] = os.getcwd() in my code before it will work. Not only that, but of course I have to know about $PWD and the fact that some people use it. Otherwise it just seems like Python isn't correctly passing on the current working directory. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4057 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4057] Popen(..., cwd=...) does not set PWD environment variable
Changes by Geoffrey Bache gjb1...@users.sourceforge.net: -- nosy: +gjb1002 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4057 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4057] Popen(..., cwd=...) does not set PWD environment variable
Geoffrey Bache gjb1...@users.sourceforge.net added the comment: I can see your point, though I think particularly in this case it's (unfortunately) fairly common that scripts on POSIX platforms read $PWD instead of finding the current working directory properly. I'm probably not the first person that has had to set PWD explicitly in a python program for this reason. Yes, it's really the fault of the people who maintain the script I'm calling, but I don't think setting PWD on POSIX could have any bad effects and should surely be easy to do? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4057 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2986] difflib.SequenceMatcher not matching long sequences
Changes by Geoffrey Bache gjb1...@users.sourceforge.net: -- nosy: +gjb1002 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2986 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6136] Make logging configuration files easier to use
Geoffrey Bache gjb1...@users.sourceforge.net added the comment: My comp.lang.python thread is here: http://groups.google.com/group/comp.lang.python/browse_thread/thread/a0c35c3c9ad210a4 It was met by deafening silence though. I don't see why a simple format would need to be customer-specific. log4py's isn't/wasn't and that worked just fine. It did support logging to more than files but its configuration file scaled down much more gracefully for simple usage, mostly because it didn't expose its internal design like the logging one does. It had only loggers instead of loggers/handlers/formatters. But log4py is discontinued now as a project and I can't face maintaining my own copy of it any more. I'm getting the feeling you're just trying to fob me off here. You dismiss the threads I found as being mostly about other things or not mentioning specifics. That may be so, but the fact is, in those threads you have five other people expressing in one way or another that the configuration file is too complex - and I'm sure I could find more if you really want. If you prefer to ignore them and me there's not much point in discussing further. I'm not demanding that you do this work. I'm simply trying to raise the issue and asking you to consider accepting such a patch if I or somebody else produce it. -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6136] Make logging configuration files easier to use
Geoffrey Bache gjb1...@users.sourceforge.net added the comment: If it was never intended for end users, then perhaps you could rename this request as provide an end-user-friendly log configuration format (that would live alongside the current one). It's hardly unusual that users should be able to troubleshoot systems themselves by requesting more (or different) logging, is it? For example, log4py's format looked like this: [my_logger] LogLevel: Normal Target: my_filename.log Pretty much anyone can edit a bunch of sections that look like that (with optional extras such as formatting where appropriate). As for mentions of this issue online, I linked to one such on my comp.lang.python posting. It isn't recent, but the points about the config file still apply as it hasn't substantially changed since then as far as I can see. 3 different users raise essentially the same point (and you also contributed to this thread) http://www.mechanicalcat.net/richard/log/Python/Simple_usage_of_Python_s_logging_module Here's another (only some of the discussion is relevant, but this exact point is raised by the original poster and agreed with by the responder): http://markmail.org/message/amxocg2nskd72qaf -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6136] Make logging configuration files easier to use
Geoffrey Bache gjb1...@users.sourceforge.net added the comment: OK, I hadn't seen the delay parameter until now. I guess this is new in Python 2.6? Good that there is already a way to avoid lots of empty files, though it'll be a while before I can assume Python 2.6 unfortunately... that probably renders point (a) moot. As for (b), do you not think a large number of users will not bother with the hierarchical aspect of the logging framework? I'd say you need to be pretty advanced/large scale before that becomes interesting. I don't really understand why accepting such a patch would be a problem, as it's a simple change that wouldn't break backwards compatibility. It's surely got to be better than exiting with a python stack, which is what happens today. (To give an idea of the bloat-factor, since migrating to the logging framework a typical configuration file for my system is now roughly 3 times the size it used to be for the same functionality) -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6136] Make logging configuration files easier to use
Geoffrey Bache gjb1...@users.sourceforge.net added the comment: Who said anything about not supporting users who want the hierarchy? I'm talking about making qualname optional, not removing it entirely! I even supplied the entirety of the code (all 4 lines of it) to be clear what I meant a few comments ago. The files have gone from about 5kb to about 15kb. Of course diskspace is not a problem in itself, but these files need to be read and edited by non-coders and they're a lot scarier (and harder to tweak) than the old ones were. Basically they're full of abstract technical concepts (qualname, handler) and bits of python code to be eval'ed. Yes, I can write my own format. But I can't see anything about my case which is unusual and I'm sure there must be a demand for something simpler, which is why I bothered to report this issue at all. It's not particularly hard to find people out there raising this if you google a bit. But I shall raise this on comp.lang.python as you suggest. -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6136] Make logging configuration files easier to use
Geoffrey Bache gjb1...@users.sourceforge.net added the comment: OK, I'll take point (c) further on comp.lang.python. As for the others, it would be useful if you could at least understand my points. a) I'm aware that there isn't necessarily a one-to-one correspondence between loggers and files, don't see why that's relevant. I have no idea what the common way of using logging is, if there is one. Having lots of files in a logging set up doesn't seem to me in any way unusual, even if the number of loggers is potentially even larger. The main question is the one I posed before: what is the point of opening files that will never be written to and sockets that will never be used? Or to put it another way, if I submitted a patch that only created handlers that were used by at least one logger, would you look at it? b) compulsory as in compulsory as an entry in the config file. The code would be if qualname in opts: qn = cp.get(sectname, qualname) else: qn = log To make life easier for those of us who don't see the point in naming loggers differently in the config file and in the code... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6136] Make logging configuration files easier to use
Geoffrey Bache gjb1...@users.sourceforge.net added the comment: a) What is the point of opening files that will never be written to and sockets that will never be used? A large application might have a great many loggers for debugging which are off by default, and this means you have to either put up with lots of empty files being created all the time, or tell everyone that they need to change the configuration in two places each time they enable or disable a logger. Logging config files need to be easy to tweak, even for people who aren't coders: it should be quick and obvious how to enable or disable a logger. b) I don't see why making those sections optional would break backward compatibility. It would be easy to just silently ignore them if they were present (or call today's code that uses them). I'm aware that qualname isn't always the same as the section name. My point is that it should not be *compulsory*, not that it shouldn't exist. It has an obvious default value so it's wrong to fail with a python stack if it isn't present. c) I know there are other packages out there. I've been using log4py for years, which is now abandoned. But Python now has an official way to do logging and I think it should be more user-friendly for simple usage than it is. I can write my own config file format without too much difficulty but it seems a shame if everyone ends up doing this. (The one you linked to seemed to have wider ambitions than logging and its format seemed even more unwieldy. Curly braces in Python?!) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6136] Make logging configuration files easier to use
New submission from Geoffrey Bache gjb1...@users.sourceforge.net: Recently tried to use the logging configuration file format as understood by logging.config.fileConfig() and found it very unwieldy for normal usage. I feel it needs to scale down better. Some thoughts: a) It creates handlers whether they're needed or not. This means you cannot leave the handler sections present in your configuration file and just disable and enable the logger by changing the level, or your application will open the files/sockets etc. anyway, whether the loggers are enabled or not. This is bordering on being a bug rather than just an annoyance... b) There is a lot of unnecessary cruft. For example it should be possible to eliminate the [loggers], [handlers] and [formatters] sections. I gather they're there due to a limitation of ConfigParser but I assume this is historical as I can see no good reason for it now. Also, entries should default sensibly, e.g. qualname should not be treated as vital but should default to the name in the section header. c) I'd also suggest providing a newer, non-back-compatible format alongside the existing one that was less wordy for normal use. Get rid of the separate handlers and formatters and make each logger have a section of its own containing all handling and formatting information: most users aren't going to want to think about these things as separate entities and in any case there is the hierarchical mechanism to prevent too much copying. In fact, I'd suggest extending the basicConfig idea to be able to call it on individual loggers, and build a new format around that, where each section is read and a logger created with the contents passed as keyword arguments to basicConfig. I might have time to do some of this myself but I want to be sure people think it's a good idea before investing time in it. -- components: Extension Modules messages: 88467 nosy: gjb1002 severity: normal status: open title: Make logging configuration files easier to use type: feature request ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue957650] Fix for bugs relating to ntpath.expanduser()
Geoffrey Bache gjb1...@users.sourceforge.net added the comment: Just ran into this myself, and would agree with Christian's comments. On my system, my home directory is a mounted network drive, hence H:\. It was a bit of a surprise when os.path.expanduser(~fred) returned H:\\fred... This seems broken to me. It's surely better to have reliable functions that either work or return the path unchanged, than ones that guess and are wrong some of the time. At least in the above case it should be possible to add a special case. Will this be considered for Python 2.7 now? I'd suggest opening a new bug or reopening this one if so. -- nosy: +gjb1002 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue957650 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue957650] Fix for bugs relating to ntpath.expanduser()
Geoffrey Bache gjb1...@users.sourceforge.net added the comment: In fact, wouldn't a very simple fix be to not return paths that don't exist? That would probably catch 90% of the cases. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue957650 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1748960] os.path.expandvars: expand string without modifying the environment
Geoffrey Bache gjb1...@users.sourceforge.net added the comment: Thanks, didn't know about that feature. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1748960 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue648658] xmlrpc can't do proxied HTTP
Geoffrey Bache [EMAIL PROTECTED] added the comment: Well, strictly speaking, yes. It just feels like a rather major omission (when Python can do xmlrpc and handle proxies you hope it will handle the combination). Desperate doesn't really have a timeline, strangely enough :) I know I will be talking to bazaar and bugzilla behind a proxy in the mid-term future and it would be very useful to use an officially sanctioned solution (though of course I will try the attached file if there isn't one at the time). I see Python 2.6 is nearing release candidates : is this likely to be included or will we have to wait for 2.7 now? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue648658 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3210] subprocess.Popen does not release process handles if process cannot be started
Geoffrey Bache [EMAIL PROTECTED] added the comment: A note on workarounds, the garbage collector seems to release the handles when the function exits, so removing the file in a caller works for me. However Tim's proposed fix with os.close didn't do so. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3210] subprocess.Popen does not release process handles if process cannot be started
New submission from Geoffrey Bache [EMAIL PROTECTED]: Run the following code on Windows: import subprocess, os file = open(filename, w) try: proc = subprocess.Popen(nosuchprogram, stdout=file) except OSError: file.close() os.remove(filename) This produces the following exception: Traceback (most recent call last): File C:\processown.py, line 10, in module os.remove(filename) WindowsError: [Error 32] The process cannot access the file because it is being used by another process: 'filename' When the CreateProcess call fails the subprocess module should release the handles it provides. Unfortunately it seems to raise WindowsError before doing this. See also http://groups.google.com/group/comp.lang.python/browse_thread/thread/6157691ea3324779/6274e9f8bc8a71ee?hl=en#6274e9f8bc8a71ee As Tim Golden points out, this can be worked around by doing os.close(file.fileno()) at the end instead of file.close() -- components: Extension Modules messages: 68787 nosy: gjb1002 severity: normal status: open title: subprocess.Popen does not release process handles if process cannot be started type: behavior versions: Python 2.5 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3210 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3137] Python doesn't handle SIGINT well if it arrives during interpreter startup
New submission from Geoffrey Bache [EMAIL PROTECTED]: If a python script receives SIGINT while the interpreter is starting up, it's possible to get the message import site failed; use -v for traceback printed on standard error and for execution to proceed. It also seems to be possible to get half-imported modules and for the script to fail later claiming that something like os.getenv doesn't exist. If I do as instructed and use -v for traceback I get something like: 'import site' failed; traceback: Traceback (most recent call last): File /usr/lib/python2.4/site.py, line 61, in ? import os File /usr/lib/python2.4/os.py, line 683, in ? import copy_reg as _copy_reg File /usr/lib/python2.4/copy_reg.py, line 5, in ? KeyboardInterrupt I imagine there exists some code like try: import site except: sys.stderr.write(import site failed; use -v for traceback\n) though I couldn't find any. If so, it seems clear that KeyboardInterrupt needs to be re-raised, or Python's special handler for SIGINT installed rather later. -- components: Interpreter Core messages: 68392 nosy: gjb1002 severity: normal status: open title: Python doesn't handle SIGINT well if it arrives during interpreter startup versions: Python 2.5 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3137 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
