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

[Travis Oliphant]

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 think replacing basic number operations of the arrayobject should 
simple, so perhaps a default ufunc object could be worked out for 
inclusion.


I appreciate some of what Paul is saying here, but I'm not fully  
convinced that this is still true with Python 2.2 and up new-style  
c-types.   The concerns seem to be over the fact that you have to  
re-implement everything in the sub-class because the base-class will  
always return one of its objects instead of a sub-class object.

I'd say that such discussions should be postponed until someone  
proposes a good use for subclassing arrays. Matrices are not one, in 
my  opinion.

Agreed.  It is is not critical to what I am doing, and I obviously need 
more understanding before tackling such things.  Numeric3 uses the new 
c-type largely because of the nice getsets table which is separate from 
the methods table.  This replaces the rather ugly C-functions getattr 
and setattr.

-Travis
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Paul Moore]

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 say it is okay for people to send in
> patch reviews *only* and not notifications of new patches, bug reports, or bug
> reviews, then I can handle it.

Having done some reviews (admittedly for the 5-for-1 deal) I do like
seeing patch reviews appear on python-dev. As they are meant to be
reviews, this implies a certain level of effort expended, and quality
in the response. I agree with Martin that detail comments should go in
the tracker - a posting can summarise to an extent, but should be
enough to let python-dev readers know if they can act on the review.

It's nice to see new contributors doing good work to help Python, and
I assume they like the chance to feel like they are "participating" by
posting helpful contributions to python-dev. IMHO, the tracker doesn't
give this same feeling of "contributing".

Also, review postings encourage others to do the same - I know I did
my reviews after having seen someone else post a set of reviews. It
made me think "hey, I could do that!" I'm sure there are other lurkers
on python-dev who could be encouraged to assist in the same way.

Having said this, I'd suggest that if people intend to review multiple
patches, they post a summary covering a number of patches at a time.

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Jim Jewett]

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 with:  [] in (0,)

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.

If there aren't any unhashable values, then the (unhashable) item
being checked is not in the set. ==> Return False.

Are you worried about unhashable objects (as item) which 
compare == to something that is hashable (in container)?
Custom rich compares can already confuse the "in" tests.

Or is the problem that guarding against/trapping this case is 
somehow so expensive that it overrides the expected savings?

-jJ
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Tim Peters]

[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.datetime):
> +self.value = value.strftime("%Y%m%dT%H:%M:%S")
> +return

... [and similarly later] ...

Fred, is there a reason to avoid datetime.datetime's .isoformat()
method here?  Like so:

>>> import datetime
>>> print datetime.datetime(2005, 2, 10, 14, 0, 8).isoformat()
2005-02-10T14:00:08

A possible downside is that you'll also get fractional seconds if the
instance records a non-zero .microseconds value.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred L. Drake, Jr.]

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 a 
string without hyphens (but with colons), so I stuck with eactly that.

 > A possible downside is that you'll also get fractional seconds if the
 > instance records a non-zero .microseconds value.

There's nothing in the XML-RPC spec about the resolution of time, so, again, 
I'd rather be conservative in what we generate.


  -Fred

-- 
Fred L. Drake, Jr.  

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Tim Peters]

[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), so I stuck with eactly that.

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>.

>> A possible downside is that you'll also get fractional seconds if the
>> instance records a non-zero .microseconds value.

> There's nothing in the XML-RPC spec about the resolution of time, so, again,
> I'd rather be conservative in what we generate.

dt.replace(microsecond=0).isoformat()

suffices for that much.  Tack on .replace('-', '') to do the whole job.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Michael Hudson]

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:
>> Remove the set conversion which didn't work with:  [] in (0,)
>
> Why is this a problem?

It broke the test suite...

> If there were *any* unhashable objects in the container, then the
> compiler would have bailed on the initial set-conversion.

Also, the RHS wouldn't have been a tuple of constants, as far as the
compiler saw it.

> If there aren't any unhashable values, then the (unhashable) item
> being checked is not in the set. ==> Return False.

This would seem to require changing the frozenset implementation.  I
don't know if the option of unhashable implying returning false from
frozenset.__contains__() was considered at the time it was implemented
but it doesn't feel right to me.

> Are you worried about unhashable objects (as item) which 
> compare == to something that is hashable (in container)?
> Custom rich compares can already confuse the "in" tests.

This was a concern of mine, yes.  Although any custom object
(particularly an unhashable one!) that compares equal to something so
simple as an integer, string or tuple seems bad design, I'm not sure
that's the point.

> Or is the problem that guarding against/trapping this case is 
> somehow so expensive that it overrides the expected savings?

If you want to compile the expression

x in (1,2,3)

to contain the moral equivalent of a try:except: block, I'd question
your sanity.

