Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c

On Fri, 2005-02-11 at 17:15 +1100, Donovan Baarda wrote: [...] > I think it would be cleaner and simpler to modify the existing > md5module.c to use the openssl md5 layer API (this is just a > search/replace to change the function names). The bigger problem is > deciding what/how/whether to include

Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c

On Thu, 2005-02-10 at 23:13 -0500, Bob Ippolito wrote: > On Feb 10, 2005, at 9:50 PM, Donovan Baarda wrote: > > > On Thu, 2005-02-10 at 21:30 -0500, Bob Ippolito wrote: [...] > > Only problem with this, is pyopenssl doesn't yet include any mdX or sha > > modules. > > My bad, how about M2Crypto

Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c

On Feb 10, 2005, at 9:50 PM, Donovan Baarda wrote: On Thu, 2005-02-10 at 21:30 -0500, Bob Ippolito wrote: On Feb 10, 2005, at 9:15 PM, Donovan Baarda wrote: On Tue, 2005-02-08 at 11:52 -0800, Gregory P. Smith wrote: [...] One possible alternative would be to bring in something like PyOpenSSL

Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c

On Thu, 2005-02-10 at 21:30 -0500, Bob Ippolito wrote: > On Feb 10, 2005, at 9:15 PM, Donovan Baarda wrote: > > > On Tue, 2005-02-08 at 11:52 -0800, Gregory P. Smith wrote: [...] > One possible alternative would be to bring in something like PyOpenSSL > and jus

Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c

On Feb 10, 2005, at 9:15 PM, Donovan Baarda wrote: On Tue, 2005-02-08 at 11:52 -0800, Gregory P. Smith wrote: The md5.h/md5c.c files allow "copy and use", but no modification of the files. There are some alternative implementations, i.e. in glibc, openssl, so a replacement should be sage. Any other

Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c

On Tue, 2005-02-08 at 11:52 -0800, Gregory P. Smith wrote: > > The md5.h/md5c.c files allow "copy and use", but no modification of > > the files. There are some alternative implementations, i.e. in glibc, > > openssl, so a replacement should be sage. Any other requirements when > > considering a re

RE: [Python-Dev] Re: [Python-checkins] python/dist/src/Pythoncompile.c, 2.343, 2.344

[Raymond] > > > Remove the set conversion which didn't work with: [] in (0,) [Jim] > > Why is this a problem? If there were *any* unhashable objects > > in the container, then the compiler would have bailed on the > > initial set-conversion. > > >>> [] in frozenset(["hi", "ho"]) > Traceback (mo

Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Python compile.c, 2.343, 2.344

> On Wed, 09 Feb 2005 17:42:41 -0800, [EMAIL PROTECTED] > <[EMAIL PROTECTED]> wrote: > > Update of /cvsroot/python/python/dist/src/Python > > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv31172 > > > > Modified Files: > > compile.c > > Log Message: > > Remove the set conversion whic

[Python-Dev] Re: [Python-checkins] python/dist/src/Lib xmlrpclib.py, 1.38, 1.39

[Tim] >> Well, then since that isn't ISO 8601 format, it would be nice to have >> a comment explaining why it's claiming to be anyway <0.5 wink>. [Fred] > Hmm, that's right (ISO 8601:2000, section 5.4.2). Sigh. Ain't your fault. I didn't remember that I had seen the XML-RPC spec before, in conj

Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Lib xmlrpclib.py, 1.38, 1.39

On Thu, 10 Feb 2005 15:32:14 -0500, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote: > On Thursday 10 February 2005 14:44, Tim Peters wrote: > > Well, then since that isn't ISO 8601 format, it would be nice to have > > a comment explaining why it's claiming to be anyway <0.5 wink>. > > I've posted

Re: [Python-Dev] discourage patch reviews to the list?

[Martin von Löwis] > I disagree with the primary reason not to take bug reports on > python-dev, however: bug reports in email get lost if not immediately > processed; usage of a tracker is necessary to actually "keep > track". Some developers and users appreciate bug trackers, or at least are ab

