[issue1385] hmac module violates RFC for some hash functions, e.g. sha512

Changes by Georg Brandl: -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Un

[issue1394] simple patch, improving unreachable bytecode removing

Changes by Martin v. Löwis: -- keywords: +patch __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.p

[issue1395] py3k: duplicated line endings when using read(1)

Raghuram Devarakonda added the comment: I think the solution is to do the translation on a bigger chunk than on the string being returned in each read call. For example, the following patch correctly returns "a" and "\n" (instead of "a" and two "\n"s). Index: Lib/io.py =

[issue1392] py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeError patch

Guido van Rossum added the comment: > Updates: > * Added class BytesWarning(Warning) > * Added -b/-bb command line args and Py_BytesWarningFlag > * issue PyErr_WarnEx(PyExc_BytesWarning) when Py_BytesWarningFlag is set. > * Added warning filter for BytesWarning that raises an exception if > Py_By

[issue1345] Fix for test_netrc on Windows

Changes by Christian Heimes: -- keywords: +py3k resolution: -> invalid status: open -> closed superseder: -> py3k: duplicated line endings when using read(1) __ Tracker <[EMAIL PROTECTED]> _

[issue1392] py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeError patch

Christian Heimes added the comment: Pfff! I've written my best code after having one or two beers :) Updates: * Added class BytesWarning(Warning) * Added -b/-bb command line args and Py_BytesWarningFlag * issue PyErr_WarnEx(PyExc_BytesWarning) when Py_BytesWarningFlag is set. * Added warning fil

[issue1395] py3k: duplicated line endings when using read(1)

Guido van Rossum added the comment: Wow, thanks! This is not just a bug on Windows -- it is a bug in the TextIOWrapper code that is just more likely on Windows. It is easily reproduced on Linux too: >>> f = open("@", "wb")>>> f.write(b"a\r\n") 6 >>> f.close() >>> f = open("@", "r") >>> f.read(1)

[issue1389] py3k-pep3137: struct module is leaking references

Guido van Rossum added the comment: Committed revision 58871. Finding this took me half a day. It was not a real leak; it was just filling the character cache in stringobject.c slowly with random data. -- nosy: +gvanrossum resolution: -> fixed status: open -> closed ___

[issue1384] Windows fix for inspect tests

Amaury Forgeot d'Arc added the comment: Yes, the patch is needed. The problem arises when you run the python executable in different ways WITHOUT deleting the .pyc files. Example on my machine: Note that the exact path to run python is not the same: >cd C:\dev\python\py3k\PCbuild8 >del /s ..\*.

[issue1385] hmac module violates RFC for some hash functions, e.g. sha512

Gregory P. Smith added the comment: Fixed in release25-maint branch in svn r58870. -- versions: -Python 2.5 __ Tracker <[EMAIL PROTECTED]> __ _

[issue1395] py3k: duplicated line endings when using read(1)

New submission from Amaury Forgeot d'Arc: When reading a Windows text file one byte at a time, \r\n get split into two function calls, and the user receives two \n. The following test fails (put it somewhere in test_io.py, inside TextIOWrapperTest for example) def testReadOneByOne(self):

[issue1385] hmac module violates RFC for some hash functions, e.g. sha512

Gregory P. Smith added the comment: Fixed in trunk (2.6) svn revision 58868 with rfc 4231 unit tests and tests for the new warnings. The fix parts of that diff should be backported to 2.5. I'm leaving the Python 2.5 flag on the bug until that happens. I'm leaving Python 3.0 and py3k tags on th

[issue1384] Windows fix for inspect tests

Christian Heimes added the comment: Ah, os.path has a method for the job. I should have checked the module before reinventing the wheel ... For some unknown and mysterious reasons the inspect tests are passing again on my machine. I've purged the pyc files before I run the unpatched test suite.

[issue1384] Windows fix for inspect tests

