Re: [Python-Dev] [Python-checkins] r64424 - inpython/trunk:Include/object.h Lib/test/test_sys.pyMisc/NEWSObjects/intobject.c Objects/longobject.cObjects/typeobject.cPython/bltinmodule.c
FWIW, I'm fine with making these methods on float -- a class method float.fromhex(...) echoes e.g. dict.fromkeys(...) and datetime.fromordinal(...). The to-hex conversion could be x.hex() -- we don't tend to use ".toxyz()" as a naming convention much in Python. On Sun, Jun 29, 2008 at 5:26 PM, Mark Dickinson <[EMAIL PROTECTED]> wrote: > On Sun, Jun 29, 2008 at 12:46 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: >> Is everyone agreed on a tohex/fromhex pair using the C99 notation as >> recommended in 754R? > > Sounds good to me. > > I've attached a Python version of a possible implementation to the issue. See: > > http://bugs.python.org/file10780/hex_float.py > > It might be useful for testing. > > Mark > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r64424 - inpython/trunk:Include/object.h Lib/test/test_sys.pyMisc/NEWSObjects/intobject.c Objects/longobject.cObjects/typeobject.cPython/bltinmodule.c
On Mon, Jun 30, 2008 at 4:53 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > FWIW, I'm fine with making these methods on float -- a class method > float.fromhex(...) echoes e.g. dict.fromkeys(...) and > datetime.fromordinal(...). The to-hex conversion could be x.hex() -- > we don't tend to use ".toxyz()" as a naming convention much in Python. Would it be totally outrageous for the float constructor to accept hex strings directly? Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] urllib, multipart/form-data encoding and file uploads
On Sat, Jun 28, 2008 at 4:14 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> I didn't see any recent discussion about this so I thought I'd ask >> here: do you think this would make a good addition to the new urllib >> package? > > Just in case that isn't clear: any such change must be delayed for > 2.7/3.1. That is not to say that you couldn't start implementing it > now, of course. I like a challenge :) As discussed previously, there are two parts to this: handling streaming HTTP requests, and multipart/form-data encoding. I notice that support for file objects has already been added to 2.6's httplib. The changes required to support iterable objects are very minimal: Index: Lib/httplib.py === --- Lib/httplib.py (revision 64600) +++ Lib/httplib.py (working copy) @@ -688,7 +688,12 @@ self.__state = _CS_IDLE def send(self, str): -"""Send `str' to the server.""" +"""Send `str` to the server. + +``str`` can be a string object, a file-like object that supports +a .read() method, or an iterable object that supports a .next() +method. +""" if self.sock is None: if self.auto_open: self.connect() @@ -710,6 +715,10 @@ while data: self.sock.sendall(data) data=str.read(blocksize) +elif hasattr(str,'next'): +if self.debuglevel > 0: print "sendIng an iterable" +for data in str: +self.sock.sendall(data) else: self.sock.sendall(str) except socket.error, v: (small aside, should the parameter called 'str' be renamed to something else to avoid conflicts with the 'str' builtin?) All regression tests continue to pass with this change applied. If this change is not applied, then we have to jump through a couple of hoops to support iterable HTTP request bodies: - Provide our own httplib.HTTP(S)Connection classes that override send() to do exactly what the patch above accomplishes - Provide our own urllib2.HTTP(S)Handler classes that will use the new HTTP(S)Connection classes - Register the new HTTP(S)Handler classes with urllib2 so they take priority over the standard handlers I've created the necessary sub-classes, as well as several classes and functions to do multipart/form-data encoding of strings and files. My current work is available online here: http://atlee.ca/software/poster (tarball here: http://atlee.ca/software/poster/dist/0.1/poster-0.1dev.tar.gz) Cheers, Chris ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] urllib, multipart/form-data encoding and file uploads
On Fri, Jun 27, 2008 at 9:06 PM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Chris, > > To avoid losing these ideas, could you add them to the issue tracker as > feature requests? It's too late to get them into 2.6/3.0 but they may make > good additions for the next release cycle. > > Cheers, > Nick. Issues #3243 and #3244 created. Cheers, Chris ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r64424 - inpython/trunk:Include/object.h Lib/test/test_sys.pyMisc/NEWSObjects/intobject.c Objects/longobject.cObjects/typeobject.cPython/bltinmodule.c
Mon, Jun 30, 2008 at 9:31 AM, Mark Dickinson <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 30, 2008 at 4:53 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> FWIW, I'm fine with making these methods on float -- a class method
>> float.fromhex(...) echoes e.g. dict.fromkeys(...) and
>> datetime.fromordinal(...). The to-hex conversion could be x.hex() --
>> we don't tend to use ".toxyz()" as a naming convention much in Python.
>
> Would it be totally outrageous for the float constructor to accept
> hex strings directly?
int('0x10') raises a ValueError as well. You might propose
float('0x...p...', 16) but since the format is so specifically
different I think that's not completely kosher.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
