sys.maxsize support

[GoogleCodeExporter]

sys lib has sys.maxint but no sys.maxsize 
The future trend of python is to obsolete sys.maxint

Original issue reported on code.google.com by jason.mi...@gmail.com on 15 Jun 2011 at 2:55

[GoogleCodeExporter]

thanks a lot for mentioning! I will add it to the easy tasks wiki page for now, 
and if nobody steps up look into it myself for 0.9.

Original comment by mark.duf...@gmail.com on 15 Jun 2011 at 9:26

• Changed state: Accepted

[GoogleCodeExporter]

Attached a patch for this. Didn't use the FOR_IN macro. Is that recommended?

Original comment by bpederse on 23 Jun 2011 at 8:51

Attachments:

• shedskin.137.patch

[GoogleCodeExporter]

Uh the previous attachment is for ticket 138. this is for 137.

Original comment by bpederse on 23 Jun 2011 at 9:05

Attachments:

• shedskin.137.maxsize.diff

[GoogleCodeExporter]

heh, no problem.. ;) thanks for all your patches! 

FOR_IN in combination with a generic argument is the fastest approach in 
general (see for example see template<class T> template<class U> void 
*set<T>::update(U *iter)), but I see other set methods use the same approach. 
this is double slow, because iterating over a pyiter<T> * is slow (uses 
StopIteration..exceptions in C++ are dog slow), and allocating a new set object 
is also really slow. but usually the other argument is also just a set though, 
so the pyiter case is probably not that important to optimize.. 

if you like, the common set-set case can be optimized by iterating over the 
smaller set, as in template<class T> set<T> *set<T>::intersection(set<T> *s). 
this trick is used in a few places I think, so perhaps it would be nice to 
factor this out a bit. I pushed your patch in any case, as it's a definite 
improvement.. ;)

Original comment by mark.duf...@gmail.com on 23 Jun 2011 at 9:15

[GoogleCodeExporter]

maxsize patch also pushed, thanks a lot! :D

Original comment by mark.duf...@gmail.com on 23 Jun 2011 at 9:25

• Changed state: Fixed

[GoogleCodeExporter]

Thanks for applying.

I can't tell if you mean that FOR_IN would or would not be helpful in the 
isdisjoint case. I see what you mean about iterating over the smaller set 
though.

Original comment by bpederse on 23 Jun 2011 at 9:47

[GoogleCodeExporter]

it won't help for the isdisjoint(set) case, but can help a lot for the 
isdisjoint(pyiter) case, because the method will be specialized for every type 
of argument that is used (for example, isdisjoint(list)), and this can make 
iteration a lot faster. the set allocation is probably also really slowing 
things down here. but yeah, the smaller set trick is probably more useful in 
practice.

Original comment by mark.duf...@gmail.com on 23 Jun 2011 at 10:00