[issue2690] Precompute range length
Nick Coghlan [EMAIL PROTECTED] added the comment: Given that range() produced a list in the 2.x series (hence limited to available memory), and xrange() uses int internally for its values (and hence couldn't even cope with short ranges with values greater than sys.maxint). So my preference is to mimic the 2.x range's behaviour in this case by raising an overflow error if the sequence is too long. (From Python 2.5.1) range(2**99, 2**100) Traceback (most recent call last): File stdin, line 1, in module OverflowError: range() result has too many items range(2**99, 2**99+5) [633825300114114700748351602688L, 633825300114114700748351602689L, 633825300114114700748351602690L, 633825300114114700748351602691L, 633825300114114700748351602692L] xrange(2**99, 2**99+5) Traceback (most recent call last): File stdin, line 1, in module OverflowError: long int too large to convert to int -- nosy: +ncoghlan __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2690 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2695] Ignore case when checking algorithm in urllib2
New submission from david reid [EMAIL PROTECTED]: Small change to allow get_algorithm_impls to correctly detect when lower case algorithm strings are passed. I recently ran into a server that sent 'md5' and so this function failed without this small change. def get_algorithm_impls(self, algorithm): # lambdas assume digest modules are imported at the top level if algorithm.lower() == 'md5': H = lambda x: hashlib.md5(x).hexdigest() elif algorithm.lower() == 'sha': H = lambda x: hashlib.sha1(x).hexdigest() ... -- components: Library (Lib) messages: 65836 nosy: zathras severity: normal status: open title: Ignore case when checking algorithm in urllib2 type: behavior versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2695 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2696] unicode string does not get freed -- memory leak?
New submission from ThurnerRupert [EMAIL PROTECTED]: is it possible that str and unicode str are treated differently, i.e. unicode str does not give memory back? jonas borgström noticed the following behaviour: resident_size() 3780 a = [%i % i for i in xrange(2**22)] resident_size() 239580 del a resident_size() 4128-- Most memory returned to the os a = [u%i % i for i in xrange(2**22)] resident_size() 434532 del a resident_size()R 401760 -- Almost nothing returned to the os for details see http://groups.google.com/group/trac-dev/browse_thread/thread/9de74e1d2f62e2ed. -- messages: 65837 nosy: ThurnerRupert severity: normal status: open title: unicode string does not get freed -- memory leak? versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2696 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2684] Logging Module still failing for %(filename)s, __init__
Vinay Sajip [EMAIL PROTECTED] added the comment: This is not a logging bug, but rather due to the circumstance that .pyc/.pyo files do not correctly point to the source files that produced them. There is another issue about this (#1180193) . Closing this, as it's not a logging issue. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2684 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.6 (modifications to current re 2.2.2)
Jeffrey C. Jacobs [EMAIL PROTECTED] added the comment: Thank you and Merci Antoine! That is a good point. It is clearly specific to the compiler whether a switch-case will be turned into a series of conditional branches or simply creating an internal jump table with lookup. And it is true that most compilers, if I understand correctly, use the jump-table approach for any switch-case over 2 or 3 entries when the cases are tightly grouped and near 0. That is probably why the original code worked so fast. I'll see if I can combine the best of both approaches. Thanks again! __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2636 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2694] msilib file names check too strict ?
Martin v. Löwis [EMAIL PROTECTED] added the comment: Indeed, the primary keys in many tables must be Identifiers, see http://msdn2.microsoft.com/en-us/library/aa369212(VS.85).aspx make_id tries to synthesize an identifier from a file name, and fails for your file names. -- nosy: +loewis __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2694 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2697] Logging ancestors ignored after configuration
New submission from andrew cooke [EMAIL PROTECTED]: I am seeing some odd behaviour with logging which would be explained if loggers that are not defined explicitly (but which are controlled via their ancestors) must be created after the logging system is configured via fileConfig(). That's a bit abstract, so here's the problem itself: I define my log within a module by doing import logging log = logging.getLogger(__name__) Now typically __name__ will be something like acooke.utils.foo. That happens before the application configures logging, which it does by calling logging.config.fileConfig() to load a configuration. If I do that, then I don't see any logging output from acooke.utils.foo (when using log from above after fileConfig has been called) unless I explicitly define a logger with that name. Neither root nor an acooke logger, defined in the config file, are called. One way to handle this is to make creation of module-level Loggers lazy, and make sure that logging initialisation occurs before any other logging is actually used (which is not so hard - just init log at the start of the application). Of course, there's a performance hit... For example: class Log(object): def __init__(self, name): super(Log, self).__init__() self._name = name self._lazy = None def __getattr__(self, key): if not self._lazy: self._lazy = logging.getLogger(self._name) return getattr(self._lazy, key) and then, in some module: from acooke.util.log import Log log = Log(__name__) [...] class Foo(object): def my_method(self): log.debug(this works as expected) -- components: Library (Lib) messages: 65843 nosy: acooke severity: normal status: open title: Logging ancestors ignored after configuration type: behavior versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2697 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2603] Make range __eq__ work
Changes by Benjamin Peterson [EMAIL PROTECTED]: Added file: http://bugs.python.org/file10116/range_eq8_normalize4.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2603 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2694] msilib file names check too strict ?
Cournapeau David [EMAIL PROTECTED] added the comment: Ok, thanks for the information. It may good to have a bit more informative error, though, such as saying which characters are allowed when checking against a regex ? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2694 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2694] msilib file names check too strict ?
Martin v. Löwis [EMAIL PROTECTED] added the comment: Actually, the algorithm should be fixed to generate a valid identifier for any input. Would you like to work on a fix? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2694 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2694] msilib file names check too strict ?
Cournapeau David [EMAIL PROTECTED] added the comment: It's not that I don't want to work on it, but I don't know anything about msi, except that some windows users of my packages request it :) So I would need some indication on what to fix exactly Do I understand right that dist_msi builds a database of the files, and that the identifiers could be named differently than the filenames themselves, as long as they are unique ? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2694 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2694] msilib file names check too strict ?
Martin v. Löwis [EMAIL PROTECTED] added the comment: Do I understand right that dist_msi builds a database of the files, and that the identifiers could be named differently than the filenames themselves, as long as they are unique ? Correct. As a design objective, I try to use identifiers close to the file names, to simplify debugging of the MSI file (Microsoft itself typically uses UUIDs instead). In short, just make make_id generate valid identifiers. An algorithm on top of that will make them unique in case of conflicts. Regards, Martin __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2694 __ ___ 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
Mads Kiilerich [EMAIL PROTECTED] added the comment: Testing that email.message doesn't use the wrong casing email.Generator isn't enough. That would just test that this patch has been applied. It must also be tested that no other modules uses the wrong casing of email.Generator. Or other email packages. Or any other packages at all. IMHO the right test would be to test that modulefinder can find all relevant modules in all cases. The problem is that it gives irrelevant warnings. I tested with some shell hacking to find all modulefinder failures which could be found with another casing: find * -name '*.py'|sed 's,\.py$,,g;s,/,.,g;s,\.__init__$,,g' /tmp/all_fs_modules for a in $(find * -name '*.py'); do echo $a; python -m modulefinder $a; echo; done /tmp/all_referenced_modules for a in $(grep ^? /tmp/all_referenced_modules|sed 's,^\? \(.*\) imported from .*,\1,g'|sort|uniq); do grep -i ^$a'$' /tmp/all_fs_modules; done /tmp/referenced_existing_ignorecased email.base64mime email.charset email.encoders email.errors email.generator email.header email.iterators email.message email.parser email.quoprimime email.utils ftplib - where the last hit comes from bogus regexp matching. The test takes long time to run as it is. That could probably be improved. But still I think this is to be compared with lint-like tools which should be run reguarly but isn't suitable for unit tests. I feel ashamed for arguing against introducing a test. I think I do that because I think that this isn't a normal bug and thus isn't suitable for unit testing. The email module itself really is fully backwards compatible. And modulefinder does a good job doing what it does and can't be blamed for not figuring the email hackery out. The problem comes when a third external modules puts things together and they doesn't fit together as one could expect. Also, currently both casings works and should work. Using the old casing isn't a bug bug, but it has consequences which IMHO is enough to call it a bug and fix it. Perhaps Python could have a standard way markup of deprecated functions so that it could be checked that the standard librarary didn't use them. __ 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
[issue2487] ldexp(x,n) misbehaves when abs(n) is large
Mark Dickinson [EMAIL PROTECTED] added the comment: Here's a patch that should fix ldexp(x, large_int), as follows: ldexp(x, n) = x if x is a NaN, zero or infinity ldexp(x, n) = copysign(0., x) for x finite and nonzero, n large and -ve ldexp(x, n) - OverflowError for x finite and nonzero, n large and +ve It would be good if someone else could review this before I check it in; Fredrik, would you have time for this? -- keywords: +patch Added file: http://bugs.python.org/file10115/ldexp.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2487 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2603] Make range __eq__ work
Changes by Benjamin Peterson [EMAIL PROTECTED]: Added file: http://bugs.python.org/file10117/range_eq8_normalize5.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2603 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2698] Extension module build fails for MinGW: missing vcvarsall.bat
New submission from Lenard Lindstrom [EMAIL PROTECTED]:
Python 2.6a2 on Windows XP
Distutils fails to build an extension module for MinGW. Even though
mingw32 is specified as the compiler distutils.msvc9compiler is still
loaded and it cannot find vcvarsall.bat. Here is an example:
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
[snip]
C:\pygame\extpath=%path%;C:\python26;C:\mingw\bin
C:\pygame\extset MINGW_ROOT_DIRECTORY=C:\mingw
C:\pygame\extpython setup.py build --compiler=mingw32
running build
running build_ext
error: None
C:\pygame\extpython setup.py build_ext --compiler=mingw32
Traceback (most recent call last):
File setup.py, line 6, in module
ext_modules=[Extension('simple', ['simple.c',]),],
File C:\python26\lib\distutils\core.py, line 137, in setup
ok = dist.parse_command_line()
File C:\python26\lib\distutils\dist.py, line 459, in
parse_command_line
args = self._parse_command_opts(parser, args)
File C:\python26\lib\distutils\dist.py, line 517, in
_parse_command_opts
cmd_class = self.get_command_class(command)
File C:\python26\lib\distutils\dist.py, line 836, in
get_command_class
__import__ (module_name)
File C:\python26\lib\distutils\command\build_ext.py, line 21, in
module
from distutils.msvccompiler import get_build_version
File C:\python26\lib\distutils\msvccompiler.py, line 658, in
module
from distutils.msvc9compiler import MSVCCompiler
File C:\python26\lib\distutils\msvc9compiler.py, line 286, in
module
VC_ENV = query_vcvarsall(VERSION, ARCH)
File C:\python26\lib\distutils\msvc9compiler.py, line 253, in
query_vcvarsall
raise IOError(Unable to find vcvarsall.bat)
IOError: Unable to find vcvarsall.bat
C:\pygame\exttype setup.py
from distutils.core import setup, Extension
setup(name='Simple',
version='1.0',
description='Python extension module test',
ext_modules=[Extension('simple', ['simple.c',]),],
)
C:\pygame\extgcc --version
gcc (GCC) 3.4.5 (mingw special)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
C:\pygame\extpython -V
Python 2.6a2
--
components: Distutils
messages: 65850
nosy: kermode
severity: normal
status: open
title: Extension module build fails for MinGW: missing vcvarsall.bat
versions: Python 2.6
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2698
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2677] Argument rules for callables do not apply when function implementation uses PyArg_ParseTuple
Georg Brandl [EMAIL PROTECTED] added the comment: I'd love to add to the documentation, but I can't seem to find a proper location - except the Tutorial? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2677 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2691] Document size_t related long object APIs
Georg Brandl [EMAIL PROTECTED] added the comment: Thanks, committed as r62513. -- resolution: - accepted status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2691 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2668] apply() documentation is slightly incorrect
Georg Brandl [EMAIL PROTECTED] added the comment: Fixed in r62511. -- resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2668 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2584] numeric overflow in IDLE
Changes by Kurt B. Kaiser [EMAIL PROTECTED]: -- assignee: - kbk nosy: +kbk priority: - normal __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2584 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1180] Option to ignore or substitute ~/.pydistutils.cfg
Phillip J. Eby [EMAIL PROTECTED] added the comment: Both versions of the patch have a problem, in that the Distribution object is looking for an option directly in sys.argv. At the very least, this should be looking at the 'script_args' attribute of the Distribution instead (if not actually parsing the command line enough to find the option). -- nosy: +pje __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1180 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2699] Exception name improperly indented
New submission from Brett Cannon [EMAIL PROTECTED]: The new warnings implementation tweaks how tracebacks are printed. This introduced a bug where the exception name is indented when it shouldn't be: e.g., ``raise KeyError`` should look like:: Traceback (most recent call last): File stdin, line 1, in module KeyError not:: Traceback (most recent call last): File stdin, line 1, in module KeyError -- assignee: brett.cannon components: Interpreter Core messages: 65855 nosy: brett.cannon priority: release blocker severity: normal status: open title: Exception name improperly indented versions: Python 2.6 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2699 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2699] Exception name improperly indented
Brett Cannon [EMAIL PROTECTED] added the comment: Forgot to mention this is probably from Python/traceback.c:tb_displayline(). __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2699 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2699] Exception name improperly indented
Benjamin Peterson [EMAIL PROTECTED] added the comment: It looks like you can just remove the offending line like so: Index: Python/traceback.c === --- Python/traceback.c (revision 62515) +++ Python/traceback.c (working copy) @@ -222,8 +222,7 @@ err = PyFile_WriteString(linebuf, f); if (err != 0) return err; - -err = PyFile_WriteString(, f); + return Py_DisplaySourceLine(f, filename, lineno); } -- nosy: +benjamin.peterson __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2699 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2337] Backport oct() and hex() to use __index__
Benjamin Peterson [EMAIL PROTECTED] added the comment: This is what I'd like to do: In builtin oct/hex check if the special method is declared. If it is, Py3k warn and use it. If not, check if we can do it the Py3k way (with PyNumber_ToBase). Sound good? -- nosy: +benjamin.peterson __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2337 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2700] document PyNumber_ToBase
New submission from Benjamin Peterson [EMAIL PROTECTED]: Including a patch. -- assignee: georg.brandl components: Documentation files: tobase_doc.patch keywords: patch messages: 65860 nosy: benjamin.peterson, georg.brandl severity: normal status: open title: document PyNumber_ToBase type: feature request versions: Python 2.6 Added file: http://bugs.python.org/file10118/tobase_doc.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2700 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1950] Potential overflows due to incorrect usage of PyUnicode_AsString.
Alexandre Vassalotti [EMAIL PROTECTED] added the comment: So, any comment on the latest patch? If everything is all right, I would like to commit the patch to py3k. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1950 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1338] pickling bytes?
Alexandre Vassalotti [EMAIL PROTECTED] added the comment: Guido fixed this issue in r61467. Closing. -- resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1338 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2337] Backport oct() and hex() to use __index__
Brett Cannon [EMAIL PROTECTED] added the comment: @Georg: That is a possibility. Would need to add the proper Py3K warning to the current builtins, though. @Benjamin: You don't want to warn if it will work for Py3K, so don't warn if __index__ is used. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2337 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2699] Exception name improperly indented
Brett Cannon [EMAIL PROTECTED] added the comment: Yep. I already did that and ran the unit test suite to verify. Now I am just trying to figure out how to best test it. It seems it only comes up for printing a traceback. That would mean either using subprocess to run another interpreter and capture its output or cheat and use ctypes. I don't like either solution. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2699 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2337] Backport oct() and hex() to use __index__
Benjamin Peterson [EMAIL PROTECTED] added the comment: I meant not to. Sorry, that wasn't clear. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2337 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2671] PyErr_WarnPy3k
Guido van Rossum [EMAIL PROTECTED] added the comment: Looks good. Go ahead. Make sure to block the CL (and any follow-up CLs that use this) from integration into 3.0. -- assignee: - benjamin.peterson nosy: +gvanrossum resolution: - accepted __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2671 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue558238] Pickling bound methods
Alexandre Vassalotti [EMAIL PROTECTED] added the comment: Personally, I don't see how adding this feature would create a security hole (or more properly said, grow the giant hole that are the GLOBAL and REDUCE opcodes). I don't see either why this should be included in the standard library. Unless there is still a need for this feature, I think this bug should be closed. -- nosy: +alexandre.vassalotti Tracker [EMAIL PROTECTED] http://bugs.python.org/issue558238 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue558238] Pickling bound methods
Changes by Alexandre Vassalotti [EMAIL PROTECTED]: -- status: open - pending Tracker [EMAIL PROTECTED] http://bugs.python.org/issue558238 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1637926] Empty class 'Object'
Alexandre Vassalotti [EMAIL PROTECTED] added the comment: This has almost no-chance to get included in the standard library. Also, Python 2.6 will include ``namedtuple`` (see http://docs.python.org/dev/library/collections.html#collections.namedtuple), which provides similar functionally. Closing this issue as rejected. -- nosy: +alexandre.vassalotti resolution: - rejected status: open - closed _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1637926 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2671] PyErr_WarnPy3k
Benjamin Peterson [EMAIL PROTECTED] added the comment: Committed in r62517. -- status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2671 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2480] pickling of large recursive structures fails
Alexandre Vassalotti [EMAIL PROTECTED] added the comment: Bob Kline wrote: I just ran into this behavior with an attempt to pickle a dom tree for an XML document whose nesting level never got deeper than nine child nodes, and indeed it crashed the interpreter. Pickling recursive data-structure should not crash the interpreter. Please open a new issue and don't forget to provide an example case. the documentation for the pickle module [1] which claims (summarizing) that serializing recursive objects using marshal will fail but pickling recursive objects will not fail. The section of documentation, you are referring to, uses the term recursive object to means an object which contains a reference to itself. Anyway, the documentation [1] states clearly: Trying to pickle a highly recursive data structure may exceed the maximum recursion depth, a RuntimeError will be raised in this case. You can carefully raise this limit with sys.setrecursionlimit(). [1]: http://docs.python.org/lib/node317.html -- nosy: +alexandre.vassalotti type: crash - feature request __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2480 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2701] csv.reader accepts string instead of file object (duck typing gone bad)
New submission from Roy Smith [EMAIL PROTECTED]:
If you pass csv.reader() a filename as its first argument:
csv.reader('filename')
instead of a file object like you're supposed to, you don't get an error.
You instead get a reader object which returns the characters which make up
the filename.
Technically, this is not a bug, since the documentation says, csvfile can
be any object which supports the iterator protocol and returns a string
each time its next method is called, and a string meets that definition.
Still, this is unexpected behavior, and is almost certainly not what the
user intended. It would be useful if a way could be devised to catch this
kind of mistake.
--
components: Library (Lib)
messages: 65871
nosy: roysmith
severity: normal
status: open
title: csv.reader accepts string instead of file object (duck typing gone bad)
type: behavior
versions: Python 2.5
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2701
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1950] Potential overflows due to incorrect usage of PyUnicode_AsString.
Alexander Belopolsky [EMAIL PROTECTED] added the comment: The patch looks good. Just a question: I thought the strings returned by PyUnicode_AsStringAndSize are 0-terminated, while your patch at several places attempts to explicitly 0-terminate a copy of such string. Are you sure this is necessary? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1950 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2693] IDLE doesn't work with Tk 8.5
Greg Couch [EMAIL PROTECTED] added the comment:
I wish I could be as cavalier about Tk 8.5. The last version of Tk 8.4
just came out and it really shows its age, especially on Mac OS X, and
those are ~25% of our application's downloads. Since Python 2.6a2 is
not suitable for production use, that leaves us with patching 2.5.
Backporting, the _tkinter and Tkinter changes, was not hard, but then we
get SystemError: Objects/tupleobject.c:89: bad argument to internal
function errors with both the 2.5 and the 2.6a2 idlelibs. Looking at
the SVN log, it is not clear which patch to tupleobject.c fixed that
problem (does anyone know?).
So fixing WidgetRedirector.py to not screw up the string representation
of tuples is the easiest solution to get idle to work with Tk 8.5. and
Python 2.5 (you still would want the Tkinter.py changes for other
reasons). A slightly more robust solution would be to use Tcl quoting:
r = '{%s}' % '} {'.join(map(str, r))
But that has not been important in practice.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2693
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
