[issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6

Guido van Rossum added the comment: There's something I misunderstand then. I thought 2.x also didn't accept >255 args, but that test would seem to prove I'm wrong. __ Tracker <[EMAIL PROTECTED]>

[issue1623] Implement PEP-3141 for Decimal

Jeffrey Yasskin added the comment: _dec_from_triple: Probably, yes. It doesn't seem to have any practical effect, but it's good to be consistent. __lt__, __le__: It doesn't matter whether they're called because they have the same effect as __cmp__. They're only there to implement numbers.Real. P

[issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6

Christian Heimes added the comment: I vaguely remember that I had to modify the tests to use 254 args in Python 3.0. -- nosy: +tiran priority: -> normal __ Tracker <[EMAIL PROTECTED]> __

[issue1759] Backport of PEP 3129 "class decorators"

Changes by Christian Heimes: -- keywords: +patch nosy: +rhettinger __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscr

[issue1759] Backport of PEP 3129 "class decorators"

New submission from Christian Heimes: The patch backports the class decorator syntax to 2.6. All tests except two are passing. I'm not sure why the inspect test fails and I don't know how to fix the ast test. -- components: Interpreter Core files: trunk_pep3129_classdec.patch messages: 5

[issue1698] urlparse and usernames containing @

Senthil added the comment: The patch against the trunk could also have been applied to 2.5. There is NO change in the trunk and 2.4-maint patch. Thanks, Senthil __ Tracker <[EMAIL PROTECTED]> __ _

[issue1698] urlparse and usernames containing @

Senthil added the comment: Thank you, Yes having it in the 2.5.2 would be a good idea. The bug report is also on 2.5 only. I have attached the patch for the release25-maint branch. Thanks, Senthil Added file: http://bugs.python.org/file9102/issue6898-r25-maint.patch ___

[issue1514428] NaN comparison in Decimal broken

Mark Dickinson added the comment: It seems likely that Decimal is going to grow rich comparisons anyway, either as a result of PEP 3141 or as a result of removal of __cmp__. Given this, would there be any objections to making comparisons do the right thing (in the sense of IEEE-754) for NaNs?

[issue1623] Implement PEP-3141 for Decimal

Mark Dickinson added the comment: Some more comments: (1) I don't think I understand the mechanism by which __lt__ and __le__ are supposed to be called. For example, by adding a few print statements it seems that the comparison Decimal(2) > 3 doesn't call __lt__ at any stage. Is this what

[issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6

Robin Stocker added the comment: Thanks for the feedback! It's on line 111 in test_collections.py:: n = 1 import string, random names = [''.join([random.choice(string.letters) for j in range(10)]) for i in range(n)] Big = namedtuple('Big', names) b =

[issue1757] Decimal hash depends on current context

Mark Dickinson added the comment: Here's a patch for the trunk. Added file: http://bugs.python.org/file9101/issue1757.patch __ Tracker <[EMAIL PROTECTED]> __ __

[issue1743] IDLE fails to launch

Christian Heimes added the comment: It smells like a Vista issue. But IDLE shouldn't crash w/o a notice if the recent list can't be opened. -- assignee: -> kbk nosy: +kbk priority: -> low __ Tracker <[EMAIL PROTECTED]>

[issue1754] WindowsError messages are not properly encoded

Amaury Forgeot d'Arc added the comment: Here is a patch. Now I feel it is a hack, but it is the only place I found where I can access both the exception object and the encoding... Added file: http://bugs.python.org/file9100/windowserror.patch __ Tracker <[EMAIL P

[issue1743] IDLE fails to launch

Joakim added the comment: I can access the file. I renamed the file and tried the command again. Then I started IDLE and got a window. A new recent-files.lst was created. So I guess I solved the problem temporarily. __ Tracker <[EMAIL PROTECTED]>

[issue1743] IDLE fails to launch

Christian Heimes added the comment: Can you access the file C:\\Users\\Joakim\\.idlerc\\recent-files.lst with the explorer? Do the directory and the file exist? __ Tracker <[EMAIL PROTECTED]> __ __

[issue1757] Decimal hash depends on current context

Changes by Christian Heimes: -- priority: -> normal __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue1743] IDLE fails to launch

Joakim added the comment: Noticed I missed a bit of the path but it didn't matter. Changed the path to C:\Python25\Lib\idlelib\idle.py and got another error. C:\Users\Joakim>"C:\Python25\python.exe" "C:\Python25 \Lib\idlelib\idle.py" Traceback (most recent call last): File "C:\Python25\Lib\id

[issue1515] deepcopy doesn't copy instance methods

Michael Van Biesbrouck added the comment: Guido pointed out a common use case where people use bound methods in a way that would be poorly served by my change. An alternate implementation with a deeper copy will cause less surprise: def _deepcopy_method(x, memo): return type(x)(x.im_func, d

[issue1743] IDLE fails to launch

Joakim added the comment: I have the exact same problem also running 32-bit vista. Idle worked the first time I started it but after that it doesn't start. I did run the command and got this error. C:\Users\Joakim>"C:\Python25\python.exe" "C:\Python25\Lib\idle.py" C:\Python25\python.exe: can't

[issue932563] logging: need a way to discard Logger objects

Antoine Pitrou added the comment: I don't follow comp.lang.python either, so I'd be grateful if you give a link to the gmane thread ;) I hope we can find an useful solution to this limitation, logging is a very important task and the stdlib should satisfy all common wishes IMO.

[issue1758] Wrong link in documentation

Martin v. Löwis added the comment: Thanks for the report. I just fixed it in r59848; this will be released with Python 2.5.2. "old" docs *will* be updated for 2.5.x. -- nosy: +loewis resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTE

[issue1758] Wrong link in documentation

Robert Lehmann added the comment: This problem has been removed in the current version of the documentation (http://docs.python.org/dev/install/index.html) -- old docs aren't updated. It has an own section now (http://docs.python.org/dev/bugs.html). Issue can be closed. -- nosy: +lehman

[issue1751] Fast BytesIO implementation + misc changes

Changes by Alexandre Vassalotti: Removed file: http://bugs.python.org/file9096/bytesio+misc-fixes.patch __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bug

[issue1751] Fast BytesIO implementation + misc changes

Alexandre Vassalotti added the comment: I got a patch that also fixes the profiler tests. That was easy after all. :-) Added file: http://bugs.python.org/file9099/bytesio+misc-fixes-2.patch __ Tracker <[EMAIL PROTECTED]> ___

[issue1758] Wrong link in documentation

New submission from Martin Marcher: In this site: http://www.python.org/doc/current/inst/about.html under "Comments and Questions" the link to the python bugtracker is still pointing to the sourceforge bugtracker. -- components: Documentation messages: 59502 nosy: martin.marcher severity

[issue1766304] improve xrange.__contains__

Antoine Pitrou added the comment: The 2.6 patch should probably use long instead of int. -- nosy: +pitrou _ Tracker <[EMAIL PROTECTED]> _ ___

[issue932563] logging: need a way to discard Logger objects

Fred L. Drake, Jr. added the comment: Please be sure to post a link to the thread here, as not everyone here reads comp.lang.python. Tracker <[EMAIL PROTECTED]>

[issue932563] logging: need a way to discard Logger objects

Vinay Sajip added the comment: Ok, but let's continue the discussion on comp.lang.python, as this is probably not the best place for an extended discussion. I'll post there soon with a proposal. Tracker <[EMAIL PROTECTED]>

[issue1754] WindowsError messages are not properly encoded

Martin v. Löwis added the comment: > If this is chosen, I propose to use CharToOem as the "unfailing" > conversion function. I will try to come with a patch following this idea. Sounds fine to me. __ Tracker <[EMAIL PROTECTED]>

[issue1137] pyexpat patch for changing buffer_size

A.M. Kuchling added the comment: Here's another update of the simplified version, that also updated the documentation patch for reST and updates the test for the current code. Added file: http://bugs.python.org/file9098/pyexpat-patch2.txt __ Tracker <[EMAIL PROTE

[issue1623] Implement PEP-3141 for Decimal

Mark Dickinson added the comment: One minor point: Decimals are also created by the _dec_from_triple function: presumably that call to __new__ should also be changed to use super? __ Tracker <[EMAIL PROTECTED]> _

[issue1757] Decimal hash depends on current context

Changes by Facundo Batista: -- assignee: -> facundobatista nosy: +facundobatista __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing

[issue1754] WindowsError messages are not properly encoded

Amaury Forgeot d'Arc added the comment: > Forcing English messages would certainly reduce the problems And it does not even work: my French Windows XP does not contain the English error messages :-( > If we declare that all strings are considered as CP_ACP in the > exception, then the only way t

[issue1137] pyexpat patch for changing buffer_size

A.M. Kuchling added the comment: Here's a simpler, but still untested version of the patch that cuts out the various cases for reallocating when there's already buffered data and just does a flush every time. Added file: http://bugs.python.org/file9097/simpler_patch.txt ___

[issue1737] Windows installer issue (ObjectBrowser.py)

Christian Heimes added the comment: "your web browser corrected it"? Do you mean "corrupted"? -- nosy: +tiran __ Tracker <[EMAIL PROTECTED]> __

[issue1757] Decimal hash depends on current context

New submission from Mark Dickinson: The value of the Decimal hash() depends on the current context: >>> from decimal import * >>> x = Decimal("123456789.1") >>> hash(x) 1989332493 >>> getcontext().prec = 6 >>> hash(x) -2034270682 This has nasty consequences; e.g.: >>> s = set([x]) >>> x in s

[issue1737] Windows installer issue (ObjectBrowser.py)

Martin v. Löwis added the comment: I can confirm that the correct checksum of the file is what the web page says. So it seems that your web browser corrected it during the download. That, typically, is caused by the web browser perform a conversion of line endings in a binary file, so it would in

[issue1754] WindowsError messages are not properly encoded

Martin v. Löwis added the comment: I would claim that this is not a bug. Sure, the message doesn't come out correctly, but only because you run it in a cmd.exe window, not in (say) IDLE. IIUC, the problem is that Python computes the message in CP_ACP (i.e. the ANSI code page), whereas the termin

[issue1182] Paticular decimal mod operation wrongly output NaN.

Mark Dickinson added the comment: P.S. I've just noticed that both versions of __hash__ are buggy: the hash value of a Decimal depends on the current context. I'll open a new bug report. __ Tracker <[EMAIL PROTECTED]> _

[issue1182] Paticular decimal mod operation wrongly output NaN.

Mark Dickinson added the comment: You need to remove the old files in decimaltestdata before copying the new ones across: nrmx218 is an old, and buggy, testcase; at some point Mike Cowlishaw renamed normalize.decTest to reduce.decTest. He also renamed the operation from normalize to reduce, bu

[issue1657] [patch] epoll and kqueue wrappers for the select module

Guido van Rossum added the comment: Not yet, I ran out of time. Can you hold on for another week? __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list

[issue1657] [patch] epoll and kqueue wrappers for the select module

Christian Heimes added the comment: Guido, have you reviewed the patch and are you fine with it? -- components: +Extension Modules nosy: +gvanrossum __ Tracker <[EMAIL PROTECTED]> __ _

[issue1762972] 'exec' does not accept what 'open' returns

Guido van Rossum added the comment: Maybe just a doc update? _ Tracker <[EMAIL PROTECTED]> _ ___ Python-bugs-list mailing list Unsubscribe:

[issue1762972] 'exec' does not accept what 'open' returns

Christian Heimes added the comment: I've added the __file__ patch in r59841. Is there another location that needs to be fixed? _ Tracker <[EMAIL PROTECTED]> _ ___

[issue1722] Undocumented urllib functions

Georg Brandl added the comment: There are quite a lot more functions in __all__, more than 10 split* functions... should they all be documented? Also, isn't urlparse meant to do such tasks? __ Tracker <[EMAIL PROTECTED]> ___

[issue1734] documentation on metaclasses is incomplete and misleading

Georg Brandl added the comment: This should now be appropriately explained in the trunk, r59837. I also added an example of using __new__ in a metaclass. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]>

[issue932563] logging: need a way to discard Logger objects

Antoine Pitrou added the comment: Hi Vinay, Thanks for your reply. I think it's important to rephrase the problem in a simple way. The basic pattern is that there is a class C (say, a TCP connection class) where a specific part of each log line should from an instance-specific "contextual strin

[issue1756] -m broken in trunk

Guido van Rossum added the comment: Bah. Environment error. Sorry! -- resolution: -> invalid status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ ___

[issue1756] -m broken in trunk

Georg Brandl added the comment: Seems to work here... -- nosy: +georg.brandl __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list

[issue1756] -m broken in trunk

New submission from Guido van Rossum: As of today, the -m option doesn't appear to work any more in the trunk. I get this error: $ ./python -m string Could not import runpy module $ However it seems to be confused: $ ./python -c 'import runpy' $ IOW the module imports just fine. Crys, I won

[issue1527974] tarfile chokes on ipython archive on Windows

Lars Gustäbel added the comment: I close this issue because it is out of date. The new TarFile.extractall() method in Python 2.5 provides a way to solve the original problem IMO. -- resolution: -> out of date status: open -> closed _ Tracker <[EMAIL

[issue467924] Improve the ZipFile Interface

Georg Brandl added the comment: I committed your patch (after reviewing the docs) as r59834. I think there is no more to do here. -- resolution: -> accepted status: open -> closed Tracker <[EMAIL PROTECTED]>

[issue1540385] tarfile __slots__ addition

Lars Gustäbel added the comment: I close this issue as there has been no progress over the last 1.5 year. -- resolution: -> rejected status: open -> closed _ Tracker <[EMAIL PROTECTED]> __

[issue1754] WindowsError messages are not properly encoded

Guido van Rossum added the comment: 3.0 will be a long way away for many users. Perhaps forcing English isn't so bad, as Python's own error messages aren't translated anyway? __ Tracker <[EMAIL PROTECTED]> __

[issue1753] TextIOWrapper.write writes utf BOM for every string

Changes by Alexandre Vassalotti: -- status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue1753] TextIOWrapper.write writes utf BOM for every string

Changes by Alexandre Vassalotti: -- resolution: -> fixed __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: htt

[issue1753] TextIOWrapper.write writes utf BOM for every string

Alexandre Vassalotti added the comment: Committed fix in r59832. Thanks! P.S. Guido, what this comment, in write(), is about? # XXX What if we were just reading? __ Tracker <[EMAIL PROTECTED]> __

[issue1754] WindowsError messages are not properly encoded

Amaury Forgeot d'Arc added the comment: I think this is not possible if we want to preserve compatibility; at least, str(e.strerror) must not fail. I can see different solutions: 1) Don't fix, and upgrade to python 3.0 2) Store an additional e.unicodeerror member, use it in a new EnvironmentErro

