[issue2470] Need fixer for dl (removed) - ctypes module
New submission from Neal Norwitz [EMAIL PROTECTED]: r61837 removed the dl module. It needs a 2to3 fixer written to use ctypes. -- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) messages: 64394 nosy: collinwinter, nnorwitz priority: critical severity: normal status: open title: Need fixer for dl (removed) - ctypes module __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2470 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2471] imp.get_magic() should return bytes, not bytearray
New submission from Brett Cannon [EMAIL PROTECTED]: The magic cookie as returned by imp.get_magic() should be of the bytes type, not bytearray as the magic cookie will not ever change during the execution of the interpreter. -- components: Extension Modules messages: 64395 nosy: brett.cannon priority: normal severity: normal status: open title: imp.get_magic() should return bytes, not bytearray type: behavior versions: Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2471 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1162363] Heap class for heapq module
Raymond Hettinger [EMAIL PROTECTED] added the comment: Overall, I'm not in favor of the patch or the basic idea. The heapq module is somewhat usable as-is with apps typically inserting tuples linking a priority level and a record. Also, the attached code is not yet mature, nor does it evidence compelling use cases or user demand. This may make a good ASPN recipe but would be premature for inclusion in the standard library. One quick comment on the API, it would be better to have just a key function and to drop the cmp function as Python itself has done throughout the language in Py3.0. Recommend rejecting the feature request, leaving the module as clean as possible. If the code is published separately (perhaps as an ASPN recipe or third-party module), it may yet mature and gather a fan club. -- resolution: - rejected status: open - closed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1162363 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1904] Add key argument to heapq functions
Raymond Hettinger [EMAIL PROTECTED] added the comment: Rejecting the key-function patch in favor of the current typical approach of heapifying tuples that link a priority level with individual records. I've been a heavy user of the module and one of its principal maintainers. To date, I've seen very little need for key- function argument. Use cases aside, there is another design issue in that the key-function approach doesn't work well with the heap functions on regular lists. Successive calls to heap functions will of necessity call the key- function multiple times for any given element. This contrasts with sort () where the whole purpose of the key function was to encapsulate the decorate-sort-undecorate pattern which was desirable because the key- function called exactly once per element. -- resolution: - rejected status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1904 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2460] Ellipsis not copyable
Raymond Hettinger [EMAIL PROTECTED] added the comment: Thanks for the patch. Applied in r61841. -- resolution: - accepted status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2460 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1038909] pydoc method documentation lookup enhancement
Andy Harrington [EMAIL PROTECTED] added the comment: Alexander, I have no idea why your patch languished. On the one hand I might have skipped this if I realized that before. On the other hand, I did add something extra, and I might not have had an open mind if I had looked at yours. Plus, maybe I got it moving! :) You made a good enhancement suggestion. From the continuing interchange below, it looks like two minds are better than either one. Comments on your comments on mine: 2. Hm, good point. I do not think pydoc should substitute for PyLint, but it only makes sense to copy the docs from the same type of function in an ancestor class: static, class or method, though you are right it need not matter whether the ancestor is built-in or not, though the assumption is made that you know about built-in docs - you might only note the inheritance. And again, as I did it, finding any ancestor of the wrong type should stop the search. There is one inconsistency with static method docs: If we are given a class, and have a static method in it, we can search the inheritance chain for docs. Neither of us does this at present, though it looks easier to add through my access point in docroutine. On the other hand, if the top-level request is just to document a static function, there is a problem, since you cannot identify the class it comes from, not having an im_class attribute, and hence the documentation may look different from when it was just a part of the documentation for the class. I do not see this as a reason to skip the inheritance chain for a static method when given it's class: better information in - better information out. 3. I agree people should use doc strings not comments, but if everyone did that, our versions would have the same effect. The only difference is if the coder *does* want to use comments for some reason. Hence the question is: do you want to document what people do or push them to code the way you want? Ping apparently chose the former approach, so I am not suggesting changing it. Thanks, Andy _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1038909 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1462228] custom comparison function for bisect module
Raymond Hettinger [EMAIL PROTECTED] added the comment: Thank you for the patch but must close due the rejection of the original RFE. -- resolution: - rejected status: open - closed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1462228 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1451588] bisect should support a custom comparison function
Raymond Hettinger [EMAIL PROTECTED] added the comment: Sorry, am closing this RFE because its not the best way to use the bisect tools. The cmp function is going away in Py3.0 in favor of key functions. Yet, even those do not play nicely with bisect because the function results are not stored between successive calls to bisect. Accordingly, it is almost always better to arrange the records in a decorated style so that they can be compared directly and not through a cmp or key function. The one misgiving is that is feels odd to be able to sort by a key function but not maintain that order or search that ordering using the bisect module. Yet, there is a simple reason for the difference -- sort () works on the entire sequence at once and can take advantage of the single key function call per element -- in contrast, the bisect functions have finer granularity and the cmp/key functions no longer make sense. -- nosy: +rhettinger resolution: - rejected status: open - closed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1451588 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1619060] bisect on presorted list
Raymond Hettinger [EMAIL PROTECTED] added the comment: Thanks for the thoughtful reply. Am going to close for the reasons agreed by most of the respondants. See additional explanation in the closing of issue 1451588 . That all-at-once action of sort() allows it to take advantage of a single key-function call per element; in contrast, successive calls to bisect functions are more finely grained and the key-function doesn't make sense anymore. -- resolution: - rejected status: open - closed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1619060 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2126] BaseHTTPServer.py fails long POST from IE
Raymond Hettinger [EMAIL PROTECTED] added the comment: Unassigning. I don't have more thoughts on this one. -- assignee: rhettinger - __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2126 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2172] Add doc-string to UserDict and DictMixin
Raymond Hettinger [EMAIL PROTECTED] added the comment: I'm not sure the class docstring approach is suitable for a mixin. It seems fine to me that pydoc strips the commentary on the mixin as a standalone class; instead it appropriately focuses on the client class that uses the mixin as part of its API. FWIW, all of this code goes away in Py3.0. -- resolution: - rejected status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2172 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2354] cmp argument to list.sort()/sorted() should raise a Py3K warning
Changes by Raymond Hettinger [EMAIL PROTECTED]: -- status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2354 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1569291] Speed-up in array_repeat()
Raymond Hettinger [EMAIL PROTECTED] added the comment: This one is easy if someone wants to take a crack at it. -- keywords: +easy -patch _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1569291 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue762920] API Functions for PyArray
Raymond Hettinger [EMAIL PROTECTED] added the comment: Raising priority as a reminder to myself or anyone who wants to apply, test, and document. -- priority: normal - high Tracker [EMAIL PROTECTED] http://bugs.python.org/issue762920 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2470] Need fixer for dl (removed) - ctypes module
Martin v. Löwis [EMAIL PROTECTED] added the comment: Is it possible to write one? I'm skeptical. -- nosy: +loewis __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2470 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1700821] audioop module - request to add a note
Georg Brandl [EMAIL PROTECTED] added the comment: Fixed in r61842. -- resolution: accepted - fixed status: open - closed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1700821 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1251748] compiler package: global a; a=5
Armin Rigo [EMAIL PROTECTED] added the comment: Sorry, I don't think many PyPy coders care about microoptimizations in the bytecode. To be honest we've stopped worrying about the stdlib compiler package because no one seemed to care. I'm closing the present patch as incomplete and outdated; if someone is interested in reviving the stdlib compiler package, my offer to extract from PyPy an up-to-date diff for the compiler package still stands. -- resolution: - wont fix status: open - closed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1251748 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2472] Fixed block ordering code in compiler.pyassem
New submission from Antoine Pitrou [EMAIL PROTECTED]: This is a rewrite of the block ordering code in the compiler package (specifically, the flowgraph part). The previous code was littered with self-admitted hacks, fixups and XXX :-) They are all removed and replaced with a clean ``order_blocks`` function which does the right thing from the start. The patch also replaces a wrong startBlock() with a nextBlock() in compiler.pycodegen (startBlock can only be used when the previous block does an unconditional transfer to another one, otherwise the two adjacent blocks may not be emitted in order). I've run test_compiler a couple of times, and tested execution of several functions. They all run fine. Unless someone has specific reasons to reject the patch, I'd recommend applying it even if not many people use the compiler package :) I needed the fixes for my work on #2459. -- components: Library (Lib) files: fixcompiler.patch keywords: patch messages: 64410 nosy: pitrou severity: normal status: open title: Fixed block ordering code in compiler.pyassem type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file9838/fixcompiler.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2472 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2472] Fixed block ordering code in compiler.pyassem
Changes by Antoine Pitrou [EMAIL PROTECTED]: Removed file: http://bugs.python.org/file9838/fixcompiler.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2472 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2472] Fixed block ordering code in compiler.pyassem
Changes by Antoine Pitrou [EMAIL PROTECTED]: Added file: http://bugs.python.org/file9839/fixcompiler.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2472 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1251748] compiler package: global a; a=5
Antoine Pitrou [EMAIL PROTECTED] added the comment: Armin, this is not about micro-optimizations per se, but about fixing some parts of the compiler package. To make it easier, I've created a separate entry for the fixing part in #2472 :) This was the first time I was using the compiler package and I think it can be useful in order to experiment with bytecode ideas (of course you probably prefer to do that with PyPy). That's why I tried to fix what was failing for me. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1251748 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2472] Fixed block ordering code in compiler.pyassem
Antoine Pitrou [EMAIL PROTECTED] added the comment: By enabling TEST_ALL I've just run ``test_compiler.CompilerTest.testCompileLibrary`` against the whole stdlib, and there were no errors. It's a good sign :-) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2472 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2240] setitimer, getitimer wrapper
Martin v. Löwis [EMAIL PROTECTED] added the comment: Thanks for the patch. Committed as r61847 and r61848 -- resolution: - accepted status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2240 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2250] rlcompleter raises Exception on bad input
Lorenz Quack [EMAIL PROTECTED] added the comment: I have no idea what or who NAS is but comments are always welcome :) concerning the documentation: I´ve never done it before but there is a first time for everything, right? I´m currently on vacation so I won´t look into it for at least another 2 weeks. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2250 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2473] logging.LogRecord should know how to handle dict-like args
New submission from Will Maier [EMAIL PROTECTED]: In (at least) Python 2.5.2, logging.logRecord provides a very useful facility to interpolate formatted strings. This feature expands an *args sequence; if that sequence has only one element and that element is a dictionary, LogRecord uses the dictionary to interpolate keyword formatted strings. This is incredibly useful, but the LogRecord __init__() method includes a rather arbitrary type-specific check that prevents users from passing dict-like objects to the log methods: logging.__init__.py:204..238 class LogRecord: [...] def __init__(self, name, level, pathname, lineno, msg, args, exc_info, func=None): [...] if args and (len(args) == 1) and args[0] and (type(args[0]) == types.DictType): args = args[0] This restriction prevents the user from passing eg a subclass of UserDict.DictMixin. Now, __init__() clearly does need to do _some_ checking of args, but it would be nice if that checking accepted dict-like objects. I haven't come up with a good way to do this myself yet, but I figured I'd submit the request now. Thanks! -- components: Library (Lib) messages: 64415 nosy: wcmaier severity: normal status: open title: logging.LogRecord should know how to handle dict-like args type: feature request versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2473 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1202] zlib.crc32() and adler32() return value
Michael Becker [EMAIL PROTECTED] added the comment: In case it isn't obvious the work around for pre 3.0 to get the right sum is something like: x=zlib.adler32(str) if x 0: x=(long(x) + 4294967296L) # 2^32, long may or may not be needed here -- nosy: +mbecker __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1202 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2470] Need fixer for dl (removed) - ctypes module
Collin Winter [EMAIL PROTECTED] added the comment: Can you list the mapping you'd like to see? I've never used dl or ctypes, so I'm not immediately sure how to port from one to the other. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2470 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1733184] slice type is unhashable
L. Peter Deutsch [EMAIL PROTECTED] added the comment: Having now read messages 63380 and 63384, I agree with them: I would have withdrawn my proposal if it hadn't gotten rejected first. I do have a use case, but the workaround is pretty easy. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1733184 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2470] Need fixer for dl (removed) - ctypes module
Martin v. Löwis [EMAIL PROTECTED] added the comment: In the simplest case, convert import dl libc = dl.open(libc.so.6) iconv = libc.call(iconv_open, ISO-8859-1, ISO-8859-2) print(iconv) to import ctypes libc = ctypes.CDLL(libc.so.6) iconv = libc.iconv_open(ISO-8859-1, ISO-8859-2) print(iconv) Notice that dlobject.call has up to 11 arguments, the first one being the function name. Thomas, is it the case that all calls to dl.call can be converted to a ctypes call without parameter conversion? dl supports these parameter types: - byte string, passed as char* - integers, passed as int - None, passed as NULL -- nosy: +theller __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2470 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1731717] race condition in subprocess module
Tom Culliton [EMAIL PROTECTED] added the comment: I'm not sure what the POSIX standards say on this (and MS-Windows may go it's own contrary way), but for most real systems the PID is a running count (generally 32 bit or larger today) which would have to cycle all the way around to repeat. It's actually done this way on purpose to provide the longest possible time between IDs getting reused. I suspect that having it cycle and reuse an ID isn't an issue in practice, and keeping a list of results leaves you with the problem of figuring out which PID 55367 they're talking about... Not to mention that if you're leaving child process results unchecked for long enough for the PID counter to cycle, there are other problems with the application. ;-) Gregory P. Smith wrote: Gregory P. Smith [EMAIL PROTECTED] added the comment: Basically it's OK to collect all the child exit codes if you record the results and return them when requested. This would mean that waitpid and the like would have to check a cached list of PIDs and exit statuses before actually waiting. note that this would still have problems. PIDs are recycled by the OS so as soon as you've waited on one and the process dies, the OS is free to launch a new process using it. If the new process happens to be another one of ours launched by subprocess that would be a problem. Make the cached map of pids - exit codes be a map of pids - [list of exit codes] instead? _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1731717 _ _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1731717 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1731717] race condition in subprocess module
Jean-Paul Calderone [EMAIL PROTECTED] added the comment: Which system uses a 32 bit PID? Not Linux, or FreeBSD, or OS X - they all use 16 bit PIDs. -- nosy: +exarkun _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1731717 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1202] zlib.crc32() and adler32() return value
Gregory P. Smith [EMAIL PROTECTED] added the comment: The workaround I prefer to use is: x = zlib.adler32(mystr) 0xL __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1202 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2172] Add doc-string to UserDict and DictMixin
Alexander Belopolsky [EMAIL PROTECTED] added the comment:
On Mon, Mar 24, 2008 at 4:53 AM, Raymond Hettinger
[EMAIL PROTECTED] wrote:
I'm not sure the class docstring approach is suitable for a mixin. It
seems fine to me that pydoc strips the commentary on the mixin as a
standalone class;
My main point was not that some commentary was stripped by
pydoc, but that the commentary that is not stripped is misleading:
The beginning of pydoc UserDict.DictMixin is rendered as follows:
UserDict.DictMixin = class DictMixin
| Methods defined here:
|
| __cmp__(self, other)
|
| __contains__(self, key)
|
| __iter__(self)
| # second level definitions support higher levels
|
| __len__(self)
..
What does second level definitions support higher levels comment
below __iter__ means? Does it apply to all methods above or all
methods below but above the third level ... comment or just to
__iter__? All of these plausible interpretations are wrong.
Furthemore, pydoc UserDict is rendered as follows:
NAME
UserDict - A more or less complete user-defined wrapper around
dictionary objects.
FILE
/bnv/home/abelopolsky/Work/python-svn/trunk/Lib/UserDict.py
CLASSES
DictMixin
UserDict
IterableUserDict
class DictMixin
...
Which is not helpful at all in understanding of what DictMixin is for.
instead it appropriately focuses on the client class
that uses the mixin as part of its API.
I assume you refer to UserDict as the client class. In what sense
does it use mixin as part of its API? In 2.x, UserDict does not
derive from DictMixin. To the contrary, UserDict and DictMixin
present quite different APIs to the users of derived classes. For
example, overriding __getitem__ does not affect has_key,
__contains__ or iter* methods of the class deriving from UserDict,
which is different from the way DictMixin descendants work.
.. that's why I selected version 2.6 when I submitted this issue. :-)
However, AFAICT, not all this code goes away, just UserDict is
moved to collections and DictMixin functionality is replaced with
ABCs. This is a welcome change because with abstract
methods the classes become self-documenting, but I have to
note that UserDict will behave differently in 3.0: the following
code print 1 in 2.x and 42 in 3.0:
class X(UserDict):
def __getitem__(self, _):
return 42
print(X(a=1).pop('a'))
This change should probably be reflected in the docs
somewhere.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2172
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1731717] race condition in subprocess module
Tom Culliton [EMAIL PROTECTED] added the comment: AIX, HP-UX, Solaris, 64 bit Linux, ... Even in the Linux x86 header files there's a mix of int and short. The last time I had to do the math on how long it would take the PID to cycle was probably on an AIX box and it was a very long time. Jean-Paul Calderone wrote: Jean-Paul Calderone [EMAIL PROTECTED] added the comment: Which system uses a 32 bit PID? Not Linux, or FreeBSD, or OS X - they all use 16 bit PIDs. -- nosy: +exarkun _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1731717 _ _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1731717 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1733184] slice type is unhashable
Alexander Belopolsky [EMAIL PROTECTED] added the comment: I hate to flip-flop like this, but please consider my new arguments at issue2268. In short, slices being unhashable prevents storing them in the code object's const dictionary and thus prevents optimizing code involving const slices. Unless I hear strong opposition from the bug tracker forum, I plan to present some ideas on python-dev on how to make slices hashable while not enabling d[:]. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1733184 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1731717] race condition in subprocess module
Jean-Paul Calderone [EMAIL PROTECTED] added the comment: PIDs cycle quite frequently. You must be thinking of something else. Even 64 bit Linux has a maximum PID of 2 ** 15 - 1. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1731717 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2474] fset not working
New submission from Ryan Sturmer [EMAIL PROTECTED]:
Using the attached module, There's an asymmetry between fget and fset in
my properties. fget works fine, but fset isn't getting called. I'm
fairly sure I'm creating the property correctly. Try the following code:
a = EWAssayIntParam('myparam', 4)
a.value
a.value = 10
a.value
I've seen this same issue flare up and die out several times in the
tracker, is this a commonly made programming mistake rather than a bug?
--
components: None
files: params.py
messages: 64427
nosy: ryansturmer
severity: normal
status: open
title: fset not working
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file9840/params.py
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2474
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1731717] race condition in subprocess module
Gregory P. Smith [EMAIL PROTECTED] added the comment: fwiw, I see pids cycle in a reasonable amount of time on modern production linux systems today. its a fact of life, we should deal with it. :) _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1731717 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1569291] Speed-up in array_repeat()
Alexander Belopolsky [EMAIL PROTECTED] added the comment:
Looking at stringobject.c:1034:
i = 0;
if (i size) {
Py_MEMCPY(op-ob_sval, a-ob_sval, Py_SIZE(a));
i = Py_SIZE(a);
}
while (i size) {
j = (i = size-i) ? i : size-i;
Py_MEMCPY(op-ob_sval+i, op-ob_sval, j);
i += j;
}
return (PyObject *) op;
Do I miss something or the first condition if (i size) is
a fancy way to check for size 0?
Wouldn't it be clearer to write
if (size == 0)
return (PyObject *) op;
Py_MEMCPY(op-ob_sval, a-ob_sval, Py_SIZE(a));
i = Py_SIZE(a);
..
--
nosy: +belopolsky
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1569291
_
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2474] fset not working
Paul Pogonyshev [EMAIL PROTECTED] added the comment: This is caused by EWAssayParam being an old-style class. Dunno if it is a bug in Python or not. -- nosy: +_doublep __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2474 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2474] fset not working
Georg Brandl [EMAIL PROTECTED] added the comment: It's not a bug in Python. Properties, being descriptors, only work fully with new-style classes. -- nosy: +georg.brandl resolution: - wont fix status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2474 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2271] msi installs to the incorrect location (C drive)
Ross [EMAIL PROTECTED] added the comment: Checking Progress. This is a big of a show-stopper as it prevents me from using a number of python dependent packages. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2271 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1569291] Speed-up in array_repeat()
Alexander Belopolsky [EMAIL PROTECTED] added the comment: Attached patch (issue1569291.diff) reimplements the optimization by following Objects/stringobject.c logic as Raymond suggested. I see two remaining issues which in my view should be addressed separately: 1. There is no check for overflow after the multiplication computing the size of the resulting array. Note that while newarrayobject checks that size*itemsize does not overflow internally, there is no such check for Py_SIZE(a) * n. A decision needs to be made whether Overflow or NoMemory error should be raised because currently string_repeat and newarrayobject treat overflow differently. 2. See msg64429 above. I think both string and (patched) array codes can be simplified. -- keywords: +patch type: - performance Added file: http://bugs.python.org/file9841/issue1569291.diff _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1569291 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2271] msi installs to the incorrect location (C drive)
Martin v. Löwis [EMAIL PROTECTED] added the comment: No progress so far; may not proceed at all during April (IOW, I haven't even looked at the log file yet). Contributions are welcome. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2271 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1569291] Speed-up in array_repeat()
Alexander Belopolsky [EMAIL PROTECTED] added the comment: I forgot to mention that I added a unit test to cover the special case of repeating a single-byte array. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1569291 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2271] msi installs to the incorrect location (C drive)
Martin v. Löwis [EMAIL PROTECTED] added the comment: As a further follow-up, I have now looked at the log file, and the problematic lines are MSI (s) (DC:40) [10:44:39:425]: Ignoring disallowed property TARGETDIR MSI (s) (DC:40) [10:44:39:425]: Ignoring disallowed property DLLDIR Try setting SecureCustomProperties (through orca.exe) and report whether that helps. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2271 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1736190] asyncore/asynchat patches
Giampaolo Rodola' [EMAIL PROTECTED] added the comment: Are there news about this issue? -- nosy: +gvanrossum _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1736190 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2271] msi installs to the incorrect location (C drive)
Ross [EMAIL PROTECTED] added the comment: using Orca, I modified the .msi file and python now appears to be working. I made the following change: Property - SecureCustomProperty Changed value from REMOVEOLDSNAPSHOT;REMOVEOLDVERSION to REMOVEOLDSNAPSHOT;REMOVEOLDVERSION;TARGETDIR;DLLDIR Running the modified .msi file resulted in Python being installed in C:\Python25 (the correct location). Currently, the installation appears to work properly. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2271 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2475] Popen.poll always returns None
New submission from Josh Cogliati [EMAIL PROTECTED]: I was trying to use subprocess to run multiple processes, and then wait until one was finished. I was using poll() to do this and created the following test case: #BEGIN import subprocess,os procs = [subprocess.Popen([sleep,str(x)]) for x in range(1,11)] while len(procs) 0: os.wait() print [(p.pid,p.poll()) for p in procs] procs = [p for p in procs if p.poll() == None] #END I would have expected that as this program was run, it would remove the processes that finished from the procs list, but instead, they stay in it and I got the following output: #Output [(7426, None), (7427, None), (7428, None), (7429, None), (7430, None), (7431, None), (7432, None), (7433, None), (7434, None), (7435, None)] #above line repeats 8 more times [(7426, None), (7427, None), (7428, None), (7429, None), (7430, None), (7431, None), (7432, None), (7433, None), (7434, None), (7435, None)] Traceback (most recent call last): File ./test_poll.py, line 9, in module os.wait() OSError: [Errno 10] No child processes #End output Basically, even for finished processes, poll returns None. Version of python used: Python 2.5.1 (r251:54863, Oct 30 2007, 13:45:26) [GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2 Relevant documentation in Library reference manual 17.1.2 poll( ) ... Returns returncode attribute. ... A None value indicates that the process hasn't terminated yet. -- messages: 64439 nosy: jjcogliati severity: normal status: open title: Popen.poll always returns None type: behavior versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2475 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2469] Fix build error in unicodeobject.c UCS4
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: Oops, I made this error while correcting #2469. Thanks for catching it! committed as r61853. There is no buildbot configured with UCS4... -- nosy: +amaury.forgeotdarc resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2469 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1477] UnicodeDecodeError that cannot be caught in narrow unicode builds
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: backported to 2.5 branch as r61854 -- status: pending - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1477 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2471] imp.get_magic() should return bytes, not bytearray
Benjamin Peterson [EMAIL PROTECTED] added the comment: Attaching patch... -- keywords: +patch nosy: +benjamin.peterson Added file: http://bugs.python.org/file9842/get_magic_bytes.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2471 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1054434] automatic XMLRPC boxcarring via multicall for xmlrpclib
Ralf Schmitt [EMAIL PROTECTED] added the comment: this issue is about the threaded one. I think it should be rejected. It does not work: ~/ python2.5 xmlrpclib_multicall.py [EMAIL PROTECTED] failed 1 Traceback (most recent call last): File xmlrpclib_multicall.py, line 12, in module from log.StdLogger import logger ImportError: No module named log.StdLogger and the code uses lot's of unused imports. -- nosy: +schmir _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1054434 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue730938] Python bsddb docs need update
Jesús Cea Avión [EMAIL PROTECTED] added the comment: Done in the pybssdb module (the external one, not the included in python distribution). Online docs available at http://www.argo.es/~jcea/programacion/pybsddb_doc/ The source rst files should be directly usable in the stock 2.6 documentation. Tracker [EMAIL PROTECTED] http://bugs.python.org/issue730938 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2159] dbmmodule inquiry function is performance prohibitive
Changes by Jesús Cea Avión [EMAIL PROTECTED]: -- nosy: +jcea __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2159 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2413] os.strerror does not check for out of range argument
Ralf Schmitt [EMAIL PROTECTED] added the comment: The current behaviour (without your patch) seems ok to me. I just wanted to point out that the patch in its current form could break on some platforms. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2413 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2159] dbmmodule inquiry function is performance prohibitive
Changes by Benjamin Peterson [EMAIL PROTECTED]: -- type: resource usage - performance __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2159 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2159] dbmmodule inquiry function is performance prohibitive
Jesús Cea Avión [EMAIL PROTECTED] added the comment: I think that -1 is a sanity check. If the count is updated in the database, but it is not transactional (or there are bugs, or the DB is updated by a not up-to-date library, and so on), the cached counter and the real data can diverge. Anybody using Berkeley DB related databases knows that length is costly. By good reasons, actually :-). Checking for empty databases should be fast, nevertheless (just iterate over the first item in the database). We could simply define a __nonzero__() method for that. That would solve the if issue. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2159 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2375] PYTHON3PATH environment variable to supersede PYTHONPATH for multi-Python environments
Ralf Schmitt [EMAIL PROTECTED] added the comment: I once even had the need for a PYTHON24PATH or PYTHON25PATH. (And I think this would be the right approach, i.e. even using the minor version number). However, now I am a happy user of virtualenv, and I do not even have to set PYTHONPATH anymore... -- nosy: +schmir __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2375 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2375] PYTHON3PATH environment variable to supersede PYTHONPATH for multi-Python environments
Ralf Schmitt [EMAIL PROTECTED] added the comment: c modules cannot be used when the minor version number changes. If I remember correctly c modules where the problem for me, when I ran python 2.4 and 2.5 in parallel. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2375 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2375] PYTHON3PATH environment variable to supersede PYTHONPATH for multi-Python environments
Changes by Benjamin Peterson [EMAIL PROTECTED]: -- type: - feature request __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2375 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1251748] compiler package: global a; a=5
Neil Schemenauer [EMAIL PROTECTED] added the comment: On Sun, Mar 23, 2008 at 04:17:12PM +, Antoine Pitrou wrote: Armin, if you still care about the compiler package, could you (or some other pypy coder) take a look at #2459? As part of the patch, it rewrites the flow graph block ordering algorithm in a cleaner way (IMHO). I'm interested to update the compiler package but I'm short of time at the moment. If you want to assign bugs and patches to me, I will try to get to them. Neil _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1251748 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2250] rlcompleter raises Exception on bad input
Neil Schemenauer [EMAIL PROTECTED] added the comment: On Thu, Mar 20, 2008 at 08:49:32PM +, Sean Reifschneider wrote: Is a straightforward patch, but I'd like NAS to comment on the change in behavior. Probably would also need a documentation change, are you up for doing that Lorenz? I doubt that people are relying on complete() to raise NameError or Attribute error. I think it would be okay just to trap them and not change the docs. A note in NEWS should be good enough. Neil __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2250 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue762920] API Functions for PyArray
Alexander Belopolsky [EMAIL PROTECTED] added the comment: I think this issue is largely superseded by PEP 3118 http://www.python.org/dev/peps/pep-3118, which is being backported to 2.6 (see issue2393). AFAICT, the only functionality not available from the new buffer protocol is the ability to create new array objects from C code, but this patch does not provide such functionality either. Travis, can you weigh in on this? I think it may be useful to expose newarrayobject() through some C API compatible with PEP 3118, but otherwise this proposal seems redundant. -- nosy: +belopolsky, teoliphant Tracker [EMAIL PROTECTED] http://bugs.python.org/issue762920 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2467] gc.DEBUG_STATS reports invalid elapsed times
Neil Schemenauer [EMAIL PROTECTED] added the comment: The original code is pretty icky. I'm attaching a patch that improves it, IMO. Before the elapsed time was only shown if garbage was found. I think it should always be shown if DEBUG_STATS is set. -- nosy: +nas Added file: http://bugs.python.org/file9843/gc_timestat.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2467 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2448] namedtuple breaks refleak tests
Alexander Belopolsky [EMAIL PROTECTED] added the comment: This is a duplicate of issue2223. (See msg63244.) -- nosy: +belopolsky __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2448 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2447] Python 2.6 refleak test issues
Alexander Belopolsky [EMAIL PROTECTED] added the comment: This is a duplicate of issue2223. -- nosy: +belopolsky __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2447 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
