[issue9784] _msi.c warnings under 64-bit Windows
Martin v. Löwis mar...@v.loewis.de added the comment: Martin Lowis do you mean API when you type SDK? When I said SDK examples, then I really meant examples as published in the SDK, not examples as published in the API (and the SDK documentation, in turn, is published on msdn). But yes, the SDK examples use Win32 directly. If I understand what you are saying, you would rather use the Win32 API instead of the CRT API? Correct. It may interest you to know that _open calls CreateFile internally, _read calls ReadFile, _write calls WriteFile, _lseek calls SetFilePointer, and _close calls CloseHandle. I'm fully aware of that. We could rewrite the functions using the Win32 API directly but we don’t have to. I realize this is a Windows only module but the use of the CRT API is more familiar to a majority of the Python developers (I would guess). I have the long-term plan to eliminate all CRT usage from Python on Windows. In this case, there is a straight-forward opportunity to do so. Nothing is really gained from using the CRT (as the cabinet SDK is probably even less familiar to Python developers than CreateFile), plus using the CRT causes compiler warnings, as Microsoft clearly intends that these routines would be implemented using the Windows API directly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9784 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9940] Strange error reporting with with statement
Georg Brandl ge...@python.org added the comment: At least not without losing generality, and we don't like that. -- nosy: +georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9940 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9941] Unify trace and profile interfaces
Georg Brandl ge...@python.org added the comment: Sounds good to me. -- nosy: +georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9941 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9942] Allow memory sections to be OS MERGEABLE
Georg Brandl ge...@python.org added the comment: My first thought is Why is the reference counter stored with the object itself? Because if you move the reference counter out of the object, you a) add another indirection and b) depending on how you implement it require a certain amount of memory more per object. It's far from obvious that the possible benefits are worth this, and needs to be tested carefully, which nobody has done yet. -- nosy: +georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9942 ___ ___ 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
[issue9942] Allow memory sections to be OS MERGEABLE
Antoine Pitrou pit...@free.fr added the comment: Answering the question as best I can: I don't know how the reference counter is implemented in CPython, but if it's just a field in a struct, then madvise could be sent the memory location starting with the byte immediately following the reference counter Well, first, this would only work for large objects. Must objects in Python are quite small individually, unless you have very large (unicode or binary) strings, or very big integers. Second, madvise() works at the page granularity (4096 bytes on most system), and it will be very likely this will include the reference count for the current object. Third, MADV_MERGEABLE will only be efficient if you have actual duplications of whole memory pages (and, practically, if you have enough of them to make a real difference). Why do you think you might have such duplication in your workload? -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9942 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6706] asyncore's accept() is broken
Giampaolo Rodola' g.rod...@gmail.com added the comment: Patch in attachment makes accept() return None in case no connection takes place and modifies the doc to make this very clear, also providing an example on how an asyncore-based server should be properly set-up . -- versions: +Python 2.6 Added file: http://bugs.python.org/file19005/accept.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6706 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6706] asyncore's accept() is broken
Antoine Pitrou pit...@free.fr added the comment: EAGAIN can be raised too. I never experienced this error condition myself in pyftpdlib From the accept() man page: EAGAIN or EWOULDBLOCK The socket is marked nonblocking and no connections are present to be accepted. POSIX.1-2001 allows either error to be returned for this case, and does not require these constants to have the same value, so a portable application should check for both possibilities. The resulting address can be None, which means that the connection didn't take place. The only way this can happen is if the accept() system call returned 0 in addrlen, which sounds rather strange. I'm not convinced hiding operating system bugs is a good idea. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6706 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9931] test_ttk_guionly hangs on XP5
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +pmoore type: - crash ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9931 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8445] buildbot: test_ttk_guionly failures (test_traversal, test_tab_identifiers, test_identify, test_heading_callback)
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +db3l ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8445 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8423] tiger buildbot: test_pep277 failures
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +db3l ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8423 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6706] asyncore's accept() is broken
Giampaolo Rodola' g.rod...@gmail.com added the comment: I'm not convinced hiding operating system bugs is a good idea. Do you propose to let the error raise then? The point of frameworks such as asyncore and twisted is to hide all system-specific errors as much as possible and provide a portable interface across all platforms. AFAICT, the whole point of this issue is that there should be only one way for an asyncore-based server to accept an incoming connection, possibly avoiding the user to deal with low-level details such as catching EWOULDBLOCK/ECONNABORTED/... in his application, and looking for accept() returning None is one possibility. As I said, in a better designed framework the user shouldn't be supposed to call accept() at all, but that's how asyncore is designed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6706 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6706] asyncore's accept() is broken
Antoine Pitrou pit...@free.fr added the comment: The point of frameworks such as asyncore and twisted is to hide all system-specific errors as much as possible and provide a portable interface across all platforms. As long as these errors are reasonably explainable. If a strange error only occurs when running nmap on an OS X server, then it might be useful for the user to know that the OS X server isn't able to service all connections properly due to a bug in the operating system. AFAICT, the whole point of this issue is that there should be only one way for an asyncore-based server to accept an incoming connection, possibly avoiding the user to deal with low-level details such as catching EWOULDBLOCK/ECONNABORTED/... I am talking specifically about the address being None (i.e., a (sock, None) tuple is successfully returned). EWOULDBLOCK and ECONNABORTED are documented error conditions for accept(), but returning 0 in addrlen is not. As I said, in a better designed framework the user shouldn't be supposed to call accept() at all, but that's how asyncore is designed. Perhaps it's time to add an alternative handle_accepted(sock, addr) which relieves the user from calling accept() :)) Then, perhaps self.accept() shouldn't filter any errors at all, but the default handle_accept() would silence them before calling handle_accepted(). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6706 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6706] asyncore's accept() is broken
Giampaolo Rodola' g.rod...@gmail.com added the comment: As long as these errors are reasonably explainable. If a strange error only occurs when running nmap on an OS X server, then it might be useful for the user to know that the OS X server isn't able to service all connections properly due to a bug in the operating system. It might be useful to find whether this is tracked somewhere. For the record, here (comment #10) is a code which should reproduce this problem: https://bugs.launchpad.net/zodb/+bug/135108 As for what asyncore should in this case I think it should theoretically be safe for accept() to return (sock, None). What usually happen after that is that the socket object is passed to another dispatcher subclass (the handler) and the connection gets automatically closed once recv() or send() get called on the next async-loop. Perhaps it's time to add an alternative handle_accepted(sock, addr) which relieves the user from calling accept() :)) This sounds like a very good idea for 3.2. As for 3.1 and 2.7 (2.6?) I think it can be useful to suppress EWOULDBLOCK/ECONNABORTED and return None instead. Considering accept() can *already* return None it wouldn't break backward compatibility. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6706 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9784] _msi.c warnings under 64-bit Windows
Jon Anglin jang...@fortresgrand.com added the comment: I have the long-term plan to eliminate all CRT usage from Python on Windows. In this case, there is a straight-forward opportunity to do so. Oh, OK. If that is the plan then I am on board. I will re-code the patch using the Win32 API directly. It may interest you to know that _open calls CreateFile internally, I'm fully aware of that. I meant no disrespect, I just didn't know if you were a Windows guy. If you asked me what system call _open (or others) calls on Linux or Mac, I would have no clue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9784 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9783] _elementtree.c warnings under 64-bit Windows
Jon Anglin jang...@fortresgrand.com added the comment:
Martin is correct about this patch.
In cases where we really can't propagate Py_ssize_t to (e.g.
XML_Parse), we need to check for an int overflow, and raise
an exception if it does overflow.
Is this an appropriate approach?
int
PySize_AsInt(Py_ssize_t value)
{
if (value (Py_ssize_t)INT_MAX || value (Py_ssize_t)INT_MIN) {
PyErr_SetString(PyExc_OverflowError,
Size value can not be represented as an integer);
}
return (int)value;
}
I would only define this when sizeof(Py_ssize_t) sizeof(int) of course. In
other cases it would be a macro that just evaluates to value.
I would most likely need an unsigned version as well (although not for this
particular issue).
This code could be used in many C modules. Where in the Python code base should
such functions be placed?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9783
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6634] sys.exit() called from threads other than the main one: undocumented behaviour
Jan-Philip Gehrcke jgehr...@gmail.com added the comment: Sorry for the delay. Before suggesting a doc change to correct/complete the description of the *current* situation, we actually should consider changing this situation. I think this is reasonable and I feel encouraged by Gabriel Genellina: I see no reason for sys.exit(msg) NOT to write to stderr inside a child thread. This patch enables printing to stderr from child threads and clones the behavior of `sys.exit(arg)` called from the main thread: # PATCH BEGIN --- C:/Python27/Lib/threading.pySat Apr 10 18:55:48 2010 +++ C:/python_sys_exit_issue/threading.pySat Sep 25 14:50:24 2010 @@ -531,6 +531,15 @@ except SystemExit: if __debug__: self._note(%s.__bootstrap(): raised SystemExit, self) +# Now get and handle the exit code, given by the user via +# the second expression after `raise` or via the argument of +# sys.exit(). +code = self.__exc_info()[1].code +# Ignore None and integer exit code. Print any other object +# to stderr as it is the behavior of sys.exit(arg) called +# from the main thread. +if code is not None and not isinstance(code, int): +_sys.stderr.write(%s\n % code) except: if __debug__: self._note(%s.__bootstrap(): unhandled exception, self) # PATCH END A script with different testcases including output is attached. What do you think? All the best, Jan-Philip Gehrcke -- Added file: http://bugs.python.org/file19006/thread_sys_exit_test.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6634 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9945] Improper locking in logging
New submission from Armin Ronacher armin.ronac...@active-4.com: I found a a useless lock acquiring in the 27 maintenance branch in logging and a missing one as well: Logger.removeHandler() locks around a handler lock, however the code executed in this lock is not depending on anything of that lock. However there is a race condition when two pieces of code try to remove the same handler at the same time because between the if and the remove() no locking takes place. I would recommend this instead (and also add locking to the addHandler): def addHandler(self, hdlr): Add the specified handler to this logger. _acquireLock() try: if hdlr not in self.handlers: self.handlers.append(hdlr) finally: _releaseLock() def removeHandler(self, hdlr): Remove the specified handler from this logger. _acquireLock() try: if hdlr in self.handlers: self.handlers.remove(hdlr) finally: _releaseLock() I suppose in 3.x there might be something similar. -- assignee: vinay.sajip components: Library (Lib) messages: 117364 nosy: aronacher, vinay.sajip priority: normal severity: normal status: open title: Improper locking in logging type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9945 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9944] Typo in doc for itertools recipe of consume
Georg Brandl ge...@python.org added the comment: Thanks, fixed in r85008. -- nosy: +georg.brandl resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9944 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9896] Introspectable range objects
Antoine Pitrou pit...@free.fr added the comment: One other thought. If there is a perceived need, I would rather an alternate approach that unifies a language a bit by letting range() expose its arguments as a slice and modify its input to accept a slice. This sounds like an obscure complication to me. A range is not a slice and I don't see the point of trying to bridge both concepts. It is even more YAGNI than the original request. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9896 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1865] Document bytes alias for 2.7
Georg Brandl ge...@python.org added the comment: Fixed in r85010. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1865 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9946] lock use in logging
New submission from Georg Brandl ge...@python.org: From logging.Logger: def removeHandler(self, hdlr): Remove the specified handler from this logger. if hdlr in self.handlers: hdlr.acquire() try: self.handlers.remove(hdlr) finally: hdlr.release() I don't see what the use is for locking the handler. The only shared resource that is accessed is self.handlers, which is not locked by the handler lock. -- assignee: vinay.sajip components: Library (Lib) keywords: easy messages: 117368 nosy: georg.brandl, vinay.sajip priority: normal severity: normal status: open title: lock use in logging type: behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9946] lock use in logging
Georg Brandl ge...@python.org added the comment: Dupe of #9945, sorry. -- resolution: - duplicate status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9946 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9947] Weird locking in logging config system
New submission from Armin Ronacher armin.ronac...@active-4.com: Another case of improper locking in logging. The stopListening() method of the logging config acquires the logging lock, but it doesn't do it early enough. In order for this function to be thread safe it would have to lock before the if. Currently that lock used is useless because it locks assigning to a single attribute assignment and a global assignment that is never checked to existence besides the stopListening() function. The attached patch proposes moving the lock before the if to make it threadsafe, but in all fairness sake that method is probably never executed from more than one thread. -- assignee: vinay.sajip files: logging-config-threadsafety.patch keywords: patch messages: 117370 nosy: aronacher, vinay.sajip priority: normal severity: normal status: open title: Weird locking in logging config system versions: Python 2.7 Added file: http://bugs.python.org/file19007/logging-config-threadsafety.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9947 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9942] Allow memory sections to be OS MERGEABLE
Kevin Hunter hunt...@earlham.edu added the comment: Well, first, this would only work for large objects. [...] Why do you think you might have such duplication in your workload? Some of the projects with which I work involve multiple manipulations of large datasets. Often, we use Python scripts as first and third stages in a pipeline. For example, in one current workflow, we read a large file into a cStringIO object, do a few manipulations with it, pass it off to a second process, and await the results. Meanwhile, the large file is sitting around in memory because we need to do more manipulations after we get results back from the second application in the pipeline. Graphically: Python Script A-External App-Python Script A read large data process data more manipulations Within a single process, I don't see any gain to be had. However, in this one use-case, this pipeline is running concurrently with a number of copies with slightly different command line parameters. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9942 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9942] Allow memory sections to be OS MERGEABLE
Antoine Pitrou pit...@free.fr added the comment: Well, first, this would only work for large objects. [...] Why do you think you might have such duplication in your workload? Some of the projects with which I work involve multiple manipulations of large datasets. Often, we use Python scripts as first and third stages in a pipeline. For example, in one current workflow, we read a large file into a cStringIO object, do a few manipulations with it, pass it off to a second process, and await the results. Why do you read it into a cStringIO? A cStringIO has the same interface as a file, so you could simply operate on the file directly. (you could also try mmap if you need quick random access to various portions of the file) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9942 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9948] findCaller is slow and loses case information on Windows
New submission from Armin Ronacher armin.ronac...@active-4.com: findCaller() on loses case information on the files on Windows and has in general a really bad performance. The attached patch does not depend on filename comparisions and instead compares the object identity of the caller's global namespace against the one from the logging module. -- assignee: vinay.sajip components: Library (Lib) files: find-caller.patch keywords: patch messages: 117373 nosy: aronacher, vinay.sajip priority: normal severity: normal status: open title: findCaller is slow and loses case information on Windows versions: Python 2.7 Added file: http://bugs.python.org/file19008/find-caller.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9948 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9948] findCaller is slow and loses case information on Windows
Changes by Armin Ronacher armin.ronac...@active-4.com: Added file: http://bugs.python.org/file19009/find-caller.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9948 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9948] findCaller is slow and loses case information on Windows
Changes by Armin Ronacher armin.ronac...@active-4.com: Removed file: http://bugs.python.org/file19008/find-caller.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9948 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9949] os.path.realpath on Windows does not follow symbolic links
New submission from Daniel Stutzbach dan...@stutzbachenterprises.com: In Lib/ntpath.py: # realpath is a no-op on systems without islink support realpath = abspath However, Windows Vista and newer support symbolic links and other Python methods support them. (noticed this through source code inspection; haven't actually tested it) -- components: Library (Lib) messages: 117374 nosy: brian.curtin, eric.smith, jaraco, stutzbach priority: normal severity: normal stage: needs patch status: open title: os.path.realpath on Windows does not follow symbolic links type: behavior versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9949 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1703592] have a way to ignore nonexisting locales in locale.setlocale
Barry A. Warsaw ba...@python.org added the comment: Certainly at a minimum, the docs should describe the exception and workaround instead of just: setlocale() is not thread safe on most systems. Applications typically start with a call of import locale locale.setlocale(locale.LC_ALL, '') This sets the locale for all categories to the user’s default setting (typically specified in the LANG environment variable). If the locale is not changed thereafter, using multithreading should not cause problems. +0 for a new function in Python 3.2. For Python 2.7 though, we can't really add that new function or change the behavior of setlocale() so I'm not sure what the right thing to do is. A documentation change is probably as good as it's going to get for Python 2. -- nosy: +barry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1703592 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5412] extend configparser to support mapping access(__*item__)
Changes by Łukasz Langa luk...@langa.pl: Removed file: http://bugs.python.org/file18760/issue5412.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5412 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5412] extend configparser to support mapping access(__*item__)
Łukasz Langa luk...@langa.pl added the comment: Patch updated: * uses collections because they are built into the executable for 3.2 * uses itertools for the same reasons * in the end doesn't use weakrefs since after recent commits (Raymond removed __del__ from OrderedDict) the reference cycle problem went away on its own Still needs docs but I didn't manage to make sensible edits last night (the train I took from Hannover arrived 80 minutes later). -- Added file: http://bugs.python.org/file19010/issue5412.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5412 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9360] nntplib cleanup
Antoine Pitrou pit...@free.fr added the comment: And here is a patch integrating doc fixes and updates. -- Added file: http://bugs.python.org/file19011/nntplib_cleanup7.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9360 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6634] sys.exit() called from threads other than the main one: undocumented behaviour
Terry J. Reedy tjre...@udel.edu added the comment: I do not use threads so I cannot comment on the technical issue. Since the current behavior is not clearly a bug, I do not think a change would or know that it should be applied to 2.7/3.1. So I suggest that you both 1. Suggest a doc patch on this issue. That should not controversial and might be quickly applied. 2. Submit a separate feature request issue to change behavior in 3.2 or beyond. You could request that the change be backported to 2.7 and try to make a case for doing so. Unless you can quickly write a tested patch, such a change in unlikely to make it into 3.2 anyway. And even then, no guarantee. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6634 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8831] recv and recvfrom on UDP socket do not return/throw exception after a close()
Charles-Francois Natali neolo...@free.fr added the comment: Are you sure of that? I don't see how Python behaviour would be different to a the same program written in C. Could you write a short example written in C to prove that? I also found this surprising, so I wroke a quick C program to test this (see attached C code), and as expected, calling close() from the main thread _doesn't_ result in recv() returning (and the socket still shows up in a netstat -A inet -a). Furthermore, closing a socket still in use by another thread is probably quite questionable, and close(2) man page makes it clear: It is probably unwise to close file descriptors while they may be in use by system calls in other threads in the same process. Since a file descriptor may be re-used, there are some obscure race conditions that may cause unintended side effects. So I'd suggest to close this issue. -- nosy: +neologix Added file: http://bugs.python.org/file19012/test_socket.c ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8445] buildbot: test_ttk_guionly failures (test_traversal, test_tab_identifiers, test_identify, test_heading_callback)
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +gpolo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8445 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9562] Slightly misleading wording in documentation of dict.update
Sandro Tosi sandro.t...@gmail.com added the comment: Hello, does the attached patch contains the expected wording? Thanks, Sandro -- nosy: +sandro.tosi Added file: http://bugs.python.org/file19013/issue9562-py3k.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9562 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9562] Slightly misleading wording in documentation of dict.update
Georg Brandl ge...@python.org added the comment: Committed original suggestion as r85011. -- nosy: +georg.brandl resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9562 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9945] Improper locking in logging
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: Fix checked into py3k and release27-maint branches, r85012. Thanks! -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9945 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9947] Weird locking in logging config system
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: Fix checked into py3k and release27-maint, r85013. Thanks! -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9947 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6293] Have regrtest.py echo back sys.flags
Sandro Tosi sandro.t...@gmail.com added the comment:
Hello,
I've changed the initial patch to add a CLI option ('-g/--sysflags', '-f' is
already used) to enable the echoing of sys.flags.
If you need some other changes, just ping me.
Regards,
Sandro
--
nosy: +sandro.tosi
Added file: http://bugs.python.org/file19014/issue6293-py3k.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6293
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9950] socket.sendall() crash when receiving a signal
New submission from Antoine Pitrou pit...@free.fr: This was introduced by r74426 which addressed issue1628205. socket.sendall() calls PyErr_CheckSignals() (and potentially returns to the caller) without having the GIL. import socket c, s = socket.socketpair() s.sendall(bx*(100 * 1024**2)) ^C^CFatal Python error: PyThreadState_Get: no current thread -- components: Library (Lib) messages: 117385 nosy: gregory.p.smith, pitrou priority: normal severity: normal status: open title: socket.sendall() crash when receiving a signal type: crash versions: Python 2.7, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9950 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9890] Visual C++ Runtime Library Error is there a fix?
Gösta Huldt ghu...@gmail.com added the comment: I get the same error, but only when IDLE is run with the -n flag. In my case, the error occurs when attempting to switch back to the IDLE gui after executing a script that opens a graphics window (using the vtk module). This is with Python 2.6. I have Visual C++ 2010 Express installed, along with a previous install of the 2008 redistributable. The following message is returned to the prompt: Fatal Python error: PyEval_RestoreThread: NULL tstate This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. -- nosy: +Gösta.Huldt versions: +Python 2.6 -Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9890 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9950] socket.sendall() crash when receiving a signal
Antoine Pitrou pit...@free.fr added the comment:
The fix is very simple, but perhaps a test should be added.
diff -r af0d7b32d6ce Modules/socketmodule.c
--- a/Modules/socketmodule.cFri Sep 24 20:03:12 2010 +0200
+++ b/Modules/socketmodule.cSat Sep 25 21:09:58 2010 +0200
@@ -2581,8 +2581,8 @@ sock_sendall(PySocketSockObject *s, PyOb
return select_error();
}
-Py_BEGIN_ALLOW_THREADS
do {
+Py_BEGIN_ALLOW_THREADS
timeout = internal_select(s, 1);
n = -1;
if (timeout)
@@ -2592,6 +2592,7 @@ sock_sendall(PySocketSockObject *s, PyOb
#else
n = send(s-sock_fd, buf, len, flags);
#endif
+Py_END_ALLOW_THREADS
if (n 0) {
#ifdef EINTR
/* We must handle EINTR here as there is no way for
@@ -2610,7 +2611,6 @@ sock_sendall(PySocketSockObject *s, PyOb
buf += n;
len -= n;
} while (len 0);
-Py_END_ALLOW_THREADS
PyBuffer_Release(pbuf);
if (timeout == 1) {
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9950
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9950] socket.sendall() crash when receiving a signal
Antoine Pitrou pit...@free.fr added the comment: Actually, the patch is enough to suppress the crash, but sendall() behaviour is buggy in another way: EINTR may be received as part of the select() call (on sockets with a timeout), in which case the loop will be exited early instead of retrying, losing track of the number of bytes written (something which the original patch aimed to avoid). For example: def handler(*args): print (args) ... signal.signal(signal.SIGALRM, handler) 0 c, s = socket.socketpair() s.settimeout(60.0) signal.alarm(1); s.sendall(bx * (100 * 1024**2)) 0 (14, frame object at 0x2b8f220) Traceback (most recent call last): File stdin, line 1, in module socket.error: [Errno 4] Interrupted system call -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9950 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9950] socket.sendall() crash when receiving a signal
Antoine Pitrou pit...@free.fr added the comment: Oh, and an additional bug is that send() can return a successful partial write when it was actually interrupted by a signal. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9950 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9950] socket.sendall() crash when receiving a signal
Antoine Pitrou pit...@free.fr added the comment: Here is a patch fixing the aforementioned issues, and with tests. -- keywords: +patch nosy: +exarkun Added file: http://bugs.python.org/file19015/sendallinterrupt.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9950 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7110] Output test failures on stderr in regrtest.py
Sandro Tosi sandro.t...@gmail.com added the comment: Hello, the attached patch seems to do the trick, at least on what I can verify here on my machine. I'd appreciate a bit more of test from more experienced developers, just to catch corner cases I didn't see. Regards, Sandro -- keywords: +patch nosy: +sandro.tosi Added file: http://bugs.python.org/file19016/issue7110-py3k.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7110 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9628] runtests.sh -x doesn't work with more than two args (sed error)
Sandro Tosi sandro.t...@gmail.com added the comment: Hello, the patch applies cleanly against up-to-date py3k branch: is there anything else to do before committing it? Regards, Sandro -- nosy: +sandro.tosi ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9628 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8831] recv and recvfrom on UDP socket do not return/throw exception after a close()
Martin v. Löwis mar...@v.loewis.de added the comment: Closing, as suggested by neologix -- resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9910] Add Py_SetPath API for embedding python
Antoine Pitrou pit...@free.fr added the comment: The patch compiles fine under Linux, but please don't use tabs for indentation of C files. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9910 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9923] mailcap module may not work on non-POSIX platforms if MAILCAPS env variable is set
Gregory Nofi crackityjones200...@yahoo.com added the comment: I'm also creating a test for mailcap (Issue 6484), which is how I found this bug. I'll have an update to that test submitted soon once I implement r.david.murray's helpful suggestions. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9923 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9926] Wrapped TestSuite subclass does not get __call__ executed
Michael Foord mich...@voidspace.org.uk added the comment: The attached patch fixes the issue (I think...) by tagging the result object. It removes the need for _wrapped_result altogether. The test fails without the change to TestSuite and passes with the change. This could be applied to 2.7-maint and py3k. Uhm... the patch needs a better name for the TestResult tag attribute. -- keywords: +patch Added file: http://bugs.python.org/file19017/suite.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9926 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9951] introduce bytes.hex method
New submission from Arnon Yaari wiggi...@gmail.com: Following up on these discussions: http://psf.upfronthosting.co.za/roundup/tracker/issue3532 http://www.gossamer-threads.com/lists/python/dev/863892 I'm submitting a patch to add bytes.hex method in accordance to PEP 358. The code was taken from binascii so it should be tested. Also added bytearray.hex and fixed the documentation and testing. There are additional things to discuss, for example: * multiple and different implementations of tohex\fromhex - in binascii, sha1module, bytes, bytearray... * binascii's functions which perform the same thing, but those functions and the rest of binascii's functions receive and return wrong types. I would fix this but it breaks compatibility. -- components: Interpreter Core files: bytes.hex.diff keywords: patch messages: 117397 nosy: wiggin15 priority: normal severity: normal status: open title: introduce bytes.hex method type: feature request versions: Python 3.2 Added file: http://bugs.python.org/file19018/bytes.hex.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9951 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9910] Add Py_SetPath API for embedding python
Kristján Valur Jónsson krist...@ccpgames.com added the comment: Sorry, my mistake, I work in a mixed environment. If there are no objections, I´ll submit this (with fixed whitespace) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9910 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8445] buildbot: test_ttk_guionly failures (test_traversal, test_tab_identifiers, test_identify, test_heading_callback)
Guilherme Polo ggp...@gmail.com added the comment: Hi there, I believe I've fixed most of these errors. But I couldn't replicate the last error on the first message, so I guessed what could be the problem. Could you try the patch and see how it works for you ? (Thanks for the nosy addition, I rarely check for bugs as you may know). -- keywords: +patch Added file: http://bugs.python.org/file19019/issue8445.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8445 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9942] Allow memory sections to be OS MERGEABLE
Kevin Hunter hunt...@earlham.edu added the comment: Why do you read it into a cStringIO? A cStringIO has the same interface as a file, so you could simply operate on the file directly. In that particular case, because it isn't actually a file. That workflow was my attempt at simplification to illustrate a point. I think the point is moot however, as I've gotten what I needed from this feature request/discussion. Not one, but three Python developers seem opposed to the idea, or at least skeptical. That's enough to tell me that my first-order supposition that Python objects could be MERGEABLE is not on target. Cheers. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9942 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9815] assertRaises as a context manager keeps tracebacks and frames alive
Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp added the comment: Note that the original issue (test_tarfile failures on the Windows buildbots) now seems fixed thanks to the various tarfile and test_tarfile improvements. Yes, thanks. :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9815 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9289] Skip test_long_key(test_winreg) on win2k + py2.x
Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp added the comment: I found workaround for this. (Probably self.deletetree is more handful, though) -- versions: -Python 2.6 Added file: http://bugs.python.org/file19020/py27_fix_test_winreg_long_key.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9289 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9937] _winreg.EnumValue causes MemoryError
Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp added the comment: Sorry, my patch didn't pass test_dynamic_key(test_winreg). (Apologize for not testing on unit test) RegEnumValueA and RegQueryInfoKeyA always returned 0 for required data size if target is HKEY_PERFORMANCE_DATA. The possible fixes I can imagine are... 1. Use GetCPInfo() to get MaxCharSize. http://msdn.microsoft.com/en-us/library/dd317780%28v=VS.85%29.aspx We can get a large value enough to store the key name in ANSI by The length in Unicode * MaxCharSize. 2. Use RegEnumValueW and convert result via WideCharToMultiByte I'll attach the patch with option 1. -- Added file: http://bugs.python.org/file19021/py27_fix_winreg_EnumValue_op1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9937 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9937] _winreg.EnumValue causes MemoryError
Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp added the comment: I shall create unit test later. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9937 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