[issue919614] Python configured with --disable-unicode fails tests, more

Georg Brandl added the comment: I renamed --enable-unicode to --with-wide-unicode in r59829; this should handle the Py3k case. I added suitable Py_USING_UNICODE directives in r59830 so that the trunk compiles again without unicode. -- assignee: -> gvanrossum nosy: +georg.brandl, gvanro

[issue1622] zipfile hangs on certain zip files

Alan McIntyre added the comment: Well I can't promise it will be swift, since my winter vacation ended today, but I'll keep on top of it as best I can. :) __ Tracker <[EMAIL PROTECTED]> __

[issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6

Georg Brandl added the comment: Keyword-only-args are not yet documented. __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscrib

[issue1668] -E command line parameter intent

Georg Brandl added the comment: Committed getenv.2.diff and extended envvar docs in r59827. -- resolution: -> accepted status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ ___

[issue1762972] 'exec' does not accept what 'open' returns

Christian Heimes added the comment: I've readded reload() as imp.reload() in r59825. I've also copied two unit tests from trunk to py3k. -- resolution: -> accepted _ Tracker <[EMAIL PROTECTED]> __

[issue602345] option for not writing .py[co] files

Georg Brandl added the comment: Committed r59824. -- status: open -> closed Tracker <[EMAIL PROTECTED]> ___ Python-bugs-list mailing

[issue1762972] 'exec' does not accept what 'open' returns

Christian Heimes added the comment: both sounds like a good idea. -- nosy: +tiran _ Tracker <[EMAIL PROTECTED]> _ ___ Python-bugs-lis

[issue1755179] Deadlocks with fork() and multithreading

Facundo Batista added the comment: Backported, commited in r59823. -- resolution: -> fixed status: open -> closed _ Tracker <[EMAIL PROTECTED]> _ __

[issue1753] TextIOWrapper.write writes utf BOM for every string

Changes by Georg Brandl: -- priority: normal -> high __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue1748] contextlib.contextmanager does not use functools.wraps