Cheers,
mwh

-- 
  > It might get my attention if you'd spin around in your chair,
  > spoke in tongues, and puked jets of green goblin goo.
  I can arrange for this.  ;-)-- Barry Warsaw & Fred Drake
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred L. Drake, Jr.]

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()
 >
 > suffices for that much.  Tack on .replace('-', '') to do the whole job.

Yep, that would work too.


  -Fred

-- 
Fred L. Drake, Jr.  

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred L. Drake, Jr.]

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 the range of what's accepted and produced by the 
various XML-RPC libraries, but I've not looked hard for it.


  -Fred

-- 
Fred L. Drake, Jr.  

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[John J Lee]

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 MozillaCookieJar exceptions


John
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[=?iso-8859-1?Q?Fran=E7ois?= Pinard]

[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 able
to stand them.  Others, at least like me, just hate them.

When a developer replies to one of my emails, asking me that I use
the bug tracker, my email was surely not lost, since the developer is
replying to it.  That developer could have used the bug tracker himself,
the way he sees fit, instead of inviting me to do it.

In fact, a developer asking me to use the tracker of the day is trying
to educate me into using it.  Or maybe he knows that using the tracker
is uneasy and is trying to spare himself some disgust.  Or maybe he is
consciously trying to turn me down :-). I do not buy the argument of the
fear of emails being lost.  Actually, almost all of my emails reporting
bugs received a reply in one form or another, so developers do see them.

If a developer wants to use a bug tracker, then nice, good for him.
For one, trackers merely tell me that I should get a life and do nicer
things than reporting bugs.  In any case, Python has plenty of users,
and others will contribute anyway.  So, after all, why should I?

> So this kind of bug management is the primary reason for the tracker,
> not that we want to keep random users out of python-dev (although this
> is a convenient side effect).

Hey, that's good!  Trackers may act like a randomiser! :-)

-- 
François Pinard   http://pinard.progiciels-bpi.ca
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[David Ascher]

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 a note on the XML-RPC list about this.  There doesn't seem to be
> anything that describes the range of what's accepted and produced by the
> various XML-RPC libraries, but I've not looked hard for it.

Is there any surprise here? =)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Tim Peters]

[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 conjunction with its crazy rules for representing floats. 
It's a very vague doc indeed.

Anyway, some quick googling strongly suggests that many XML-RPC
implementors don't know anything about 8601 either, and accept/produce
only the non-8601 format inferred from the single example in "the
spec".  Heh -- kids .
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[=?ISO-8859-1?Q?BJ=F6rn_Lindqvist?=]

> 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 with:  [] in (0,)
> 
> 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 (most recent call last):
  File "", line 1, in ?
TypeError: list objects are unhashable

The compiler do bail out when there are unhashable objects outside the
tuple, but not if the LHS is unhashable. I believe that is because
internally frozenset uses a dict and it does something similar to
d.has_key([]) in this case. It should be trivial for the compiler to
also check the LHS for hashability I think.

That is also why the email unit test failed - LHS was unhashable but
the RHS was hashable. There is a patch for that (1119016) at SF but
that may no longer be needed.
 
-- 
mvh Björn
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Raymond Hettinger]

[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 (most recent call last):
>   File "", line 1, in ?
> TypeError: list objects are unhashable

[Bjorn]
> The compiler do bail out when there are unhashable objects outside the
> tuple, but not if the LHS is unhashable. I believe that is because
> internally frozenset uses a dict and it does something similar to
> d.has_key([]) in this case. It should be trivial for the compiler to
> also check the LHS for hashability I think.
> 
> That is also why the email unit test failed - LHS was unhashable but
> the RHS was hashable. There is a patch for that (1119016) at SF but
> that may no longer be needed.

Right, that patch only fixes a symptom.  Also, the compiler cannot check
the hashability of the search key because it is likely not known at
compile time (i.e. x in (1,2,3) where x is a function argument).

For the time being, the set conversion concept was removed entirely.  To
go forward with it at some point, it will need a fast search type other
than frozenset, something like:

class FastSearchTuple(tuple):
"""Tuple lookalike that has O(1) search time if both the key and
 tuple elements are hashable; otherwise it reverts to an O(n) linear
 search. Used by compile.c for 'in' tests on tuples of constants.
""" 
  
def __init__(self, data):
try:
self.dict = dict.fromkeys(data)
except TypeError:
self.dict = None

def __contains__(self, key):
try:
return key in self.dict
except TypeError:
return tuple.__contains__(self, key)



Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Donovan Baarda]

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 replacement?

One thing to consider is "degree of difficulty" :-)

