[Python-Dev] Re: Unifying Long Integers and Integers

[Guido van Rossum]

> [re: numerical PEPs mailing list] 
> > Please help yourself.  I recommend using SF since it requires less
> > overhead for the poor python.org sysadmins.
> 
> Err...I can't. Requesting an SF mailing list is an admin operation.

OK.  I won't make the request (too much going on still) so please ask
someone else at PythonLabs to do it.  Don't just sit there waiting for
one of us to read this mail and do it!

> What do you think? Should I issue a warning on shifting an integer so
> it would be cut/signed in the old semantics?

You'll have to, because the change in semantics will definitely break
some code.

> It also means overflow raises a different exception. Again, I suspect
> it will be used only in cases where the algorithm is supposed to maintain
> that internal results are not bigger then the inputs or things like that,
> and there only as a debugging aid -- so I don't think that this would be this
> bad. And if people want to avoid using the longs for performance reasons,
> then the implementation should definitely *not* lie to them.

It's not clear that using something derived from the machine word size
is the most helpful here.  Maybe a separate integral type that has a
limited range should be used for this.

> OK, so what's the concrete advice?

Propose both alternatives in the PEP.  It's too early to make
decisions -- first we need to have a catalog of our options, and their
consequences.

--Guido van Rossum (home page: http://www.python.org/~guido/)