Changes by Georg Brandl: -- priority: -> low type: -> behavior __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscrib

[issue1755] Misspelling in future.c in 2.5.1 source (handl should be handle)

Georg Brandl added the comment: Fixed in r59820. -- nosy: +georg.brandl resolution: accepted -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ _

[issue1754] WindowsError messages are not properly encoded

Romulo A. Ceccon added the comment: "... but the error message must be converted to str early (i.e when building the Exception)." Wouldn't that create more problems? What if somebody wants to intercept the exception and do something with it, like, say, redirect it to a log file? The programmer m

[issue1751] Fast BytesIO implementation + misc changes

Alexandre Vassalotti added the comment: [grrr, I eat my words] > So, here's one big patch. I have updated the behavior of close(), so that ... it matches the behavior of 2.x. > As a side-effect, this make __next__ raises a ValueError, instead of StopIteration. ... when the file is closed. _

[issue1751] Fast BytesIO implementation + misc changes

Alexandre Vassalotti added the comment: So, here's one big patch. I have updated the behavior of close(), so that > The profile tests often fail when io.py changes because they happen to > depend on "golden output" which includes line numbers of code in io.py > that happens to be traced during

[issue1646] Make socket support TIPC.

Christian Heimes added the comment: Committed in r59819 -- resolution: accepted -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ __

[issue1646] Make socket support TIPC.

Alberto Bertogli added the comment: On Mon, Jan 07, 2008 at 03:37:54PM -, Christian Heimes wrote: > The unit tests don't work for me (Ubuntu 7.10, Linux 2.6.22, i386) > > >>> srv = socket.socket(socket.AF_TIPC, socket.SOCK_RDM) > Traceback (most recent call last): > File "", line 1, in >

[issue1182] Paticular decimal mod operation wrongly output NaN.

Facundo Batista added the comment: Mmm... I thought this would be a clean backport... but no. If we just copy the files to 2.5, we get two failures running the tests. - test_hash_method (DecimalUsabilityTest): This is because of the changes we made to the hash builtin in the trunk, and we shoul

[issue1646] Make socket support TIPC.

Christian Heimes added the comment: The unit tests don't work for me (Ubuntu 7.10, Linux 2.6.22, i386) >>> srv = socket.socket(socket.AF_TIPC, socket.SOCK_RDM) Traceback (most recent call last): File "", line 1, in File "/home/heimes/dev/python/trunk/Lib/socket.py", line 177, in __init__

[issue1754] WindowsError messages are not properly encoded

Amaury Forgeot d'Arc added the comment: I confirm the problem (with French accents) on python 2.5. Python 3.0 already fixed the problem by using the FormatMessageW() unicode version of the API. We could do the same for python 2.5, but the error message must be converted to str early (i.e when bu