> > Matthias
> 
> I believe the "plan" for md5 and sha1 and such is to use the much
> faster openssl versions "in the future" (based on a long thread
> debating future interfaces to such things on python-dev last summer).
> That'll sidestep any tedious license issue and give a better
> implementation at the same time.  i don't believe anyone has taken the
> time to make such a patch yet.

I wasn't around for that discussion. There are two viable replacements
for the RSA implementation currently used; 

libmd 
openssl .

The libmd implementation is by Colin Plumb and has the licence; "This
code is in the public domain; do with it what you wish." The API is
identical to the RSA implementation and BSD world's libmd and hence is a
drop in replacement. This implementation is faster than the RSA
implementation.

The openssl implementation has an apache style license. The API is
almost the same but slightly different to the RSA API, so it would
require a little bit of work to make it fit. This implementation is the
fastest currently available, as it includes many platform specific
optimisations for a large range of platforms.

Currently md5c.c is included in the python sources. The libmd
implementation has a drop in replacement for md5c.c. The openssl
implementation is a complicated tangle of Makefile expanded template
code that would be harder to include in the Python sources.

In the Linux world, openssl is starting to become ubiquitous, so not
including it and statically or even dynamically linking against it is
feasible. However, using Python in other lands will probably require
something to be included.

Long term, I think openssl is the way to go. Short term, libmd is a
painless replacement that gets around the licencing issues.

I have been using the libmd API stuff for md4 in librsync, and am
looking at migrating to the openssl API. If people hassle me, I could
probably do the openssl API migration for Python, but I'm not sure what
the best approach would be to including the source in Python sources.

FWIW, I also have an md4sum module and md4c.c implementation that I'm
happy to contribute to Python (done for pysysnc).

-- 
Donovan Baarda <[EMAIL PROTECTED]>
http://minkirri.apana.org.au/~abo/

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Bob Ippolito]

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 requirements when
considering a replacement?
One thing to consider is "degree of difficulty" :-)
	Matthias
I believe the "plan" for md5 and sha1 and such is to use the much
faster openssl versions "in the future" (based on a long thread
debating future interfaces to such things on python-dev last summer).
That'll sidestep any tedious license issue and give a better
implementation at the same time.  i don't believe anyone has taken the
time to make such a patch yet.
I wasn't around for that discussion. There are two viable replacements
for the RSA implementation currently used;
libmd 
openssl .
--
In the Linux world, openssl is starting to become ubiquitous, so not
including it and statically or even dynamically linking against it is
feasible. However, using Python in other lands will probably require
something to be included.
Long term, I think openssl is the way to go. Short term, libmd is a
painless replacement that gets around the licencing issues.
OpenSSL is also ubiquitous on Mac OS X (as a shared lib):
Mac OS X 10.2.8 has OpenSSL 0.9.6i Feb 19 2003
Mac OS X 10.3.8 has OpenSSL 0.9.7b 10 Apr 2003
One possible alternative would be to bring in something like PyOpenSSL 
 and just rewrite the md5 (and sha?) 
extensions as Python modules that use that API.

-bob
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Donovan Baarda]

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 just rewrite the md5 (and sha?) 
> extensions as Python modules that use that API.

Only problem with this, is pyopenssl doesn't yet include any mdX or sha
modules.

-- 
Donovan Baarda <[EMAIL PROTECTED]>
http://minkirri.apana.org.au/~abo/

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Bob Ippolito]

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
 and just rewrite the md5 (and 
sha?)
extensions as Python modules that use that API.
Only problem with this, is pyopenssl doesn't yet include any mdX or sha
modules.
My bad, how about M2Crypto  
then?  This one supports message digests and is more license compatible 
with Python to boot.

-bob
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Donovan Baarda]

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  
> then?  This one supports message digests and is more license compatible 
> with Python to boot.
[...]

This one does have md5 support, but the Python API is rather different
from the current python md5sum API. It hooks into the slightly higher
level MVP openssl layer, rather than the lower level md5 layer. Hooking
into the MVP layer pretty much requires including all the openssl
message digest implementations (which may or may not be a good idea).

It also uses SWIG to generate the extension module. I don't think
anything else in Python itself uses SWIG, so starting to use it would
introduce a "Build Dependency".

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 the openssl md5 implementation
sources so that win32 can use them.

-- 
Donovan Baarda <[EMAIL PROTECTED]>
http://minkirri.apana.org.au/~abo/

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Donovan Baarda]

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 the openssl md5 implementation
> sources so that win32 can use them.

Thinking about it, probably the best way is to include the libmd md5c.c
modified to use the openssl API, and then use configure to check for and
use openssl if it is available. That way win32 could use the provided
md5c.c, and other platforms could use the faster openssl.

-- 
Donovan Baarda <[EMAIL PROTECTED]>
http://minkirri.apana.org.au/~abo/

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com