Amaury Forgeot d'Arc added the comment: A slightly modified patch, which uses os.path.normcase before comparing file names. -- nosy: +amaury.forgeotdarc Added file: http://bugs.python.org/file8700/py3k_inspect_2.diff __ Tracker <[EMAIL PROTECTED]>

[issue1390] toxml generates output that is not well formed

Thomas Conway added the comment: Hi Martin, toxml() is not part of the DOM, so it could be changed to throw an exception. However, I suggest doing nothing, for the moment - I've posted to the dom mailing list at w3, so I'll see what wisdom we get from its members. cheers, Tom

[issue1390] toxml generates output that is not well formed

Martin v. Löwis added the comment: I'm not willing to change minidom unless there is precedence of how to deal with this case. So can you find DOM implementations in other languages that meet the DOM spec an still reject your code? __ Tracker <[EMAIL PROTECTED]> <

[issue1385] hmac module violates RFC for some hash functions, e.g. sha512

Changes by Gregory P. Smith: -- components: +Library (Lib) -None versions: +Python 2.5, Python 2.6 __ Tracker <[EMAIL PROTECTED]> __ ___ Python-

[issue1385] hmac module violates RFC for some hash functions, e.g. sha512

Gregory P. Smith added the comment: option 1 sounds best. i'll take care of this. thanks for noticing this and providing suggestions and a patch. __ Tracker <[EMAIL PROTECTED]> __ ___

[issue1394] simple patch, improving unreachable bytecode removing

New submission from Paul Pogonyshev: This patch improves bytecode output, by removing unreachable code. It doesn't target special cases, as now, but provides a generic implementation. -- components: Interpreter Core files: unreachable-code.diff messages: 57141 nosy: Paul Pogonyshev seve

[issue1385] hmac module violates RFC for some hash functions, e.g. sha512

Changes by Guido van Rossum: -- assignee: -> gregory.p.smith nosy: +gregory.p.smith __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mail

[issue1390] toxml generates output that is not well formed

Thomas Conway added the comment: Hi Martin, You write: It's not a bug in toxml, which should always serialize the DOM tree if possible. Right! In this case it is *not* possible. The generated serialization is not a well formed XML document. Having just consulted the DOM technical repor

[issue1384] Windows fix for inspect tests

Guido van Rossum added the comment: Shouldn't this use os.path.normcase() instead of testing for nt and using lower()? -- nosy: +gvanrossum __ Tracker <[EMAIL PROTECTED]> __ __

[issue1392] py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeError patch

Guido van Rossum added the comment: > It's sounds like a reasonable idea. But first I'm going to hit the down > with my gf and meet some friends. Cu later! No! You're not allowed to have a life! :-) (And no hacking drunk, either. :-) > PS: In my humble opinion Amaury Forgeot d'Arc deserves an

[issue1392] py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeError patch

Christian Heimes added the comment: Guido van Rossum wrote: > The error message is fine, though you could drop the word "Calling" > without loss of information. ;-) Also, most warnings don't seem to use > a trailing period. > > Perhaps you could expand this to also add a trap in the comparison >

[issue1392] py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeError patch

Guido van Rossum added the comment: The error message is fine, though you could drop the word "Calling" without loss of information. ;-) Also, most warnings don't seem to use a trailing period. Perhaps you could expand this to also add a trap in the comparison function when Py{String,Bytes} is c

[issue1393] function comparing lacks NotImplemented error

New submission from Paul Pogonyshev: I believe attached script demonstrates a bug in Python 3000. As far as I can tell, it should print four times 'True'. -- components: Interpreter Core files: test.py messages: 57135 nosy: Paul Pogonyshev severity: normal status: open title: function c

[issue1392] py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeError patch

Christian Heimes added the comment: I've made a patch with -b -> warning and -bb > type error. I'm not happy with the warning message. Maybe you've a better idea for it. Added file: http://bugs.python.org/file8697/py3k-pep3137_str_bytes_warning.patch __ Tracker <

[issue1392] py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeError patch

