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.
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
On Fri, Jun 27, 2008 at 11:40 AM, Bill Janssen <[EMAIL PROTECTED]> wrote:
>> I notice that there is some work being done on urllib / urllib2 for
>> python 2.6/3.0. One thing I've always missed in urllib/urllib2 is the
>> facility to encode POST data as multipart/form-data. I think it would
>> als
Hello,
I notice that there is some work being done on urllib / urllib2 for
python 2.6/3.0. One thing I've always missed in urllib/urllib2 is the
facility to encode POST data as multipart/form-data. I think it would
also be useful to be able to stream a POST request to the remote
server rather th
On 2/28/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> "Chris AtLee" <[EMAIL PROTECTED]> wrote:
> > I just got bitten by the runtime library incompatibility problem on
> > windows when I tried to load a C extension compiled with MSVC 2005
> > (64-bit) in
I just got bitten by the runtime library incompatibility problem on
windows when I tried to load a C extension compiled with MSVC 2005
(64-bit) into Python 2.5.
I realize that Python2.5 will continue to use MSVC 2003 for
compatibility reasons, but I was curious if any thought had been given
to the
On 5/21/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Then options 2 and 3 are both fine.
>
> Not compiling at all is *not*, so if nobody has time to implement 2 or
> 3, we'll have to do 4.
>
> --Guido
Is this thread still alive?
I've posted patch #1503046 to sourceforge which implements opti
On 3/30/06, Aahz <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 30, 2006, Chris AtLee wrote:
> >
> > The current 2.4 and 2.5 docs mention that the xmlrpclib has a function
> > called binary which converts any python value to a Binary object.
> >
> > However, this
The current 2.4 and 2.5 docs mention that the xmlrpclib has a function
called binary which converts any python value to a Binary object.
However, this function does not exist in either 2.4.3 or 2.5.
The Binary constructor accepts a data parameter, so I would say just
remove mention of the binary
On 3/28/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> We've made a lot of improvement with testing over the years.
> Recently, we've gotten even more serious with the buildbot, Coverity,
> and coverage (http://coverage.livinglogic.de). However, in order to
> improve quality even further, we need t
Hi,
I've just submitted patch #1457227 which adds a convenience method to
datetime objects to get the timestamp. It's equivalent to
time.mktime(d.timetuple()), I just wanted to save myself some typing
and be able to write d.timestamp() instead.
I hope I have the dst code right. Would d.utctimes
On 2/20/06, Mark Mc Mahon <[EMAIL PROTECTED]> wrote:
> Hi,
>
> It seems that the Path module as currently defined leaves equality
> testing up to the underlying string comparison. My guess is that this
> is fine for Unix (maybe not even) but it is a bit lacking for Windows.
>
> Should the path clas
On 2/17/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
Please submit your patch to SourceForge.I've submitted the zlib patch as patch #1435422. I added some test cases to test_zlib.py and documented the new methods. I'd like to test my gzip / tarfile changes more before creating a patch for it,
I'm writing a program in python that creates tar files of a certain maximum size (to fit onto CD/DVD). One of the problems I'm running into is that when using compression, it's pretty much impossible to
determine if a file, once added to an archive, will cause the archive size to exceed the m
14 matches
Mail list logo