[issue1752] logging.basicConfig misleading behaviour

Vinay Sajip added the comment: Added clarifying sentence to documentation (trunk only): "The function does nothing if any handlers have been defined for the root logger." -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]>

[issue1737] Windows installer issue (ObjectBrowser.py)

Dariusz Suchojad added the comment: Hmm, on a home PC the checksum's correct, it's a1d1a9c07bc4c78bd8fa05dd3efec87f. Assuming something is wrong with my download at work, is it possible for an MSI package to start the installation even when package is corrupted? Anyway, tomorrow I'll try to ins

[issue1754] WindowsError messages are not properly encoded

Christian Heimes added the comment: Oh nice ... Amaury knows probably more about the wide char Windows API than me. The function Python/error.c:PyErr_SetExcFromWindows*() needs to be modified. -- assignee: -> amaury.forgeotdarc nosy: +amaury.forgeotdarc priority: -> normal versions:

[issue1011893] Problems importing packages in ZIP file

Alan McIntyre added the comment: I just tried it on 2.5 and 2.6, since I didn't have the earlier versions available. If I find some time I'll see if I can try it on 2.3 & 2.4; maybe that will shed some light on whether it's been fixed or if is something specific to Windows that could still be br

[issue1752] logging.basicConfig misleading behaviour

Guido van Rossum added the comment: I recall being bitten by this too when first trying to use the logging module. I think the behavior is intentional, but I suppose it could be documented better. -- assignee: -> vsajip nosy: +gvanrossum, vsajip priority: -> low _

