All of the abstract base classes should be collected in one place. I propose that the modules be collected into a package so that we can write:
. . .
Besides collecting all the relevant code in one place, it has a nice additional benefit of clearly designating when you're working with one of the provided abstract base classes. When I see "import numbers", I don't immediately recognize this as being somehow different from "import math" or some other concrete implementation.
IMO. the emerging practice of spreading modules these across the library isn't serving us well.
> Does no-one thinks it means round(f) either?
Heck no. The int() and round() functions have been in Lotus and Excel for an eternity and nobody has a problem learning what those functions do.
Also, the extra argument for round(f, n) makes it clear that it can return other floats rounded to n-digits.
I've taught a lot of classes to spreadsheet users and have observed that people get it right away.
>.some pocket calculators have an INT function, defined
> as floor(x) when x is positive and ceil(x) when x is negative
That's the mathematical definition. The way they explain
it is dirt simple: return the integer portion of a number.
Some of the calculators that have int() also have frac()
which has the obvious interpretation.
rational.py contains code for turning a float into an
exact integer ratio. I've needed something like this in
other situations as well. The output is more convenient
than the mantissa/exponent pair returned by math.frexp().
I propose C-coding this function and either putting it in
the math module or making it a method for floats. That
would simplify and speed-up rational.py while making
the tool available for other applications. Also, the
tool is currently in the wrong place (while the output
is clearly useful for rational.py, the internals of
the function are entirely about floats and ints and
has no internal references to the rational module).
"""x -> (top, bot), a pair of ints s.t. x = top/bot.
The conversion is done exactly, without rounding.
bot > 0 guaranteed.
Some form of binary fp is assumed.
Pass NaNs or infinities at your own risk.
In 3.0, the code to implement long.__format__() calls PyNumber_ToBase to
do the heavy lifting. If someone is planning on implementing
PyNumber_ToBase in 2.6, I'll wait for them to do so. If not, I guess
I'll either do it myself, or hack around it.
Is this on anyone's To Do list? I don't see it on Brett's spreadsheet
>> Can anyone explain to me why we need both trunc() and int()?
> trunc() has well-defined semantics -- it takes a Real instance
> and converts it to an Integer instance using round-towards-zero
Since something similar is happening to math.ceil and math.floor,
I'm curious why trunc() ended-up in builtins instead of the math
module. Doesn't it make sense to collect similar functions
with similar signatures in the same place?
I have created issue #1923 to keep track of this.
On Jan 23, 2008 6:00 PM, Gregory P. Smith <greg(a)krypto.org> wrote:
> could you put this on bugs.python.org and follow up with a reference to the
> issue # for better tracking?
> On 1/23/08, stephen emslie <stephenemslie(a)gmail.com> wrote:
> > I've been working on a project that renders PKG-INFO metadata in a
> > number of ways. I have noticed that fields with any indentation were
> > flattened out, which is being done in distutils.util.rfc822_escape.
> > This unfortunately means that you cant use reStructuredText formatting
> > in your long description (suggested in PEP345), or are limited to a
> > set that doesn't require indentation (no block quotes, etc.).
> > It looks like this behavior was intentionally added in rev 20099, but
> > that was about 7 years ago - before reStructuredText and eggs. I
> > wonder if it makes sense to re-think that implementation with this
> > sort of metadata in mind, assuming this behavior isn't required to be
> > rfc822 compliant. I think it would certainly be a shame to miss out on
> > a good thing like proper (renderable) reST in our metadata.
> > A quick example of what I mean:
> > >>> rest = """
> > ... a literal python block::
> > ... >>> import this
> > ... """
> > >>> print distutils.util.rfc822_escape(rest)
> > a literal python block::
> > >>> import this
> > should look something like:
> > a literal python block::
> > >>> import this
> > Is distutils being over-cautious in flattening out all whitespace? A
> > w3c discussion on multiple lines in rfc822  seems to suggest that
> > whitespace can be 'unfolded' safely, so it seems a shame to be
> > throwing it away when it can have important meaning.
> >  http://www.w3.org/Protocols/rfc822/3_Lexical.html
> > Thanks for any comments
> > Stephen Emslie
> > _______________________________________________
> > Python-Dev mailing list
> > Python-Dev(a)python.org
> > http://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe:
The documentation for the struct module says:
"short is 2 bytes; int and long are 4 bytes; long long (__int64 on Windows)
is 8 bytes"
and lists 'l' and 'L' as the pack code for a C long.
As its implemented today, the documentation is incorrect. On an LP64 host
(pretty much any 64-bit linux, bsd or unixish thing) a long is 8 bytes.
I assume this means there is existing code out there that expects the
current not-as-documented behavior. There is also code out there that
expects the documented behavior but behaves wrong when a 64bit Python is
I assume I should just fix the documentation and anything in Lib that uses
the struct module incorrectly (zipfile for example) rather than change the
This is for http://bugs.python.org/issue1789
The O'Reilly Open Source Convention (OSCON) is accepting proposals for
tutorials and presentations. The submission period ends Feb 4.
OSCON 2008 will be in Portland, Oregon July 21-25. For more information
and to submit a proposal, see
Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/
"All problems in computer science can be solved by another level of
indirection." --Butler Lampson