[Python-Dev] Patches for cookielib bugs, for 2.4.1

Hope these can get in before 2.4.1. All include unit tests. http://python.org/sf/1117339 cookielib and cookies with special names http://python.org/sf/1117454 cookielib.LWPCookieJar incorrectly loads value-less cookies http://python.org/sf/1117398 cookielib LWPCookieJar and MozillaC

[Python-Dev] Re: [Python-checkins] python/dist/src/Lib xmlrpclib.py, 1.38, 1.39

On Thursday 10 February 2005 14:44, Tim Peters wrote: > Well, then since that isn't ISO 8601 format, it would be nice to have > a comment explaining why it's claiming to be anyway <0.5 wink>. I've posted a note on the XML-RPC list about this. There doesn't seem to be anything that describes th

[Python-Dev] Re: [Python-checkins] python/dist/src/Lib xmlrpclib.py, 1.38, 1.39

On Thursday 10 February 2005 14:44, Tim Peters wrote: > Well, then since that isn't ISO 8601 format, it would be nice to have > a comment explaining why it's claiming to be anyway <0.5 wink>. Hmm, that's right (ISO 8601:2000, section 5.4.2). Sigh. > dt.replace(microsecond=0).isoformat()

Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Python compile.c, 2.343, 2.344

Jim Jewett <[EMAIL PROTECTED]> writes: > On Wed, 09 Feb 2005 17:42:41 -0800, [EMAIL PROTECTED] > <[EMAIL PROTECTED]> wrote: >> Update of /cvsroot/python/python/dist/src/Python >> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv31172 >> >> Modified Files: >> compile.c >> Log Message:

[Python-Dev] Re: [Python-checkins] python/dist/src/Lib xmlrpclib.py, 1.38, 1.39

[Tim] >> Fred, is there a reason to avoid datetime.datetime's .isoformat() >> method here? Like so: > Yes. The XML-RPC spec is quite vague. It claims that the dates are in ISO > 8601 format, but doesn't say anything more about it. The example shows a > string without hyphens (but with colons),

[Python-Dev] Re: [Python-checkins] python/dist/src/Lib xmlrpclib.py, 1.38, 1.39

On Thursday 10 February 2005 14:09, Tim Peters wrote: > Fred, is there a reason to avoid datetime.datetime's .isoformat() > method here? Like so: Yes. The XML-RPC spec is quite vague. It claims that the dates are in ISO 8601 format, but doesn't say anything more about it. The example shows

[Python-Dev] Re: [Python-checkins] python/dist/src/Lib xmlrpclib.py, 1.38, 1.39

[EMAIL PROTECTED] > Modified Files: >xmlrpclib.py > Log Message: > accept datetime.datetime instances when marshalling; > dateTime.iso8601 elements still unmarshal into xmlrpclib.DateTime objects > > Index: xmlrpclib.py ... > +if datetime and isinstance(value, datetime.dateti

[Python-Dev] Re: [Python-checkins] python/dist/src/Python compile.c, 2.343, 2.344

On Wed, 09 Feb 2005 17:42:41 -0800, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Update of /cvsroot/python/python/dist/src/Python > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv31172 > > Modified Files: > compile.c > Log Message: > Remove the set conversion which didn't work wit

Re: [Python-Dev] discourage patch reviews to the list?

On Wed, 09 Feb 2005 17:25:14 -0800, Brett C. <[EMAIL PROTECTED]> wrote: > All valid points, but I also don't want people to suddenly start posting > one-liners or bug posts. > > I guess it comes down to a signal-to-noise ratio and if the level of signal we > are currently getting will hold. If we

[Python-Dev] Re: [Numpy-discussion] Re: Numeric life as I see it

One question we are pursuing is could the arrayobject get into the core without a particular ufunc object. Most see this as sub-optimal, but maybe it is the only way. Since all the artithmetic operations are in ufunc that would be suboptimal solution, but indeed still a workable one. I t