[issue8825] int(0,0) throws exception
Mark Dickinson dicki...@gmail.com added the comment: Dino: I think Clark already did this: http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=27186 Sorry; I checked that there was an IronPython issue open before I closed this one, but forgot to mention it here. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8825 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8838] Remove codecs.readbuffer_encode() and codecs.charbuffer_encode()
Marc-Andre Lemburg m...@egenix.com added the comment: STINNER Victor wrote: New submission from STINNER Victor victor.stin...@haypocalc.com: readbuffer_encode() and charbuffer_encode() are not really encoder nor related to encodings: they are related to PyBuffer. readbuffer_encode() uses s# format and charbuffer_encode() uses t# format to parse their arguments. Both functions were introduced by the creation of the _codecs module 10 years ago (r14660). I think that these functions should be removed. memoryview() should be used instead. Note: charbuffer_encode() is the last function using on of the t format (t, t#, t*) in Python3. Those two encoder functions were meant to be used by Python codec implementations which want to use the readbuffer and charbuffer interfaces available in Python via s# and t# to access input object data. They are not used by the builtin codecs, but may well be in use by 3rd party codecs. I'm not sure why you think those functions are not encoders. -- nosy: +lemburg title: Remove codecs.readbuffer_encode() and codecs.charbuffer_encode() - Remove codecs.readbuffer_encode() andcodecs.charbuffer_encode() ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8838 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8839] PyArg_ParseTuple(): remove t# format
Marc-Andre Lemburg m...@egenix.com added the comment:
STINNER Victor wrote:
New submission from STINNER Victor victor.stin...@haypocalc.com:
t# format was introduced by r11803 (11 years ago): Implement new format
character 't#'. This is like s#, accepting an object that implements the
buffer interface, but requires a buffer that contains 8-bit character data.
Python3 now has a strict separation between byte string (bytes and bytearray
types) and unicode string (str), and has PyBuffer and PyCapsule APIs. t#
format can be replaced by y# or y*.
Extract of getarg.c:
/*TEO: This can be eliminated --- here only for backward
compatibility */
case 't': { /* 8-bit character buffer, read-only access */
In Python, the last function using t# is _codecs.charbuffer_encode() and I
proposed to remove this function in #8838. We can also patch this function.
I don't know if third party modules use this format or not. I don't know if
it can be just removed or if it should raise a deprecation warning (but who
will notice such warning since there are disabled by default?).
Since Python3 completely removed the getcharbuffer interface
to which the t# interfaces in Python2, t# does indeed no
longer serve any special purpose.
It's probably wise to just map t# to y# in order to ease
porting extensions from 2.x to 3.x.
--
nosy: +lemburg
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8839
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8839] PyArg_ParseTuple(): remove t# format
Marc-Andre Lemburg m...@egenix.com added the comment: STINNER Victor wrote: STINNER Victor victor.stin...@haypocalc.com added the comment: Patch to remove t#: - Update c-api/arg.rst documentation - Replace t# format by y# in codecs.charbuffer_encode() - Add a note in Doc/whatsnew/3.2.rst (in Porting to Python 3.2) Given that y# is not (yet) in wide-spread use, it may actually make more sense, to replace y# with t# and introduce t* to replace y*. y# and y* could then be setup as synonyms for t# and t*. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8839 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8839] PyArg_ParseTuple(): remove t# format
STINNER Victor victor.stin...@haypocalc.com added the comment: Given that y# is not (yet) in wide-spread use, ... t# is only used once (in codecs.charbuffer_encode()), whereas y# is used by ossaudiodev, socket and mmap modules (there are 8 functions using y#). There are 46 functions using y* format. y format is not used in Python3. To me, it looks easier to just drop t# and continue to use y, y* and y# formats in Python3. y# and y* could then be setup as synonyms for t# and t* If we have to keep backward compatibility, yes, t# can be kept as a synonym for y#. But I don't think that backward compatibility of the C API is important in Python3 because only few 3rd party modules are compatible with Python3. -- I prefer to use y, y* and y# formats because they target the *bytes* type (which is the Python3 type to store byte strings), whereas s# is used in Python2 to get text, *str* type.. which are byte strings, but most Python2 programmers consider that the str type is the type of chararacter string. I see the change of s# to y#, as the change from str to bytes (the strict separation between bytes and str). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8839 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8838] Remove codecs.readbuffer_encode() and codecs.charbuffer_encode()
STINNER Victor victor.stin...@haypocalc.com added the comment: Those two encoder functions were meant to be used by Python codec implementations which want to use the readbuffer and charbuffer interfaces available in Python via s# and t# to access input object data. Ah ok. They are not used by the builtin codecs, but may well be in use by 3rd party codecs. My quick Google search didn't found any of those. I suppose that str and bytes are enough for most people. Do you know an usecase of text or bytes stored in different types than str and bytes? (I suppose the bytearray is compatible with bytes, and so it can be used instead of bytes) I'm not sure why you think those functions are not encoders. I consider that Python3 codecs module only encode and decode text to/from an encoding, whereas Python2 had extra unrelated codecs like base64 or hex (but it was decided to remove them to cleanup the codecs module). -- title: Remove codecs.readbuffer_encode() andcodecs.charbuffer_encode() - Remove codecs.readbuffer_encode() and codecs.charbuffer_encode() ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8838 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8835] buildbot: support.transient_internet() doesn't catch DNS socket.gaierror
STINNER Victor victor.stin...@haypocalc.com added the comment: There is another error: test test_ssl failed -- Traceback (most recent call last): File /scratch/pybot-buildarea/trunk.klose-ubuntu-i386/build/Lib/test/test_ssl.py, line 261, in test_algorithms s.connect(remote) File /scratch/pybot-buildarea/trunk.klose-ubuntu-i386/build/Lib/ssl.py, line 292, in connect socket.connect(self, addr) File /scratch/pybot-buildarea/trunk.klose-ubuntu-i386/build/Lib/socket.py, line 222, in meth return getattr(self._sock,name)(*args) error: [Errno 110] Connection timed out transient_internet() should also catch socket.error(errno.ETIMEDOUT). -- See also #8455, #8499 and #8574. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8835 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8842] sqlite3 library outdated in Windows builds
New submission from Marko Kohtala marko.koht...@gmail.com: The Windows builds seem to come with SQLite library version 3.5.9, as seen from sqlite3.sqlite_version. This is from 2008-May-12. I've been using the sqlite3 module, but keep running into bugs on Windows. Replacing the DLLs\sqlite3.dll with a newer library (sqlite is going at version 3.6.23), seems to fix those problems. One problem was locking failures when performing a lot of changes and committing after each change. This happens within a single script accessing the file, apparently locking himself out. I did not want users needing to patch installed Python, so I got around that by removing the smaller commits and making one huge commit at end. Now I had a problem that ANALYZE does not result in good queries. Performing ANALYZE with newer library speeded queries significantly. I do not know how to get around that. On Linux I see Python 2.6 using sqlite 3.6.x versions, so I'd expect the reason for old library on Windows can not be incompatibility. -- components: Library (Lib), Windows messages: 106647 nosy: Marko.Kohtala priority: normal severity: normal status: open title: sqlite3 library outdated in Windows builds type: behavior versions: Python 2.6, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8842 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8839] PyArg_ParseTuple(): remove t# format
Marc-Andre Lemburg m...@egenix.com added the comment: STINNER Victor wrote: STINNER Victor victor.stin...@haypocalc.com added the comment: Given that y# is not (yet) in wide-spread use, ... t# is only used once (in codecs.charbuffer_encode()), whereas y# is used by ossaudiodev, socket and mmap modules (there are 8 functions using y#). There are 46 functions using y* format. y format is not used in Python3. To me, it looks easier to just drop t# and continue to use y, y* and y# formats in Python3. You are forgetting our main target: to get extension writers to port their extensions to Python3. Changes to the Python core are a lot easier to implement than getting thousands of extensions ported. t# is in wide-spread use, since it's the only way a Python2 extension can request access to an object's text data version. y# was introduced with Python3, and there are only very few extensions written for it. Given these facts, it's better to drop y# and replace it with t#. This is easily done for the core modules and by adding synonyms for y# we can also automatically take care of the few Python3 extensions possibly using it. y# and y* could then be setup as synonyms for t# and t* If we have to keep backward compatibility, yes, t# can be kept as a synonym for y#. But I don't think that backward compatibility of the C API is important in Python3 because only few 3rd party modules are compatible with Python3. True and that's why we have to make it easier for extension writer to port their extensions rather than making it harder. It is not too difficult to adjust a Python2 extension to work in Python3 as well, so that's most likely the route that many extension writer will take, hence the need to reduce the number of differences between the Python2 and Python3 C API. -- I prefer to use y, y* and y# formats because they target the *bytes* type (which is the Python3 type to store byte strings), whereas s# is used in Python2 to get text, *str* type.. which are byte strings, but most Python2 programmers consider that the str type is the type of chararacter string. I see the change of s# to y#, as the change from str to bytes (the strict separation between bytes and str). That's not correct: s# is used in Python2 to get at the bytes representation of an object, not the text version. t# was specifically added to access a text version of the content. In Python3, this distinction is no longer available (for whatever reason), so only the bytes representation of the object remains. Looking at the implementation again, I found that y# rejects Unicode, while s# returns the default encoded version like t# does in Python2. So I have to correct what I said earlier: y# is not the right replacement for t# in order to stay compatible with its Python2 pendant. The t# implementation in Python3 is not compatible with the Python2 approach - it's in fact, a totally different parser, since Unicode no longer provides a buffer interface and thus cannot be used as input for t#. The only compatible pendant to the Python2 t# parser marker in Python3 appears to be s#. I'll have to think about this some more, but seen in that light, removing t# in Python3 may actually be a better strategy after all - mostly to remove a misguided forward-porting attempt and to reduce the number of surprising extension writer will see when porting their apps to Python3. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8839 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8843] urllib2 Digest Authorization uri must match request URI
New submission from Andrew Nelis andrew.ne...@gmail.com: When using Digest authentication to authenticate with a web server, according to rfc2617 (section 3.2.2.5) the uri in the Authorization header MUST match the request URI. urllib2.AbstractDigestAuthHandler doesn't honour this when we request a url of the form 'http://hostname' without the trailing slash and we end up with request headers of the form: GET / 1.1 ... Authorization: Digest ... uri= - should be uri=/! A web server will return 400 Bad Request error. I attach a patch to fix urllib2.AbstractDigestAuthHandler.get_authorization that simply checks for the empty uri and uses '/' instead. It's the same thing that httplib.HTTPConnection does when it builds the GET line. However I do wonder if this uri normalisation should be part of Request.get_selector? Following is a script to demonstrate the behaviour, if you call it as: ./do_digest_request.py http://myserver username password (and assuming myserver is using Digest authentication) there will a 400 response instead of it working. --- do_digest_request.py #!/usr/bin/env python import sys import urllib2 import urlparse def request( url, username, password ): p = urlparse.urlparse( url ) password_manager = urllib2.HTTPPasswordMgrWithDefaultRealm() password_manager.add_password( None, p.hostname, username, password ) handlers = [ urllib2.HTTPDigestAuthHandler( password_manager ), ] opener = urllib2.build_opener( *handlers ) request = urllib2.Request( url ) response = opener.open( request ) response.read() if __name__ == '__main__': request( sys.argv[1], sys.argv[2], sys.argv[3] ) -- components: Library (Lib) files: urllib2.diff keywords: patch messages: 106649 nosy: anelis priority: normal severity: normal status: open title: urllib2 Digest Authorization uri must match request URI type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file17480/urllib2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8843 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8838] Remove codecs.readbuffer_encode() and codecs.charbuffer_encode()
Marc-Andre Lemburg m...@egenix.com added the comment: STINNER Victor wrote: STINNER Victor victor.stin...@haypocalc.com added the comment: Those two encoder functions were meant to be used by Python codec implementations which want to use the readbuffer and charbuffer interfaces available in Python via s# and t# to access input object data. Ah ok. They are not used by the builtin codecs, but may well be in use by 3rd party codecs. My quick Google search didn't found any of those. I suppose that str and bytes are enough for most people. Do you know an usecase of text or bytes stored in different types than str and bytes? (I suppose the bytearray is compatible with bytes, and so it can be used instead of bytes) Any Python object can expose a buffer interface and the above functions then allow accessing these interfaces from within Python. Think of e.g. memory mapped files, image/audio/video objects, database BLOBs, scientific data types, numeric arrays, etc. There are lots of such object types. I'm not sure why you think those functions are not encoders. I consider that Python3 codecs module only encode and decode text to/from an encoding, whereas Python2 had extra unrelated codecs like base64 or hex (but it was decided to remove them to cleanup the codecs module). Those codecs will be reenabled in Python 3.2. Removing them was a mistake. The codec machinery is not limited to only working on Unicode and bytes. It can work on arbitrary type combinations, depending on what a codec wants to implement. -- title: Remove codecs.readbuffer_encode() and codecs.charbuffer_encode() - Remove codecs.readbuffer_encode() andcodecs.charbuffer_encode() ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8838 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2920] Patch to print symbolic value or errno in EnvironmentError.__str__()
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: I don't like the import errno while printing an exception... It would be much more robust to store errorcode_dict in a static variable when python starts, and reuse it directly. -- nosy: +amaury.forgeotdarc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2920 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8839] PyArg_ParseTuple(): remove t# format
STINNER Victor victor.stin...@haypocalc.com added the comment: Le vendredi 28 mai 2010 13:30:22, vous avez écrit : Looking at the implementation again, I found that y# rejects Unicode, while s# returns the default encoded version like t# does in Python2. Oh, I didn't noticed that. So I have to correct what I said earlier: y# is not the right replacement for t# in order to stay compatible with its Python2 pendant. The t# implementation in Python3 is not compatible with the Python2 approach - it's in fact, a totally different parser, since Unicode no longer provides a buffer interface and thus cannot be used as input for t#. The only compatible pendant to the Python2 t# parser marker in Python3 appears to be s#. I'll have to think about this some more, but seen in that light, removing t# in Python3 may actually be a better strategy after all - mostly to remove a misguided forward-porting attempt and to reduce the number of surprising extension writer will see when porting their apps to Python3. So t#, s# and y# are all different. I'm waiting for your final decision. reduce the number of surprising extension writer ... is a good argument in favor of removing t# :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8839 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8838] Remove codecs.readbuffer_encode() and codecs.charbuffer_encode()
Antoine Pitrou pit...@free.fr added the comment:
Any Python object can expose a buffer interface and the above
functions then allow accessing these interfaces from within
Python.
What's the point? The codecs functions already support objects exposing the
buffer interface:
b = b\xe9
codecs.latin_1_decode(memoryview(b))
('é', 1)
codecs.latin_1_decode(array.array(b, b))
('é', 1)
Those two functions are undocumented. They serve no useful purpose (you can
call the bytes(...) constructor instead, or even use the buffer object directly
as showed above). They are badly named since they don't have anything to do
with codecs. Google Code Search shows them not appearing anywhere else than
implementations of the Python stdlib. Removing them only seems reasonable.
--
nosy: +loewis, pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8838
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2920] Patch to print symbolic value or errno in EnvironmentError.__str__()
Antoine Pitrou pit...@free.fr added the comment: Agreed with Amaury. Module import could fail for various reasons (perhaps the same ones which led to the exception being raised!), or could deadlock if the import lock is being held. Also, having __str__ fail is usually very annoying for users (especially when it's the __str__ of an exception object). If it's too hard to import errno at startup (because of bootstrapping), I would suggest using PyImport_ImportModuleNoBlock() instead, and silence errors (just print the numeric value of errno instead). -- nosy: +pitrou versions: +Python 2.7, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2920 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2920] Patch to print symbolic value or errno in EnvironmentError.__str__()
Alexander Belopolsky alexander.belopol...@gmail.com added the comment: The patch already checks for failed import and falls back to printing numerical error code. However, I don't like the import either. I will think about the alternatives. On May 28, 2010, at 8:27 AM, Antoine Pitrou rep...@bugs.python.org wrote: Antoine Pitrou pit...@free.fr added the comment: Agreed with Amaury. Module import could fail for various reasons (perhaps the same ones which led to the exception being raised!), or could deadlock if the import lock is being held. Also, having __str__ fail is usually very annoying for users (especially when it's the __str__ of an exception object). If it's too hard to import errno at startup (because of bootstrapping), I would suggest using PyImport_ImportModuleNoBlock() instead, and silence errors (just print the numeric value of errno instead). -- nosy: +pitrou versions: +Python 2.7, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2920 ___ -- nosy: +Alexander.Belopolsky ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2920 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8838] Remove codecs.readbuffer_encode() and codecs.charbuffer_encode()
Marc-Andre Lemburg m...@egenix.com added the comment:
Antoine Pitrou wrote:
Antoine Pitrou pit...@free.fr added the comment:
Any Python object can expose a buffer interface and the above
functions then allow accessing these interfaces from within
Python.
What's the point? The codecs functions already support objects exposing the
buffer interface:
b = b\xe9
codecs.latin_1_decode(memoryview(b))
('é', 1)
codecs.latin_1_decode(array.array(b, b))
('é', 1)
Those two functions are undocumented. They serve no useful purpose (you can
call the bytes(...) constructor instead, or even use the buffer object
directly as showed above). They are badly named since they don't have
anything to do with codecs. Google Code Search shows them not appearing
anywhere else than implementations of the Python stdlib. Removing them only
seems reasonable.
readbuffer_encode and charbuffer_encode convert objects to bytes
and provide a codec encoder interface for this, hence the naming.
They are meant to be used as encode methods for codecs, just like
the other *_encode functions exposed in the _codecs module, e.g.
class BinaryDataCodec(codecs.Codec):
# Note: Binding these as C functions will result in the class not
# converting them to methods. This is intended.
encode = codecs.readbuffer_encode
decode = codecs.latin_1_decode
While it's possible to emulate the functions via other methods,
these methods always introduce intermediate objects, which isn't
necessary and only costs performance.
Given than t# was basically rendered useless in Python3 (see
issue8839), removing charbuffer_encode() is indeed possible,
so
+1 on removing charbuffer_encode()
-1 on removing readbuffer_encode()
--
title: Remove codecs.readbuffer_encode() andcodecs.charbuffer_encode() -
Remove codecs.readbuffer_encode() and codecs.charbuffer_encode()
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8838
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8838] Remove codecs.readbuffer_encode() and codecs.charbuffer_encode()
Éric Araujo mer...@netwok.org added the comment: I’d be grateful if someone could post links to discussion about the removal of codecs like hex and rot13 and about their coming back. It may be useful for a NEWS entry too, not just for my personal curiosity ;) I’ll try to find them next week or so if nobody posts them before. Thanks. -- nosy: +merwok ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8838 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8838] Remove codecs.readbuffer_encode() and codecs.charbuffer_encode()
Antoine Pitrou pit...@free.fr added the comment: class BinaryDataCodec(codecs.Codec): # Note: Binding these as C functions will result in the class not # converting them to methods. This is intended. encode = codecs.readbuffer_encode decode = codecs.latin_1_decode What's the point, though? Creating a non-symmetrical codec doesn't sound like a very useful or recommandable thing to do. Especially in the py3k codec model where encode() only works on unicode objects. While it's possible to emulate the functions via other methods, these methods always introduce intermediate objects, which isn't necessary and only costs performance. The bytes() constructor doesn't (shouldn't) create any more intermediate objects than read/charbuffer_encode() do. And all this doesn't address the fact that these functions have never been documented, and don't seem used in the outside world (understandably so, since there's no way to know about their existence, and their intended use). -- title: Remove codecs.readbuffer_encode()and codecs.charbuffer_encode() - Remove codecs.readbuffer_encode() and codecs.charbuffer_encode() ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8838 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8838] Remove codecs.readbuffer_encode() and codecs.charbuffer_encode()
STINNER Victor victor.stin...@haypocalc.com added the comment: I’d be grateful if someone could post links to discussion about the removal of codecs like hex and rot13 r55932 (~3 years ago): Rip out all codecs that can't work in a unicode/bytes world: base64, uu, zlib, rot_13, hex, quopri, bz2, string_escape. However codecs.escape_encode() and codecs.escape_decode() still exist, as they are used for pickling str8 objects (so those two functions can go, when the str8 type is removed). There were removed 1 year and an half before Python 3.0 release. ... and about their coming back which coming back? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8838 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8838] Remove codecs.readbuffer_encode() and codecs.charbuffer_encode()
Éric Araujo mer...@netwok.org added the comment: Thanks for the link. Do you have a pointer to the PEP or ML thread discussing that change? “Which coming back?” Martin said these codecs are coming back in 3.2. -- title: Remove codecs.readbuffer_encode()and codecs.charbuffer_encode() - Remove codecs.readbuffer_encode() and codecs.charbuffer_encode() ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8838 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8843] urllib2 Digest Authorization uri must match request URI
Changes by Antoine Pitrou pit...@free.fr: -- assignee: - orsenthil nosy: +orsenthil stage: - patch review versions: +Python 2.6, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8843 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8839] PyArg_ParseTuple(): remove t# format
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8839 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8838] Remove codecs.readbuffer_encode() and codecs.charbuffer_encode()
STINNER Victor victor.stin...@haypocalc.com added the comment: Martin said these codecs are coming back in 3.2. Oh, there is the issue #7485 where Martin wrote: * 2009-12-10 23:15: It was a mistake that they were integrated * 2009-12-12 19:25: I would still be opposed to such a change (...) adding them would be really confusing. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8838 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7475] codecs missing: base64 bz2 hex zlib ...
Changes by STINNER Victor victor.stin...@haypocalc.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7475 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8838] Remove codecs.readbuffer_encode() and codecs.charbuffer_encode()
Walter Dörwald wal...@livinglogic.de added the comment: I’d be grateful if someone could post links to discussion about the removal of codecs like hex and rot13 r55932 (~3 years ago): That was my commit. ;) Thanks for the link. Do you have a pointer to the PEP or ML thread discussing that change? The removal is documented here: http://www.artima.com/weblogs/viewpost.jsp?thread=208549 We are adopting a slightly different approach to codecs: while in Python 2, codecs can accept either Unicode or 8-bits as input and produce either as output, in Py3k, encoding is always a translation from a Unicode (text) string to an array of bytes, and decoding always goes the opposite direction. This means that we had to drop a few codecs that don't fit in this model, for example rot13, base64 and bz2 (those conversions are still supported, just not through the encode/decode API). A post by Georg Brandl about this is at http://mail.python.org/pipermail/python-3000/2007-June/008420.html (Note that this thread began in private email between Guido, MvL, Georg and myself. If needed I can dig up the emails.) -- nosy: +doerwalter ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8838 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8838] Remove codecs.readbuffer_encode() and codecs.charbuffer_encode()
Marc-Andre Lemburg m...@egenix.com added the comment: Antoine Pitrou wrote: Antoine Pitrou pit...@free.fr added the comment: class BinaryDataCodec(codecs.Codec): # Note: Binding these as C functions will result in the class not # converting them to methods. This is intended. encode = codecs.readbuffer_encode decode = codecs.latin_1_decode What's the point, though? Creating a non-symmetrical codec doesn't sound like a very useful or recommandable thing to do. Why not ? If you're only interested in the binary data and don't care about the original input object type, that's a very natural thing to do. E.g. you could use a memory mapped file as input to the encoder. Would you really expect the codec to recreate such a file object when decoding the binary data ? Especially in the py3k codec model where encode() only works on unicode objects. That's a common misunderstanding. The codec system does not mandate a specific type combination. Only the helper methods .encode() and .decode() on bytes and str objects in Python3 do. While it's possible to emulate the functions via other methods, these methods always introduce intermediate objects, which isn't necessary and only costs performance. The bytes() constructor doesn't (shouldn't) create any more intermediate objects than read/charbuffer_encode() do. Looking at the code, the data takes quite a long path through the whole machinery. For non-Unicode objects, it always tries to create an integer and only if that fails reverts back to the buffer interface after a few more function calls. Furthermore, the bytes() constructor accepts a lot more objects than the s# parser marker, e.g. lists of integers, plain integers, arbitrary iterators, which a codec just interested in the binary representation of an object via the buffer interface most likely doesn't want to accept. And all this doesn't address the fact that these functions have never been documented, and don't seem used in the outside world (understandably so, since there's no way to know about their existence, and their intended use). That's a documentation bug and probably the result of the fact that none of the exposed encoder/decoder APIs are documented. -- title: Remove codecs.readbuffer_encode() and codecs.charbuffer_encode() - Remove codecs.readbuffer_encode()and codecs.charbuffer_encode() ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8838 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8838] Remove codecs.readbuffer_encode() and codecs.charbuffer_encode()
STINNER Victor victor.stin...@haypocalc.com added the comment: Oh, there is the issue #7485 where Martin wrote: Copy/paste failure: issue #7475. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8838 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8838] Remove codecs.readbuffer_encode() and codecs.charbuffer_encode()
Marc-Andre Lemburg m...@egenix.com added the comment: STINNER Victor wrote: Martin said these codecs are coming back in 3.2. I said that and it was discussed on the python-dev mailing list a while back. We'll also add .transform() methods on bytes and str objects to access same-type codecs. -- title: Remove codecs.readbuffer_encode()and codecs.charbuffer_encode() - Remove codecs.readbuffer_encode() and codecs.charbuffer_encode() ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8838 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8838] Remove codecs.readbuffer_encode() and codecs.charbuffer_encode()
STINNER Victor victor.stin...@haypocalc.com added the comment: readbuffer_encode() and charbuffer_encode() are not really encoder nor related to encodings: they are related to PyBuffer That was the initial problem: codecs is specific to encodings (in Python3), encodes str to bytes, and decodes bytes (or any read buffer) to str. I don't like readbuffer_*encode* and *charbuffer_encode* function names, because there are different than other codecs: they encode *bytes* to bytes (and not str to bytes). I think that these functions should be removed or moved somewhere else under a different name. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8838 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8838] Remove codecs.readbuffer_encode() and codecs.charbuffer_encode()
Antoine Pitrou pit...@free.fr added the comment: And all this doesn't address the fact that these functions have never been documented, and don't seem used in the outside world (understandably so, since there's no way to know about their existence, and their intended use). That's a documentation bug and probably the result of the fact that none of the exposed encoder/decoder APIs are documented. Are you planning to fix it? It is not obvious anybody else is able to properly document those functions. -- title: Remove codecs.readbuffer_encode() andcodecs.charbuffer_encode() - Remove codecs.readbuffer_encode() and codecs.charbuffer_encode() ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8838 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8842] sqlite3 library outdated in Windows builds
Brian Curtin cur...@acm.org added the comment: SQLite was upgraded to 3.6.21 about 4 months ago for 2.7 and 3.2. -- nosy: +brian.curtin resolution: - out of date status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8842 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7475] codecs missing: base64 bz2 hex zlib ...
STINNER Victor victor.stin...@haypocalc.com added the comment: I agree with Martin: codecs choosed the wrong direction in Python2, and it's fixed in Python3. The codecs module is related to charsets (encodings), should encode str to bytes, and should decode bytes (or any read buffer) to str. Eg. rot13 encodes str to str. base64 bz2 hex zlib ...: use base64, bz2, binascii and zlib modules for that. The documentation should be fixed (explain how to port code from Python2 to Python3). It's maybe possible for write some 2to3 fixers for the following examples: encode(base64) = base64.b64encode(...) encode(rot13) = do nothing (but display a warning?) encode(zlib) = zlib.compress(...) encode(hex) = base64.b16encode(...) encode(bz2) = bz2.compress(...) decode(base64) = base64.b64decode(...) decode(rot13) = do nothing (but display a warning?) decode(zlib) = zlib.decompress(...) decode(hex) = base64.b16decode(...) decode(bz2) = bz2.decompress(...) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7475 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7475] codecs missing: base64 bz2 hex zlib ...
STINNER Victor victor.stin...@haypocalc.com added the comment: Explanation the change in Python3 by Guido: We are adopting a slightly different approach to codecs: while in Python 2, codecs can accept either Unicode or 8-bits as input and produce either as output, in Py3k, encoding is always a translation from a Unicode (text) string to an array of bytes, and decoding always goes the opposite direction. This means that we had to drop a few codecs that don't fit in this model, for example rot13, base64 and bz2 (those conversions are still supported, just not through the encode/decode API). http://www.artima.com/weblogs/viewpost.jsp?thread=208549 -- See also issue #8838. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7475 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4015] [patch] make installed scripts executable on windows
Per pybugs.pho...@safersignup.com added the comment: On POSIX the interpreter will be read from the first line of a file. On Windows the interpreter will be read from the Registry HKEY_CLASSES_ROOT\.file-extension . So the correct way to associate a interpreter to a file is to invent a file-extension for every interpreter. Like /usr/bin/python /usr/bin/python3 and /usr/bin/python3.1 on POSIX, there should be .py .py3 and .py31 on Windows! I attached a example-registry-patch to register extensions for 2.5, 2.6 and 3.1 . If you want to use it, you need to adjust the paths! I propose to change all Python-Windows-installer to install versioned extensions. If you want a switcher application, it should read the first line of the script and match it against .*/python(.*)$. So the default POSIX #!/usr/bin/python3.1 can be kept unchanged. With that rexex the app-path can be read from HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\regex-match\InstallPath\. BTW. It would be nice if Python would call itself Python 3.1 instead of python in the Open with...-list! The current naming is problematic if you install more than one Python version. -- nosy: +phobie Added file: http://bugs.python.org/file17481/hklm_python_extensions.reg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4015 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8838] Remove codecs.readbuffer_encode() and codecs.charbuffer_encode()
Éric Araujo mer...@netwok.org added the comment: I don't like readbuffer_*encode* and *charbuffer_encode* function names, because there are different than other codecs “transform” as hinted by MvL seems perfect. Thanks everyone for the pointers here and in #7475! I’ll search the missing one (“it was discussed on the python-dev mailing list a while back”) later. -- title: Remove codecs.readbuffer_encode()and codecs.charbuffer_encode() - Remove codecs.readbuffer_encode() and codecs.charbuffer_encode() ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8838 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4015] [patch] make installed scripts executable on windows
Éric Araujo mer...@netwok.org added the comment: Related to #870479 (should we make that one a meta-bug?) -- nosy: +merwok ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4015 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7475] codecs missing: base64 bz2 hex zlib ...
Marc-Andre Lemburg m...@egenix.com added the comment: STINNER Victor wrote: STINNER Victor victor.stin...@haypocalc.com added the comment: I agree with Martin: codecs choosed the wrong direction in Python2, and it's fixed in Python3. The codecs module is related to charsets (encodings), should encode str to bytes, and should decode bytes (or any read buffer) to str. No, that's just not right: the codec system in Python does not mandate the types used or accepted by the codecs. The only change that was applied in Python3 was to make sure that the str.encode() and bytes.decode() methods always return the same type to assure type-safety. Python2 does not apply that check, but instead provides a direct interface to codecs.encode() and codecs.decode(). Please don't mix the helper methods on those objects with what the codec system was designed for. The helper methods apply a strategy that's more constrained than the codec system. The addition of .transform() and .untransform() for same type conversions was discussed in 2008, but didn't make it into 3.0 since I hadn't had time to add the methods: http://mail.python.org/pipermail/python-3000/2008-August/014533.html http://mail.python.org/pipermail/python-3000/2008-August/014533.html http://mail.python.org/pipermail/python-3000/2008-August/014534.html The removed codecs don't rely on the helper methods in any way. They are easily usable via codecs.encode() and codecs.decode() even without .transform() and .untransform(). Esp. the hex codec is very handy and at least in our eGenix code base in wide-spread use. Using a single well-defined interface to such encodings is just much more user friendly than having to research the different APIs for each of them. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7475 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7475] codecs missing: base64 bz2 hex zlib ...
Changes by Éric Araujo mer...@netwok.org: -- nosy: +merwok ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7475 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1759169] clean up Solaris port and allow C99 extension modules
Martin v. Löwis mar...@v.loewis.de added the comment: Thanks for the patch. Committed as r81582 and r81583. Antoine was right: subsequent references to Solaris needed to be removed also. -- resolution: - accepted status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1759169 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1100562] deepcopying listlike and dictlike objects
Changes by Ryan Coyner rcoy...@gmail.com: -- nosy: +rcoyner ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1100562 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8713] multiprocessing needs option to eschew fork() under Linux
Changes by Ryan Coyner rcoy...@gmail.com: -- nosy: +rcoyner ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8713 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8405] Improve test_os._kill (failing on slow machines)
Brian Curtin cur...@acm.org added the comment: Committed to trunk in r81584 and py3k in r81585. -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8405 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8405] Improve test_os._kill (failing on slow machines)
STINNER Victor victor.stin...@haypocalc.com added the comment: Committed to trunk in r81584 and py3k in r81585 sparc solaris10 gcc trunk buildbot slave doesn't compile anymore. I'm not sure that it's related, so I prefer to not reopen the issue :-) http://www.python.org/dev/buildbot/trunk/builders/sparc%20solaris10%20gcc%20trunk/builds/891 --- ... building '_struct' extension gcc -fPIC -fno-strict-aliasing -g -O2 -g -O0 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/usr/local/include -I/home2/buildbot/slave/trunk.loewis-sun/build/Include -I/home2/buildbot/slave/trunk.loewis-sun/build -c /home2/buildbot/slave/trunk.loewis-sun/build/Modules/_struct.c -o build/temp.solaris-2.10-sun4u-2.7-pydebug/home2/buildbot/slave/trunk.loewis-sun/build/Modules/_struct.o gcc -shared build/temp.solaris-2.10-sun4u-2.7-pydebug/home2/buildbot/slave/trunk.loewis-sun/build/Modules/_struct.o -L/usr/local/lib -o build/lib.solaris-2.10-sun4u-2.7-pydebug/_struct.so Assertion failed: min = 0, file Python/getargs.c, line 1826 *** Error code 134 The following command caused the error: case $MAKEFLAGS in \ *s*) CC='gcc' LDSHARED='gcc -shared' LDFLAGS='' OPT='-g -O0 -Wall -Wstrict-prototypes' ./python -E ./setup.py -q build;; \ *) CC='gcc' LDSHARED='gcc -shared' LDFLAGS='' OPT='-g -O0 -Wall -Wstrict-prototypes' ./python -E ./setup.py build;; \ esac make: Fatal error: Command failed for target `sharedmods' program finished with exit code 1 --- -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8405 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8844] Condition.wait() doesn't raise KeyboardInterrupt
New submission from Mike Hobbs mho...@alvenda.com: Condition.wait() without a timeout will never raise a KeyboardInterrupt: cond = threading.Condition() cond.acquire() cond.wait() *** Pressing Ctrl-C now does nothing *** If you pass a timeout to Condition.wait(), however, it does behave as expected: cond.wait() ^CTraceback (most recent call last): File /usr/lib/python3.1/threading.py, line 242, in wait _sleep(delay) KeyboardInterrupt This may affect other problems reported with multiprocessing pools. Most notably: http://bugs.python.org/issue8296 http://stackoverflow.com/questions/1408356 -- components: Library (Lib) messages: 106678 nosy: hobb0001 priority: normal severity: normal status: open title: Condition.wait() doesn't raise KeyboardInterrupt type: behavior versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8844 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4015] [patch] make installed scripts executable on windows
anatoly techtonik techto...@gmail.com added the comment: This issue is so old and I do not have time to reread it fully, unfortunately. I believe I wanted to install packages using easy_install, pip or whatever I have and get Scripts/something.bat for my version of Python. This version is often portable, so registry dependency it is not an option - not a good version at least. Scripts/ can also be located in virtualenv. The similar patch is used for deploying SCons on Windows. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4015 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8844] Condition.wait() doesn't raise KeyboardInterrupt
Antoine Pitrou pit...@free.fr added the comment: In 3.2, even using a timeout doesn't make the call interruptible. The solution would be to fix the internal locking APIs so that they handle incoming signals properly, and are able to return an error status. -- nosy: +gregory.p.smith, jyasskin, pitrou, rnk versions: +Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8844 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8834] Define order of Misc/ACKS entries
Brett Cannon br...@python.org added the comment: LGTM as well. -- nosy: +brett.cannon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8834 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8835] buildbot: support.transient_internet() doesn't catch DNS socket.gaierror
Antoine Pitrou pit...@free.fr added the comment: I commited the patch as r81571 in trunk. Apparently it's ok. -- assignee: - haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8835 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8845] Expose sqlite3 connection inTransaction as read-only in_transaction attribute
New submission from R. David Murray rdmur...@bitdance.com: I have a use case where I'd like to be able to check whether or not there is an uncommitted transaction. The use case is a REPL database editor. If the user issues the 'save' command a commit is done. When they quit the application, I'd like to be able to prompt them with a 'save or discard' if and only if they have made changes since the last save. Exposing the connection's inTransaction attribute would allow me to do this. The attached patch does this as a read only attribute named in_transaction. I'll add unit tests if this idea isn't rejected. -- components: Extension Modules files: sqlite.in_transaction.patch keywords: easy, patch messages: 106683 nosy: ghaering, r.david.murray priority: normal severity: normal stage: unit test needed status: open title: Expose sqlite3 connection inTransaction as read-only in_transaction attribute type: feature request versions: Python 3.2 Added file: http://bugs.python.org/file17482/sqlite.in_transaction.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8845 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8845] Expose sqlite3 connection inTransaction as read-only in_transaction attribute
Changes by Shashwat Anand anand.shash...@gmail.com: -- nosy: +l0nwlf ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8845 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6560] socket sendmsg(), recvmsg() methods
David Watson bai...@users.sourceforge.net added the comment: Here is a new version of the patch; I've added some tests which use the RFC 3542 interface (IPv6 advanced API) and am now quite happy with it generally. As well as Linux, I've tested it on an old (unsupported) FreeBSD 5.3 installation, which required a few changes in the tests and the code, but is probably representative of many socket implementations. Testing on other systems would be appreciated! The main issue was that when truncating ancillary data, FreeBSD seemed to just copy as much into the buffer as would fit and did not adjust the last item's cmsg_len member to reflect the amount of data that was actually present, so the item would appear to extend past the end of the buffer. The last version of the patch detected this and raised RuntimeError, which prevented any truncated receives from succeeding. The new version instead issues a warning and returns as much of the last item as is in the buffer. The warning could perhaps be disabled for systems like this, given that it happens every time ancillary data is truncated, but truncation generally shouldn't happen in a program's normal operation, and on other platforms a bad cmsg_len value might indicate that the returned data is actually incorrect in some way. After some investigation, I've stuck with using CMSG_FIRSTHDR() and CMSG_NXTHDR() to step through the headers when assembling the ancillary data in sendmsg(). The KAME IPv6 userspace utilities at [1] include several programs which send multiple control messages at once, and these always use CMSG_NXTHDR() to advance to the next uninitialized header, while some (but not all) of them zero-fill the buffer beforehand, suggesting they ran into the issue with glibc's macros returning NULL (KAME developed the BSD IPv6 stack, and the zero-filling isn't necessary with the BSD macros). The alternative would be to add CMSG_SPACE(size) to the pointer to get to the next header. Going by the diagram in RFC 3542, that should be equivalent, but if some system defined CMSG_SPACE(len) as, say, CMSG_LEN(len) + 3, instead of (CMSG_LEN(len) + 3) ~3, it would probably go unnoticed until someone tried to use CMSG_SPACE() that way. So given the KAME example, I think using CMSG_NXTHDR() with a zero-filled buffer is the way to go. [1] http://www.kame.net/dev/cvsweb2.cgi/kame/kame/kame/ -- Added file: http://bugs.python.org/file17483/baikie-hwundram-v3.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6560 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8844] Condition.wait() doesn't raise KeyboardInterrupt
Antoine Pitrou pit...@free.fr added the comment: 3.2 is interesting in that it introduces a new internal API: PyThread_acquire_lock_timed(). We can therefore change that API again before release without risking any compatibility breakage. Reid, would you want to work on this? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8844 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6560] socket sendmsg(), recvmsg() methods
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +haypo stage: - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6560 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8845] Expose sqlite3 connection inTransaction as read-only in_transaction attribute
Shashwat Anand anand.shash...@gmail.com added the comment: Tested this patch, works perfectly fine. Also it suits for the particular use case which David mentioned where there is no better alternate approach. -- Added file: http://bugs.python.org/file17484/dbapi.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8845 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8845] Expose sqlite3 connection inTransaction as read-only in_transaction attribute
Jean-Paul Calderone exar...@twistedmatrix.com added the comment: If the user issues the 'save' command a commit is done. When they quit the application, I'd like to be able to prompt them with a 'save or discard' if and only if they have made changes since the last save. Isn't this the same as if they have issued any non-SELECT statements? And isn't that pretty easy to track? (Not that I'm opposed to making the SQLite3 wrapper more complete.) -- nosy: +exarkun ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8845 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8845] Expose sqlite3 connection inTransaction as read-only in_transaction attribute
Changes by Shashwat Anand anand.shash...@gmail.com: Removed file: http://bugs.python.org/file17484/dbapi.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8845 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8845] Expose sqlite3 connection inTransaction as read-only in_transaction attribute
Shashwat Anand anand.shash...@gmail.com added the comment:
conn = sqlite3.connect('dbdump.sqlite')
c = conn.cursor()
conn.in_transaction
False
c.execute('CREATE TABLE foo (id integer, name text)')
sqlite3.Cursor object at 0x1004a7730
conn.in_transaction
False
It gives True for Insert and False for Select. perfect Ok. However It should
give True when we Create tables ?
Adding unit-test which upon showing this behavior fails the test.
--
Added file: http://bugs.python.org/file17485/dbapi.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8845
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8845] Expose sqlite3 connection inTransaction as read-only in_transaction attribute
R. David Murray rdmur...@bitdance.com added the comment: @exarkun: yes, but since the module is already tracking that information, it seems silly to duplicate it in my code, especially since that duplication could include data-losing bugs. @l0nwlf: its behaviour is in accord with the module documentation, which talks about the fact that issuing a create statement (for example) commits the current transaction. So in_transaction is an accurate representation of what sqlite3 is actually doing. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8845 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8845] Expose sqlite3 connection inTransaction as read-only in_transaction attribute
Changes by Shashwat Anand anand.shash...@gmail.com: Removed file: http://bugs.python.org/file17485/dbapi.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8845 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8845] Expose sqlite3 connection inTransaction as read-only in_transaction attribute
Shashwat Anand anand.shash...@gmail.com added the comment: Ok then. Uploading unit-test which takes value of in_transaction as False after issuing a Create statement. It passes with the patch applied. -- Added file: http://bugs.python.org/file17486/dbapi.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8845 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8846] cgi.py bug report + fix: tailing carriage return and newline characters in multipart cgi input broken
New submission from Andre Wobst wob...@users.sourceforge.net: There are serious bugs in carriage return and newline handling at the end of a multipart cgi input. The enclosed patch extends the test_cgi.py (and actually reverts two wrong tests to what they had been for python2.x). Additionally, the bugs are fixed by two small corrections to cgi.py and email/feedparser.py. Thanks for consideration. -- components: Library (Lib) files: fix-cgi.patch keywords: patch messages: 106691 nosy: wobsta priority: normal severity: normal status: open title: cgi.py bug report + fix: tailing carriage return and newline characters in multipart cgi input broken versions: Python 3.3 Added file: http://bugs.python.org/file17487/fix-cgi.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8846 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8846] cgi.py bug report + fix: tailing carriage return and newline characters in multipart cgi input broken
Changes by Andre Wobst wob...@users.sourceforge.net: -- type: - behavior versions: +Python 3.1 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8846 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8837] PyArg_ParseTuple(): remove old and unused O? format
STINNER Victor victor.stin...@haypocalc.com added the comment: Commited: r81588 (py3k), blocked in 3.1 (r81589). -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8837 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8838] Remove codecs.readbuffer_encode() and codecs.charbuffer_encode()
Martin v. Löwis mar...@v.loewis.de added the comment: Martin said these codecs are coming back in 3.2. I think you are confusing me with MAL. I remain opposed to adding them back. Users ought to use the modules that provide these these conversions as functions. -- title: Remove codecs.readbuffer_encode() and codecs.charbuffer_encode() - Remove codecs.readbuffer_encode() andcodecs.charbuffer_encode() ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8838 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8845] Expose sqlite3 connection inTransaction as read-only in_transaction attribute
Martin v. Löwis mar...@v.loewis.de added the comment: The patch lacks documentation. Otherwise, I think it's fine. -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8845 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8847] crash appending list and namedtuple
New submission from benrg benrud...@gmail.com:
c:\python
Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit (Intel)]
on win32
Type help, copyright, credits or license for more information.
from collections import namedtuple
foo = namedtuple('foo', '')
[1] + foo()
At this point the interpreter crashes. Also happens when foo has named
arguments, and in batch scripts. foo() + [1] throws a TypeError as expected. []
+ foo() returns (). The immediate cause of the crash is the CALL instruction at
1E031D5A in python31.dll jumping into uninitialized memory.
--
components: Interpreter Core, Library (Lib), Windows
messages: 106695
nosy: benrg
priority: normal
severity: normal
status: open
title: crash appending list and namedtuple
type: crash
versions: Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8847
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8840] io.StringIO: truncate+print disabled in 3.1.2
Terry J. Reedy tjre...@udel.edu added the comment: This should not have been closed yet. The announced policy is that bugfix releases should not add or change APIs. I think this hidden change (there is no What' New in 3.1.2 doc) should be reverted in 3.1.3. I will post on py-dev for other opinions. That aside, I think both the current behavior and docs are buggy and should be changed for 3.2 (and 3.1.3 if not reverted). 1. If the file pointer is not moved, then it seems to me that line 3 of my example output should have been '\0\0\0\0' instead of ''. The current behavior is '' + 'abc\n' == '\0\0\0\0abc\n', which is not sane. Maybe .getvalue() needs to be changed. It is hard to further critique the observed behavior since the intent is, to me, essentially undocumented. 2. The current 3.1.2/3.2a0 manual entry truncate(size=None) Truncate the file to at most size bytes. size defaults to the current file position, as returned by tell(). Note that the current file position isn’t changed; if you want to change it to the new end of file, you have to seek() explicitly. has several problems. a. 'file' should be changed to 'stream' to be consistent with other entries. b. If truncate the file to at most size bytes does not mean 'change the steam position', then I have no idea what it is supposed to mean, or what .truncate is actually supposed to do. c. There is no mention that what is does do is to replace existing chars with null chars. (And the effect of that is/should be different in Python than in C.) d. There is no mention of the return value and what *it* is supposed to mean. 3. The current 3.1.2 (and I presume, 3.2a0) doc string (help entry) truncate(...) Truncate size to pos. The pos argument defaults to the current file position, as returned by tell(). The current file position is unchanged. Returns the new absolute position. also has problems. a. Same change of 'file' to 'stream'. b. I already commented on ... and 'truncate size to pos', but to be consistent with the manual, the arg should be called 'size' rather that 'pos', or vice verse. c. 'truncate' does not define the meaning of 'truncate', especially when it no longer means what a native English speaker would expect it to mean. d. To me, 'the *new* absolute position' contradicts 'The current file position is *unchanged*' [emphases added]. Is there some subtle, undocumented, distinction between 'absolute position' and 'file [stream] position'? In any case, .truncate(0) returns 0, which seems to become the new position for .getvalue() but not for appending chars with print. To me, having *two* steams positions for different functions is definitely a bug. 4. There is no mention of a change to .truncate in What's New in Python 3.2. After searching more, I see that the change was discussed in #6939, by only two people. I see no justification there for changing 3.1 instead of waiting for 3.2. The OP suggested in his initial message, as I do here, that the doc say something about what .truncate does do with respect to padding, but that did not happen. -- resolution: rejected - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8840 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7593] Computed-goto patch for RE engine
Changes by Chris Leary christopher.le...@cornell.edu: -- nosy: +cdleary ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7593 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8215] getargs.c in Python3 contains some TODO and the documentation is outdated
STINNER Victor victor.stin...@haypocalc.com added the comment: Patch to cleanup getbuffer() and convertbuffer(): - getbuffer() doesn't call convertbuffer() if pb-bf_getbuffer==NULL. If pb-bf_getbuffer==NULL, PyObject_GetBuffer() fails and so the call to convertbuffer() is useless. - convertbuffer() calls getbuffer() to check that the buffer is 'C contiguous (and to factorize the code) - release the buffer if the buffer is not contigous = fix a bug - rename errmsg and buf to expected to reuse converterror() term - Remove /* XXX Really? */: I don't understand the comment and the code looks ok The main change is that convertbuffer() now requires a C contiguous buffer. That change concerns s#, y, z and t# formats. If a function would like to support non contiguous buffers, it should use O format and then PyObject_GetBuffer(). I don't think that builtin Python functions do support non contiguous buffers. -- keywords: +patch Added file: http://bugs.python.org/file17488/getarg_cleanup_buffer.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8215 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8848] Remove U and U# formats of Py_BuildValue()
New submission from STINNER Victor victor.stin...@haypocalc.com: U and U# formats were introduced by r55433 (Python3). At this same, s and U formats were different: s called PyString_FromStringAndSize() and U called PyUnicode_FromStringAndSize(). Two months later, PyString_FromStringAndSize() was replaced by PyUnicode_FromStringAndSize() for format s, and so both formats are exactly the same. U and U# were introduced during the transition between bytes, str and unicode. They can now be replaced by s and s#, and then be removed. There is just one usage of U: definition of sys.subversion (Python/sysmodule.c), whereas there are 36 usages of s format. (U# and s# are not used.) -- components: Interpreter Core messages: 106700 nosy: doerwalter, haypo priority: normal severity: normal status: open title: Remove U and U# formats of Py_BuildValue() versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8848 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2516] Instance methods are misreporting the number of arguments
Changes by Rodrigo Bernardo Pimentel r...@isnomore.net: -- nosy: +rbp ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2516 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8850] Remove w format of PyParse_ParseTuple()
New submission from STINNER Victor victor.stin...@haypocalc.com: w format is dangerous because it doesn't give the size of the buffer: the caller may write outside the buffer (buffer overflow). w* and w# formats are fine. It looks like w format is not used in trunk nor py3k (only w# and w*). -- components: Interpreter Core messages: 106702 nosy: haypo priority: normal severity: normal status: open title: Remove w format of PyParse_ParseTuple() versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8215] getargs.c in Python3 contains some TODO and the documentation is outdated
STINNER Victor victor.stin...@haypocalc.com added the comment: Patch to update the documenation, especially input types for PyArg_ParseTuple() and output types for Py_BuildValue(): - add bytes and/or bytearray when buffer compatible object is accepted to be more explicit - es, et, es#, et# don't accept buffer compatible objects: fix the doc - specify utf-8 encoding - mark U and U# as deprecated: see issue #8848 - fix .. note:: syntax - replace Unicode by str - replace bytes object by bytes - replace any buffer compatible object by buffer compatible object I hesitate to add explicit quotes, eg. s instead of s. -- Added file: http://bugs.python.org/file17490/doc_capi_arg.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8215 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8848] Remove U and U# formats of Py_BuildValue()
STINNER Victor victor.stin...@haypocalc.com added the comment: Less extreme patch: set 'U' as an alias to 's' (and 'U#' as an alias to 's#'). Replace usage of 'U' by 's'. Note: 'z' is also an alias to 's', and 'z#' an alias to 's#'. -- keywords: +patch Added file: http://bugs.python.org/file17491/py_buildvalue_removeU.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8848 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8848] Deprecate or remove U and U# formats of Py_BuildValue()
Changes by STINNER Victor victor.stin...@haypocalc.com: -- title: Remove U and U# formats of Py_BuildValue() - Deprecate or remove U and U# formats of Py_BuildValue() ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8848 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8844] Condition.wait() doesn't raise KeyboardInterrupt
Reid Kleckner r...@mit.edu added the comment: I'd like to fix it, but I don't know if I'll be able to in time. It was something that bugged me while running the threading tests while working on Unladen. I'm imagining (for POSIX platforms) adding some kind of check for signals when the system call returns EINTR. If the signal handler raises an exception, like an interrupt should raise a KeyboardInterrupt, we can just give a different return code and propagate the exception. It also seems like this behavior can be extended gradually to different platforms, since I don't have the resources to change and test every threading implementation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8844 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8840] io.StringIO: truncate+print disabled in 3.1.2
Nick Coghlan ncogh...@gmail.com added the comment: For the record, Guido's decision to change 3.1: http://mail.python.org/pipermail/python-dev/2009-September/092247.html -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8840 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6939] shadows around the io truncate() semantics
Nick Coghlan ncogh...@gmail.com added the comment: To avoid any confusion in the future, it should be noted that Antoine did not unilaterally make the decision to commit this change to a maintenance branch. This change was discussed on python-dev, with the ultimate decision to update the 3.1 semantics being made by Guido: http://mail.python.org/pipermail/python-dev/2009-September/092247.html -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6939 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8851] pkgutil document needs more markups
New submission from MATSUI Tetsushi m...@users.sourceforge.net: The library reference of pkgutil is only sparsely marked up. The attached patch is against 2.6 version, because I'm currently working with 2.6. Since a part of markups (namely :pep:'s) has already been done for 3.2 version, the patch cannot be applied directly to that version, and I haven't checked the versions in between. -- assignee: d...@python components: Documentation files: pkgutil.diff keywords: patch messages: 106708 nosy: d...@python, mft priority: normal severity: normal status: open title: pkgutil document needs more markups versions: Python 2.6 Added file: http://bugs.python.org/file17492/pkgutil.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8851 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1724822] provide a shlex.split alternative for Windows shell syntax
Changes by Eric Smith e...@trueblade.com: -- nosy: +eric.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1724822 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