Christian Heimes added the comment: Guido van Rossum wrote: > Guido van Rossum added the comment: > > A compromise I could live with: add a command line option that makes it > a warning. Good idea. I can live with it, too. :) How do you like -b: issue warnings about str(bytes_instance) and str

[issue1392] py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeError patch

Guido van Rossum added the comment: A compromise I could live with: add a command line option that makes it a warning. __ Tracker <[EMAIL PROTECTED]> __

[issue1392] py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeError patch

Guido van Rossum added the comment: No -- making str(b) return b.decode("ascii") brings back the same issues we had with mindlessly mixing PyString and PyUnicode in 2.x. That was a major disaster. -- status: open -> __ Tracker <[EMAIL PROTECTED]>

[issue1388] py3k-pep3137: possible ref leak in ctypes

Changes by Christian Heimes: -- resolution: -> invalid status: open -> closed __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing li

[issue1388] py3k-pep3137: possible ref leak in ctypes

Thomas Heller added the comment: > $ ./python Lib/test/regrtest.py -R:: test_ctypes > test_ctypes > beginning 9 repetitions > 123456789 > . > test_ctypes leaked [-33, 0, 0, 0] references, sum=-33 > 1 test OK. > [101762 refs] Yes, I think this is ok. __ Tr

[issue1392] py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeError patch

Christian Heimes added the comment: New patch: static PyObject * string_str(PyObject *op) { return PyObject_CallMethod(op, "decode", "s", "ascii"); } Added file: http://bugs.python.org/file8696/py3k-pep3137_str_bytes_ascii.patch __ Tracker <[EMAIL PROTEC

[issue1392] py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeError patch

Christian Heimes added the comment: Guido van Rossum wrote: > I'll look at the patches later, but we've gone over this before on the > list. str() of *any* object needs to return *something*. Yes, it's > unfortunate that this masks bugs in the transitional period, but it > really is the best thin

[issue1392] py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeError patch

Guido van Rossum added the comment: I'll look at the patches later, but we've gone over this before on the list. str() of *any* object needs to return *something*. Yes, it's unfortunate that this masks bugs in the transitional period, but it really is the best thing in the long run. We had other

[issue1392] py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeError patch

Christian Heimes added the comment: Here is an updated patch that fixes an error in httplib that was causing the xmlrpc test suite to block. Added file: http://bugs.python.org/file8695/py3k-pep3137_remove_str_bytes2.patch __ Tracker <[EMAIL PROTECTED]>

[issue1392] py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeError patch

Christian Heimes added the comment: Err, please remove the (reprfunc) cast and check the language of the error messages, too :) __ Tracker <[EMAIL PROTECTED]> __ ___

[issue1392] py3k-pep3137: str(bytes()) and str(buffer()) should raise TypeError patch

New submission from Christian Heimes: str(bytes()) == repr(bytes()) and str(buffer()) == repr(buffer()) is causing a bunch bugs which are extremely hard to understand. On several occasions I didn't understand the problem until I removed a str() call or made str(bytes()) and str(buffer()) raise an

[issue1388] py3k-pep3137: possible ref leak in ctypes

Christian Heimes added the comment: Thomas Heller wrote: > Thomas Heller added the comment: > > ./python Lib/test/regrtest.py -R:: test_ctypes does not report a leak, > so I think there is no leak. I'm getting $ ./python Lib/test/regrtest.py -R:: test_ctypes test_ctypes beginning 9 repetitions

[issue1388] py3k-pep3137: possible ref leak in ctypes

Thomas Heller added the comment: ./python Lib/test/regrtest.py -R:: test_ctypes does not report a leak, so I think there is no leak. __ Tracker <[EMAIL PROTECTED]> __ __

[issue1193] os.system() encoding bug on Windows

Christian Heimes added the comment: Python 3.0 has many more problems at its boundaries to the system on Windows. Large parts of the API that deals with Windows system calls have to be rewritten in order to use the wide char API. -- keywords: +py3k nosy: +tiran priority: normal -> high r