[issue2604] doctest.DocTestCase fails when run repeatedly
James Henstridge [EMAIL PROTECTED] added the comment: Is repeating a test with the same TestCase instance ever safe? It'd be better to create a new instance and run that. If any of the variables in test.globs are changed by the test (e.g. appending to a list), then rerunning the test will not necessarily give the same result. While the zope change allows tests that have immutable globals or don't change their globals to function, it also lets other tests almost work, and could lead to new bugs that are difficult to track down. -- nosy: +jamesh __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2604 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2604] doctest.DocTestCase fails when run repeatedly
Piet Delport [EMAIL PROTECTED] added the comment: If any of the variables in test.globs are changed by the test (e.g. appending to a list), then rerunning the test will not necessarily give the same result. This is true, but modifying the globals such that subsequent runs of the same test can break equally affects subsequent runs of any other tests that use that module: such a test is already broken (unsafe to run with other tests) to begin with, independent of the DocTestCase.tearDown issue. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2604 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2607] why is (default)dict so slow on tuples???
Andreas Eisele [EMAIL PROTECTED] added the comment: Great, that really solves my problem. Thank you so much, Amaury! As you say, the problem is unrelated to dicts, and I observe it also when including the tuples to a set or keeping them in lists. Perhaps your GC thresholds would be better default values than what is currently in force. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2607 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2614] Console UnicodeDecodeError s once more
New submission from anatoly techtonik [EMAIL PROTECTED]:
Python debugging under console is a PITA, because it has a bad habit to
fail with UnicodeEncodeError in case of unknown encoding in output. It
quickly turns into a headache when inspecting methods like in the
following example running under windows:
import active_directory
users = active_directory.search (objectCategory='Person',
objectClass='User')
u = users.next()
u = users.next()
u = users.next()
u.dump()
LDAP://CN=LыхъёрэфЁ,CN=Users,DC=dom,DC=com
{
Traceback (most recent call last):
File stdin, line 1, in module
File build\bdist.win32\egg\active_directory.py, line 495, in dump
File C:\Python25\lib\codecs.py, line 303, in write
data, consumed = self.encode(object, self.errors)
File C:\Python25\lib\encodings\cp1251.py, line 12, in en
code
return codecs.charmap_encode(input,errors,encoding_table)
UnicodeDecodeError: 'ascii' codec can't decode byte 0x84 in position 8:
ordinal
not in range(128)
Will this be fixed in Py3k to allow range(255) in case of unknown
encoding? Or will there be a new wrapper function - some
rawhexprint(...) that will temporary change sys.output encoding for the
time arguments are executed and process out of range symbols in output
stream according to its embedded rules (i.e. converting to hex
representaton). Another function can be supplied to write raw bytes to
console as-is. Raw write is preferable as it gives the possibility to
redirect output to a file and inspect it later.
These encoding issues in my POV is the stumbling block that makes
scripting in Python 2.x harder for non-english users and hampers overall
Python adoption. Is this going change in Py3k?
--
components: Unicode, Windows
messages: 65342
nosy: techtonik
severity: normal
status: open
title: Console UnicodeDecodeError s once more
versions: Python 2.5, Python 3.0
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2614
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2604] doctest.DocTestCase fails when run repeatedly
James Henstridge [EMAIL PROTECTED] added the comment:
If I create a test case with a command like:
test = DocFileSuite('foo.txt', globs={'somelist': [42]})
The doctest isn't doing anything wrong if it modifies somelist.
Furthermore, Glyph has said he thinks the current --until-failure
behaviour in trial is a mistake: http://glyf.livejournal.com/72505.html
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2604
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2604] doctest.DocTestCase fails when run repeatedly
Piet Delport [EMAIL PROTECTED] added the comment: Well, whether that code is wrong depends on whether your project policy wants repeatable tests or not. A repeatable and arguably more idiomatic way of writing that example is to give DocFileSuite a setUp function which initializes any special globals required by the test. In any case, DocTestCase allowing non-repeatable tests (which i don't think are common) is no reason to disallow repeatable tests, which e.g. at least Zope considers important enough to motivate fixing this issue. (Zope is also the source of the code being fixed, if i'm not mistaken.) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2604 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2607] why is (default)dict so slow on tuples???
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: The slowdown is because of the garbage collector, which has more and more objects to traverse (the tuples). If I add import gc; gc.disable() at the beginning of your script, it runs much faster, and the timings look linear. Martin's sample is not affected, because there are very few deallocations, and the gc collection is not triggered. Disabling the gc may not be a good idea in a real application; I suggest you to play with the gc.set_threshold function and set larger values, at least while building the dictionary. (700, 1000, 10) seems to yield good results. -- nosy: +amaury.forgeotdarc __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2607 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2613] inconsistency with bare * in parameter list
New submission from Mark Summerfield [EMAIL PROTECTED]: A bare * in a parameter list behaves differently depending on what follows it: Py30a4: def f(*, a=1, b=2): return 1 def g(*, **kwargs): return 1 SyntaxError: named arguments must follow bare * (pyshell#10, line 1) I don't know if this is a bug or not but thought it worth querying. This case does not seem to be mentioned in PEP 3102. -- components: Interpreter Core messages: 65340 nosy: mark severity: normal status: open title: inconsistency with bare * in parameter list type: behavior versions: Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2613 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2615] xml.dom.minidom documentation consistency and update
New submission from Jeroen Ruigrok van der Werven [EMAIL PROTECTED]: xml.dom.minidom details three methods: writexml(), toxml(), toprettyxml(). Only one, toxml(), showed the optional encoding argument. In the documentation for writexml() the encoding argument is explained, but toprettyxml() refers to toxml() for the details, which are not present there. -- assignee: georg.brandl components: Documentation files: minidom.diff keywords: patch messages: 65347 nosy: asmodai, georg.brandl severity: normal status: open title: xml.dom.minidom documentation consistency and update type: feature request versions: Python 2.6 Added file: http://bugs.python.org/file10004/minidom.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2615 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1738] filecmp.dircmp does exact match only
Michael Amrhein [EMAIL PROTECTED] added the comment: I've implemented an enhanced version of this feature by adding a keyword 'match' to the constructor of class 'dircmp'. It defaults to function 'fnmatch' imported from module 'fnmatch'. This allows to exclude directories and/or files by using patterns like '*.tmp'. By giving a different function it's also possible to use more elaborated patterns, for example, based on regular expressions. Attached patch includes updates of documentation and test cases. -- nosy: +mamrhein versions: +Python 2.6 Added file: http://bugs.python.org/file10005/wildcard.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1738 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2604] doctest.DocTestCase fails when run repeatedly
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: FWIW, the python testsuite needs repeatable tests, when running in reference leaks mode. See also r62100, where a DocTestSuite construction had to be moved into the repeated function. -- nosy: +amaury.forgeotdarc __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2604 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2612] file.tell() returns Long usually, Int if subclassed
Benjamin Peterson [EMAIL PROTECTED] added the comment: The documentation is still not very good about documenting the differences between new and old style classes. Perhaps this is something which could go under the __len__ entry in Special Method Names. -- nosy: +georg.brandl __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2612 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2610] string representation of range
Brad Miller [EMAIL PROTECTED] added the comment: Here is a new patch file. This one contains the modifications to rangeobject.c as well as test_range.py I think this is everything. If there is something else I need to do please let me know. I looked to see if there was any documentation I could or should change for this but did not find any. Thanks again for your help. Added file: http://bugs.python.org/file10006/range_str_comb.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2610 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1738] filecmp.dircmp does exact match only
Alexander Belopolsky [EMAIL PROTECTED] added the comment: +1 on adding the match argument. Can you comment on how one would implement the old behavior? I would guess match=lambda x,y: x in y, which is not that bad, but maybe that should be the default and those who need pattern matching should use match=fnmatch. On the patch itself, please don't change default arguments from None to lists or function. There is a subtle difference between the two forms. For example, in your code if someone overrides filecmp.fnmatch before calling dircmp, old fnmatch will still be used. If you do match=None in finction declaration and match is None check in the function body, then the new overridden value will be used in the above scenario. -- nosy: +belopolsky __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1738 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Sérgio Durigan Júnior [EMAIL PROTECTED] added the comment: Hi Martin, Actually, I know that you can use CC to do it, but IMHO that's not the correct approach. I understand too you concern about adding @CFLAGS@, but I think the user should be able to define his/her own CFLAGS, and this is not implemented yet. Do you agree with that? Regards. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1628484 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2610] string representation of range
Alexander Belopolsky [EMAIL PROTECTED] added the comment: -1 I don't think 0, 1, ..., 9 is much clearer than range(0, 10). The only problem students may have is that 10 not in range(0, 10), but this can be learned very quickly. The .. repr breaks x == eval(repr(x)) invariant which is actually important in some of my code. Furthermore, the proposed .. representation suggests that the range object contains the integers, which is not true. While eval/repr round-tripping may not be important for the majority of applications, it is a nice feature for any interactive work including education. Finally, I think introducing students to list(range(..))/tuple(range(..)) idioms early is a good thing. The sooner they learn that list/tuple are real containers while ranges, dict key/values etc. are not the better. -- nosy: +belopolsky __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2610 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2610] string representation of range
Brad Miller [EMAIL PROTECTED] added the comment: The patch does not change the behavior of repr. It modifies the behavior of str. I agree that learning list/tuple sooner is better, but students who have never written a line of code before can only absorb so much information, this little patch allows them to print(range(100,0,-1)) and get a much better intuition about what is happening. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2610 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2610] string representation of range
Alexander Belopolsky [EMAIL PROTECTED] added the comment: I did not realize that the proposed patch only affects str and not repr. Some of may previous arguments against it do not hold in this case, but I am still -1. If you introduce range before list, it will be hard to explain why lists are printed in valid python syntax while ranges are not. What do you do with ranges in your first classes? Maybe you can introduce it as a part of the looping construct and make students think of for i in range(10) as an equivalent of C's for(i = 0; i 10; i++)? Also [i for i in range(10)] [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] can be demonstrated early without explaining the mechanics of list comprehensions. I would expect most students being able to guess what for i in range(10): does and half of the students being able to guess what [i for i in range(10)] means. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2610 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2616] ctypes.pointer(), ctypes.POINTER() speedup
New submission from Thomas Heller [EMAIL PROTECTED]: This patch implements the POINTER() and the pointer() function in C; giving a speedup of roughly a factor of 2. -- assignee: theller components: ctypes files: ctypes-pointer.diff keywords: patch, patch messages: 65356 nosy: theller severity: normal status: open title: ctypes.pointer(), ctypes.POINTER() speedup type: performance versions: Python 2.6 Added file: http://bugs.python.org/file10007/ctypes-pointer.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2616 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2610] string representation of range
Brad Miller [EMAIL PROTECTED] added the comment: Our use of range in the first few classes is exactly for iteration purposes, but I do not like students to have to have too many mysteries. So I always have liked to show that range(10) simply produces a sequence of integers. In Python 3.0 range returns a mysterious iteration object. No thanks. My proposal was to provide a more user friendly implementation of the str method for this new range object that would allow the user to see the sequence. I like Python because it is so easy to start up a shell and poke around and see what things are. I have no problem, introducing list(range(10)) in week 3 when I start talking about lists, and I like list comprehensions of that purpose too. Again, what I do not like is that things that used to be very easy for students to get a conceptual handle on are now more difficult in 3.0. - range is one example the dict_keys and dict_values objects are another example. dict_keys et. al. are much easier to deal with since I've already covered lists and the list() function by the time I get there. BTW, I think we must have very different teaching styles as I would never introduce something as mysterious as list(_) on the first day of class. I'd be happy to continue our discussion of teaching philosophy but I doubt that this is the right forum. Brad __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2610 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1738] filecmp.dircmp does exact match only
Michael Amrhein [EMAIL PROTECTED] added the comment: Ok, I've set default arguments (back) to None. Revised patch attached. Defaulting the match function to fnmatch doesn't change the behavior in the normal case, i.e. when regular file / directory names are used, like in the default value of ignore. It behaves different in two cases: a) A string given in ignore contains wildcard character(s): In this case this parameter would have no effect in the previous implementation, because the string would not match any file / directory name exactly. In the changed implementation all files / directories matching the pattern would be ignored. If the wildcard(s) were included by intent, this is what probably was intended; if they were included by mistake, both version do not behave as intended. b) File system is case-insensitive: In this case the changed implementation will ignore files / directories which the previous version did not ignore because of a case mismatch. But, on such a file system this is what one would normally expect, I think. So, in both cases, I feel the changed behavior is acceptable. Or did I miss something? Added file: http://bugs.python.org/file10008/add_match_func.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1738 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2559] atom sorting error when building ctypes
Thomas Heller [EMAIL PROTECTED] added the comment: I see this also, on Leopard x86. The linker error is not printed on Tiger PPC. At least, the ctypes test suite does work ok so it may be that it can be ignored. Googling for this error, I find that it may be related to linker changes that Apple has made. One suggestion I found was to link with ld_classic instead of ld; another was to pass the -dynamic flag instead of -bundle. However, I do not known how this can be done in setup.py. The libffi sources in Python svn were copied from the PyObjC sources; maybe Ronald has a clue? -- nosy: +ronaldoussoren title: atom sorting error when buiding ctypes - atom sorting error when building ctypes __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2559 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1738] filecmp.dircmp does exact match only
Alexander Belopolsky [EMAIL PROTECTED] added the comment: As you are working on this, please consider changing self.hide+self.ignore in phase0 to chain(self.hide, self.ignore) where chain should be imported from itertools. There is no need to create the combined list (twice!) and not accepting arbitrary iterables for hide and ignore seems to be against the zen of python. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1738 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2610] string representation of range
Brad Miller [EMAIL PROTECTED] added the comment: Clearly neither Alexander nor I are going to get the other to come around to our point of view. Thats fine, I think we can disagree here, and I can adapt and change my class either way. My question is how does this get resolved. When I posted this idea to python-dev Guido suggested an approach. Nobody else expressed an opinion so after waiting a few days I took Guido's suggestion and implemented a patch. Now there are objections. Other than some mild frustration at having invested a fair amount of time in producing my first python patch, I am also in the middle of editing a textbook that will come out this fall. my intention is to have this book be 3.0 compatible. So it would be nice for me to have some clarity on the direction this will go. Thanks, Brad __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2610 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2617] Patch to emit -J is reserved for Jython on -J arg
New submission from Frank Wierzbicki [EMAIL PROTECTED]: This patch adds the message -J is reserved for Jython if that arg is attempted. See http://mail.python.org/pipermail/python-dev/2008-April/078564.html For support from BDFL. -- components: Interpreter Core files: argdashjay.diff keywords: patch messages: 65365 nosy: fwierzbicki severity: normal status: open title: Patch to emit -J is reserved for Jython on -J arg type: feature request versions: Python 2.6 Added file: http://bugs.python.org/file10009/argdashjay.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2617 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2610] string representation of range
Alexander Belopolsky [EMAIL PROTECTED] added the comment:
On Fri, Apr 11, 2008 at 2:45 PM, Brad Miller [EMAIL PROTECTED] wrote:
..
My question is how does this get resolved. When I posted this idea to
python-dev Guido suggested an approach. Nobody else expressed an opinion
so after waiting a few days I took Guido's suggestion and implemented a
patch. Now there are objections.
My -1 vote is not a veto by any means. It us ultimately up to Guido
to accept or reject your patch. I am actually willing to change my
vote to -0. I cannot recall ever using either str(..) or print on a
range object, so this change will not affect me while I still believe
it will not solve your problem either.
Other than some mild frustration at having invested a fair amount of
time in producing my first python patch
This happens a lot. Oftentimes proposals are not even considered
without a working patch. I hope writing the patch and receiving
Martin's comments on your code was a valuable experience in itself
even if your patch does not get accepted.
I am also in the middle of
editing a textbook that will come out this fall. my intention is to
have this book be 3.0 compatible. So it would be nice for me to have
some clarity on the direction this will go.
I would suggest considering a custom displayhook approach. You can
write a custom displayhook that will print range(..), {}.keys(),
{}.values() etc in a student-friendly way. I believe a module
installing such display hook can be included in the standard library.
In addition to iterable's display problem such a hook can limit the
amount of output when displaying long lists, insert smart line breaks
etc. For a textbook, you can instruct the readers to download your
code and import a custom module before trying the examples. This is
likely to make your textbook more future-proof because you will be
able to update your displayhook code as python changes.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2610
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2618] Tile module: Add support for themed widgets
New submission from Kevin Walzer [EMAIL PROTECTED]: The Tile module adds support for the platform-native themed widgets now available in Tk 8.5's core (ttk:: namespace in Tk terms). The module also supports the ttk:: namespace for Tk 8.4 if a separate Tk extension is installed. Adding this module to the core lib-tk library will make it simple for Tkinter developers to access the improved, modern widget set now available. The module was originally developed by Martin Franklin. I have updated and maintained it for the past two years. Martin Franklin has granted me permission to submit it for inclusion in the lib-tk core; documentation available on request. -- components: Tkinter files: Tile.py messages: 65367 nosy: wordtech severity: normal status: open title: Tile module: Add support for themed widgets type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file10010/Tile.py __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2618 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue858809] Use directories from configure rather than hardcoded
Sérgio Durigan Júnior [EMAIL PROTECTED] added the comment: Hi, Continuing with my effort to improve Python's build system, I'd really like to know why this issue has not been solved yet. I mean, apparently this problem is still present in Python 2.5, since I can't change the library's path with --libdir configure's flag. Any news about it? -- nosy: +sergiodj Tracker [EMAIL PROTECTED] http://bugs.python.org/issue858809 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2618] Tile module: Add support for themed widgets
Guilherme Polo [EMAIL PROTECTED] added the comment: Is this complete ? I see several methods with just a pass, where the docstring says it returns a dict, for example. -- nosy: +gpolo __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2618 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2619] Document memoryview
New submission from Benjamin Peterson [EMAIL PROTECTED]: memoryview documentation is currently nonexistent. -- assignee: georg.brandl components: Documentation messages: 65370 nosy: benjamin.peterson, georg.brandl priority: critical severity: normal status: open title: Document memoryview type: feature request versions: Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2619 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2610] string representation of range
Brad Miller [EMAIL PROTECTED] added the comment:
I would suggest considering a custom displayhook approach. You can
write a custom displayhook that will print range(..), {}.keys(),
{}.values() etc in a student-friendly way. I believe a module
installing such display hook can be included in the standard library.
In addition to iterable's display problem such a hook can limit the
amount of output when displaying long lists, insert smart line breaks
etc. For a textbook, you can instruct the readers to download your
code and import a custom module before trying the examples. This is
likely to make your textbook more future-proof because you will be
able to update your displayhook code as python changes.
That is an interesting idea! I just hacked together a quick prototype.
I'll discuss this with my co-author. Its a fine line between using
'real'
Python and providing an appropriate level of help for the beginner. We
have tried to minimize the number of additional modules and
dependencies, so
if there was a hook like this as part of the standard library that would
be
great.
Brad
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2610
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2559] atom sorting error when building ctypes
Ronald Oussoren [EMAIL PROTECTED] added the comment: I'm pretty sure I get the same error when building PyObjC. It seems to be a harmless warning though, PyObjC passes all its unittests and those really exercise all of libffi. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2559 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2590] S_unpack_from() Read Access Violation
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: What do you mean by obscene values? Do you have an example of actual values where the check at line 1561 does not do the right thing? -- just trying to understand where the problem is. -- nosy: +amaury.forgeotdarc __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2590 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2618] Tile module: Add support for themed widgets
Changes by Benjamin Peterson [EMAIL PROTECTED]: -- components: +Library (Lib) type: behavior - feature request __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2618 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2607] why is (default)dict so slow on tuples???
Martin v. Löwis [EMAIL PROTECTED] added the comment: Perhaps your GC thresholds would be better default values than what is currently in force. No, the defaults are correct for typical applications. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2607 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Martin v. Löwis [EMAIL PROTECTED] added the comment: Actually, I know that you can use CC to do it, but IMHO that's not the correct approach. I understand too you concern about adding @CFLAGS@, but I think the user should be able to define his/her own CFLAGS, and this is not implemented yet. Do you agree with that? No, I don't agree this is not implemented. The user can set CC, BASECFLAGS, and OPT, all of them contributing the CFLAGS. _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1628484 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2610] string representation of range
Martin v. Löwis [EMAIL PROTECTED] added the comment: I don't think 0, 1, ..., 9 is much clearer than range(0, 10). The only problem students may have is that 10 not in range(0, 10), but this can be learned very quickly. The .. repr breaks x == eval(repr(x)) invariant which is actually important in some of my code. I think you misunderstand the patch. It doesn't affect repr() at all. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2610 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2610] string representation of range
Martin v. Löwis [EMAIL PROTECTED] added the comment: Now there are objections. Other than some mild frustration at having invested a fair amount of time in producing my first python patch, I am also in the middle of editing a textbook that will come out this fall. Don't be frustrated. This is a regular thing to happen; sometimes, opposition won't form until the code is committed and released in an alpha release. So it would be nice for me to have some clarity on the direction this will go. We should wait a few more days for people to speak up. Myself, I'm -0 on the patch. The '' syntax is awkward. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2610 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2618] Tile module: Add support for themed widgets
Martin v. Löwis [EMAIL PROTECTED] added the comment: Kevin, is this all your code (the comment seems to suggest otherwise). Can all authors fill out contributor agreements? -- nosy: +loewis __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2618 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2620] Multiple buffer overflows in unicode processing
New submission from Justin Ferguson [EMAIL PROTECTED]:
174 static
175 int unicode_resize(register PyUnicodeObject *unicode,
176 Py_ssize_t length)
177 {
[...]
201
202 oldstr = unicode-str;
203 PyMem_RESIZE(unicode-str, Py_UNICODE, length + 1);
[...]
209 unicode-str[length] = 0;
210 unicode-length = length;
211
95 #define PyMem_RESIZE(p, type, n) \
96 ( assert((n) = PY_SIZE_MAX / sizeof(type)) , \
97 ( (p) = (type *) PyMem_REALLOC((p), (n) * sizeof(type)) ) )
The unicode_resize() function acts essentially as a wrapper to
realloc(), it accomplishes this via the PyMem_RESIZE() macro which
factors the size with the size of the type, in this case it multiplies
by two as Py_UNICODE is typedef'd to a wchar_t. When resizing large
strings, this results in an incorrect allocation that in turn leads to
buffer overflow.
This is specific to the Unicode objects, however I would not be
surprised to see that other types have this complication as well. Please
see attached proof of concepts.
--
components: Interpreter Core
files: python-2.5.2-unicode_resize-utf7.py
messages: 65379
nosy: jnferguson
severity: normal
status: open
title: Multiple buffer overflows in unicode processing
type: security
versions: Python 2.5
Added file: http://bugs.python.org/file10011/python-2.5.2-unicode_resize-utf7.py
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2620
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2620] Multiple buffer overflows in unicode processing
Changes by Justin Ferguson [EMAIL PROTECTED]: Added file: http://bugs.python.org/file10012/python-2.5.2-unicode_resize-utf8.py __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2620 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2620] Multiple buffer overflows in unicode processing
Changes by Justin Ferguson [EMAIL PROTECTED]: Added file: http://bugs.python.org/file10013/python-2.5.2-unicode_resize-utf16.py __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2620 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2590] S_unpack_from() Read Access Violation
Justin Ferguson [EMAIL PROTECTED] added the comment: What I was originally thinking was if offset was larger than buf_len, that would cause the check at 1561 to fail due to the subtraction. That said, I'm not sure what type its being compared against so I need to check this further, let me get back to you, I may have made a mistake and this may be !bug. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2590 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2618] Tile module: Add support for themed widgets
Kevin Walzer [EMAIL PROTECTED] added the comment: No, it is not all my code. I will contact Martin Franklin about filling out contributors agreement. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2618 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2620] Multiple buffer overflows in unicode processing
Marc-Andre Lemburg [EMAIL PROTECTED] added the comment:
You are probably referring to 32-bit platforms. At least on 64-bit
platforms, there's no problem with your test cases:
# this is to get the unicode_freelist initialized
... # the length of the string must be = 9 to keep
... # unicode-str from being deallocated and set to
... # NULL
... bla = unicode('IOActive')
del bla
msg = 'A'*2147483647
msg.decode('utf7')
Traceback (most recent call last):
File stdin, line 1, in module
MemoryError
The code does check for success of the realloc():
PyMem_RESIZE(unicode-str, Py_UNICODE, length + 1);
if (!unicode-str) {
unicode-str = (Py_UNICODE *)oldstr;
PyErr_NoMemory();
return -1;
}
Are you after the integer overflow and the fact that realloc() would (if
possible) allocate a buffer smaller than needed ?
--
nosy: +lemburg
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2620
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2610] string representation of range
Raymond Hettinger [EMAIL PROTECTED] added the comment: FWIW, I would like to see a newsgroup or python-dev discussion for a more general solution to the problem for helpful repr's for iterators. In 3.0, lots of things return iterators, not just range(). Before applying one ad-hoc patch, it would be helpful to think through how the issue should be handled across the whole language. For example, perhaps pprint() should display general iterators with the ... notation. For teaching and experimentation purposes, maybe the right answer is the make the command-line a bit smarter. It already knows how to suppress None return values. Perhaps, it should be taught how to display range objects and dict.items() and such. -- nosy: +rhettinger __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2610 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2620] Multiple buffer overflows in unicode processing
Justin Ferguson [EMAIL PROTECTED] added the comment: Yes, excuse me-- this should be 32-bit specific as I believe Python will not let me get a string long enough to overflow the integer on 64-bit. It's a big string, the only realistic scenario I can see is XML parsing or similar. theory$ ./python -V Python 2.5.2 theory$ cat /proc/cpuinfo | grep -i model model : 4 model name : Intel(R) Pentium(R) 4 CPU 3.00GHz theory$ ./python python-2.5.2-unicode_resize-utf7.py Segmentation fault __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2620 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2621] rename test_support to support
New submission from Benjamin Peterson [EMAIL PROTECTED]: I used some brute force search and replace for this and it worked quite well. If this patch is accepted, I'll fix the docs. -- components: Tests files: rename_test_support.patch keywords: easy, patch messages: 65385 nosy: benjamin.peterson, brett.cannon, georg.brandl severity: normal status: open title: rename test_support to support type: feature request versions: Python 2.6 Added file: http://bugs.python.org/file10014/rename_test_support.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2621 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2621] rename test_support to support
Changes by Benjamin Peterson [EMAIL PROTECTED]: Added file: http://bugs.python.org/file10015/rename_test_support2.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2621 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2620] Multiple buffer overflows in unicode processing
Alexander Belopolsky [EMAIL PROTECTED] added the comment: Note that in r61458 Neal replaced PyMem_RESIZE with a direct call to PyMem_REALLOC thus eliminating integer overflow check even from the debug builds. -- nosy: +belopolsky, nnorwitz __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2620 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2620] Multiple buffer overflows in unicode processing
Alexander Belopolsky [EMAIL PROTECTED] added the comment: Justin, Where did you find the definition that you cited: 95 #define PyMem_RESIZE(p, type, n) \ 96 ( assert((n) = PY_SIZE_MAX / sizeof(type)) , \ 97 ( (p) = (type *) PyMem_REALLOC((p), (n) * sizeof(type)) ) ) ? Current Include/pymem.h does not have the assert: 94 #define PyMem_RESIZE(p, type, n) \ 95 ( (p) = (type *) PyMem_REALLOC((p), (n) * sizeof(type)) ) and it did not change for a while. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2620 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2620] Multiple buffer overflows in unicode processing
Changes by Gregory P. Smith [EMAIL PROTECTED]: -- nosy: +gregory.p.smith priority: - high versions: +Python 2.4 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2620 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2607] why is (default)dict so slow on tuples???
Andreas Eisele [EMAIL PROTECTED] added the comment: Even if they mean that creation of a huge number N of objects requires O(N*N) effort? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2607 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2620] Multiple buffer overflows in unicode processing
Alexander Belopolsky [EMAIL PROTECTED] added the comment:
The following simple change should be enough for this issue, but I would
consider implementing the overflow check in the PyMem_RESIZE and PyMem_NEW
macros and de-deprecate their use.
===
--- Objects/unicodeobject.c (revision 62237)
+++ Objects/unicodeobject.c (working copy)
@@ -261,8 +261,8 @@
it contains). */
oldstr = unicode-str;
-unicode-str = PyObject_REALLOC(unicode-str,
- sizeof(Py_UNICODE) * (length + 1));
+unicode-str = SIZE_MAX/sizeof(Py_UNICODE) - 1 length ? NULL :
+PyObject_REALLOC(unicode-str, sizeof(Py_UNICODE) * (length +
1));
if (!unicode-str) {
unicode-str = (Py_UNICODE *)oldstr;
PyErr_NoMemory();
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2620
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2607] why is (default)dict so slow on tuples???
Raymond Hettinger [EMAIL PROTECTED] added the comment: This discussion ought to be moved to comp.lang.python. The timing script needs work. It doesn't isolate any one issue for discussion. It is affected by GC, dict resizing, details of creating and hashing string objects, the need to periodically call the system malloc, etc. You get different results if: * a new dictionary is created on each pass * if any of the objects get reused * if range(5) gets replaces with [0]*5 * if you use longs instead of ints * if the strings are of fixed length: str(j)[:5] This is the wrong forum to explain every nuance of what affects performance and whether you think perl is better. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2607 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2622] Import errors in email.message.py
New submission from John Jackson [EMAIL PROTECTED]: In email.message.py there are two import errors: line 128 from email.Generator import Generator should be from email.generator import Generator line 784 from email.Iterators import walk should be from email.iterators import walk -- components: Library (Lib) messages: 65391 nosy: JohnJackson severity: normal status: open title: Import errors in email.message.py type: crash versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2622 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2621] rename test_support to support
Martin v. Löwis [EMAIL PROTECTED] added the comment: What's the rationale for this change? -- nosy: +loewis __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2621 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