[issue1754] WindowsError messages are not properly encoded

Guido van Rossum added the comment: Crys, can you confirm this? It would seem we'll need to fix this twice -- once for 2.x, once for 3.0. -- nosy: +gvanrossum, tiran __ Tracker <[EMAIL PROTECTED]> __

[issue1646] Make socket support TIPC.

Changes by Christian Heimes: Removed file: http://bugs.python.org/file8981/0002-Make-socket-support-TIPC.patch __ Tracker <[EMAIL PROTECTED]> __ ___ Py

[issue1751] Fast BytesIO implementation + misc changes

Guido van Rossum added the comment: Any chance of uploading a single patch that contains all these changes? The profile tests often fail when io.py changes because they happen to depend on "golden output" which includes line numbers of code in io.py that happens to be traced during the test. I

[issue1755] Misspelling in future.c in 2.5.1 source (handl should be handle)

Changes by Christian Heimes: -- components: +Interpreter Core -None priority: -> low resolution: -> accepted versions: +Python 2.6 __ Tracker <[EMAIL PROTECTED]> __ _

[issue932563] logging: need a way to discard Logger objects

Fred L. Drake, Jr. added the comment: Ideally, it would be best if loggers didn't live forever behind the scenes if they have no non-default configuration, but documenting their long-lived nature and the recommended alternate ways to deal with getting additional context information into the resul

[issue1755] Misspelling in future.c in 2.5.1 source (handl should be handle)

New submission from Brad Tilley: /* A subsequent pass will detect future imports that don't appear at the beginning of the file. There's one case, however, that is easier to handl here: A series of imports joined by semi-colons, where the first import is a future

[issue932563] logging: need a way to discard Logger objects

Changes by Vinay Sajip: -- priority: high -> normal Tracker <[EMAIL PROTECTED]> ___ Python-bugs-list mailing list Unsubscribe: htt

[issue932563] logging: need a way to discard Logger objects

Vinay Sajip added the comment: Antoine, I take your point, but there are a number of ways of doing what you want, apart from the "extra" context argument: 1. Use your own logger classes which do what you want. It's probably best to make this a wrapper class so you can define different ones for d

[issue1737] Windows installer issue (ObjectBrowser.py)

Dariusz Suchojad added the comment: Done. Attached in python.zip. I've also noticed something strange here. http://python.org/download/releases/2.5.1/ says the MD5 sum should be a1d1a9c07bc4c78bd8fa05dd3efec87f but the MD5 client I'm using (http://www.pc-tools.net/win32/md5sums/) tells me the htt

[issue1562] Decimal can't be subclassed useful

Facundo Batista added the comment: Mark is right, the current behaviour is correct. See Tim post for a longer explanation. As general help, for the money class take a look of this: http://sourceforge.net/projects/pymoney There you'll see that the approach was to store the value, not subclass De

[issue1754] WindowsError messages are not properly encoded

New submission from Romulo A. Ceccon: The message for WindowsError is taken from the Windows API's FormatMessage() function, following the OS language. Currently Python does no conversion for those messages, so non-ASCII characters end up improperly encoded in the console. For example: >>> imp

[issue1011893] Problems importing packages in ZIP file

Dennis Chuah added the comment: I had forgotten about this bug. I haven't been able to test this on 2.5 as I have not worked with Python for a while. I think if you are satisfied that the problem doesn't exist, then close it. If I find it again, I can certainly log the problem again. BTW,

[issue1646] Make socket support TIPC.

Alberto Bertogli added the comment: On Sun, Jan 06, 2008 at 02:45:35PM -, Alberto Bertogli wrote: > I'll probably send you the updated patch sometime this week; thanks for > the ping =) Here are the three patches, rebased to the SVN commit 59815. The first one is the same I've already submi

[issue1753] TextIOWrapper.write writes utf BOM for every string

Changes by Georg Brandl: -- assignee: -> alexandre.vassalotti nosy: +alexandre.vassalotti __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-lis

[issue1753] TextIOWrapper.write writes utf BOM for every string

New submission from Erick Tryzelaar: I was playing around with python 3's io functions, and I found that when trying to write to an encoded utf-16 file that TextIOWrapper.write re-writes the utf-16 bom for every string: >>> f=open('foo', 'w', encoding='utf-16') >>> print('1234', file=f) >>> p