Thanks to David Abrahams for passing on this info: a free optimizing
cmdline VC 7.1 has been released by MS:
The 32MB download appears to contain much of the meat of Visual Studio .NET
2003 Professional, including the compiler, linker, static-link libraries for
the C, C++ & STL runtimes, and the .NET Common Language Runtime.
[Jewett, Jim J]
#- Under the current implementation:
#- (0, (2, 4, 0, 0, 0), -4)
#- is not quite the same as
#- (0, (2, 4) -1)
#- Given this, is should be possible for the user to specify
#- (at creation) which is desired.
It *is* posible:
Decimal( (0, (2, 4, 0, 0, 0), -4) )
Decimal( (0, (2, 4), -1) )
#- I agree that the programmer should specify if they want
#- something odd -- and that is precisely why the constructor
#- should take an optional context argument which allows the
#- user to specify precision.
If you construct using precision, and the precision is smaller than the
quantity of digits you provide, you'll get rounded, but if the precision is
greater than the quantity of digits you provide, you don't get filled with
#- Given that float input may well look like string (saved to a
#- file by another program) or even an integer (C double may have
#- more precision than C long) there is no particular reason to
#- say "context is only allowed when constructing from a float"
No. Why we should do that?
At 09:55 AM 4/19/04 -0400, Raymond Hettinger wrote:
> > I'm not sure I understand the reasoning for implementing this via a
> > bytecode hack, rather than in the compiler or loading mechanisms.
>The reason is that it is not always possible to know (in general) what
>things constants. Take a look at the ASPN recipe example, it ought to
>clarify for you how this works.
I don't need clarification about the mechanism; I independently implemented
*exactly* this hack myself a couple of years ago. (I just didn't propose
it become part of standard Python.) See 'bind_func()' in:
> > from __future__ import fast_globals
>The __future__ mechanism is a transitional approach for things that
>would break existing code.
Right, and the slightly broader proposal I made *would* break existing
code, but in a direction that Guido has said before he'd like to move.
>Also, __future__ statements go at the beginning of a script and the
>proposed bind_all goes at the end.
Which is a good argument for why the __future__ statement is a much better
> > which would mean that globals and builtins could be considered
> > unless declared with 'global' at the module level. Then, the compiler
> > could optimize any undeclared builtins, and the 'MAKE_FUNCTION' opcode
> > could bind any constants defined as of the function's declaration.
> > Finally, the module object thus created would ban any __setattr__ on
> > constant that has been bound into a function. (Since these are the
> > setattrs that could cause harm.)
>IMO, this is making something hard out of something simple.
No, it's trying to advance the *language*, rather than merely its
implementation, and thus make it easier for Jython, IronPython, et al to cope.
>Try applying the working code in the PEP to a few modules.
Given that I've had this hack in my CVS repository for a few years now, you
will probably realize that I already have. :)
At 06:29 20.04.2004 -0400, Raymond Hettinger wrote:
> > he's proposing an hack that would speed up CPython and slow down
> > (because it would result in a no-op but OTOH he would like to remove
> > code
> > when some globals are bound to locals for speed reason. Of course
> > not nice too
> > but replacing a hack with another is just sort of a win. Honestly
> > are
> > probably
> > very convoluted ways to make this, in this form, a non no-op on Jython
> > too,
> > not that I would like to
> > implement them or that Raymond cared).
>Factually false on both counts.
>I do care. Jython was a key design consideration from the beginning.
>Guido and I specifically went over the non-CPython implications before
>the PEP was submitted.
>The no-op is automatic and makes bind_all equal to lambda *args, **kwds:
>0. It is invoked only the first time a module is imported. The time
>difference is unmeasurably miniscule.
from the PEP
The library contains code such as _len=len which is intended to create fast
local references instead of slower global lookups. Though necessary for
performance, these constructs clutter the code and are usually incomplete
(missing many opportunities).
If the proposal is adopted, those constructs could be eliminated from the
code base and at the same time improve upon their results in terms of
if they are eliminated (_len = len), then CPython will win because of the
binding at load time
and the fact that time is not lost at each function call for binding them,
Jython will loose something
because if they were there, there was likely a reason.
>> Thanks, that must be it. I'll have to scrounge around for a way to
>> make syncmail figure out the submitter.
Just> If the submitters all have "regular" accounts on the machine
Just> running pserver, you can easily have each submitting process run
Just> as the proper user, by adding the user to the CVSROOT/passwd file,
Just> like so:
Just> this is:
Just> <pserver user name>:<crypt'ed password>:<run as this user>
Hot damn! That might be just the ticket. I'll try it with my own account
Discovering the 'opcode' module thanks to the new PEP 329 caused me to
wonder how many modules are undocumented and yet deserve to possibly be
(I also was procrastinating from doing schoolwork and felt like doing
some light coding =).
Below is a list of modules that might deserve some docs. Any with
numbers by them mean that a bug report has been filed to have them
If any of the modules below should not be documented, please speak up
(especially about the ones with SF bug reports since those could then be
closed; but they seem like modules that should get some docs).
Otherwise I would like to at least mention this list in the next
python-dev Summary in hopes someone will want to step forward and
document them. I would also like to file a bug report for each one that
doesn't have one yet so it at least gets recorded somewhere which
modules still need docs beyond just the mailing list archives.
trace.py 779976 737734
On Mon, Apr 19, 2004, Jewett, Jim J wrote:
> [Kevin Jacobs]
> #- Decimal('2.4000', precision=2, scale=1) == Decimal('2.4')
> #- Decimal('2.4', precision=5, scale=4) == Decimal('2.4000')
> #- Remember, these literals are frequently coming from an
> #- external source that must be constrained to a given schema.
>> I like it a lot, but not for Decimal.
> This is another face of "what do do with float"
> This has nothing to do with binary floating point. These are
> strings that map to exact numbers in Decimal;
Under the current implementation:
(0, (2, 4, 0, 0, 0), -4)
is not quite the same as
(0, (2, 4) -1)
Given this, is should be possible for the user to specify
(at creation) which is desired.
They do normalize to the same thing, but this requires
extending the second number with zeros.
(0, (1,), -17)
(0, (1, 1), -1)
The float discussions make it clear that "extend by zero"
may not always be the most accurate, and the python docs
do not yet prohibit extending by some other digit (that
rounds the same).
I agree that the programmer should specify if they want
something odd -- and that is precisely why the constructor
should take an optional context argument which allows the
user to specify precision.
Given that float input may well look like string (saved to a
file by another program) or even an integer (C double may have
more precision than C long) there is no particular reason to
say "context is only allowed when constructing from a float"
Terry Reedy writes:
> This 'bug' (and those already filed) could be minimally/temporarily
> disposed of by adding a page 'Modules Not Otherwise Documented' with the
> list and one sentence for each (plus status if discouraged/deprecated/etc)
> and then adding index entries pointing to this page. Also add
> indication/suggestion to try interactive help('modname') for the modules
> for which one will get something. Then people would know that they had not
> missed anything to be found in the Lib Ref.
But let's not jump into doing that just yet... perhaps Brett's listing
will attract some champions willing to document these orphan modules.
I'd really rather not give up on documenting a module unless we're
forced to... it's tantamount to giving up on the module itself!
In the future, of course, no new modules should be accepted without docs.
-- Michael Chermside
#- Decimal('2.4000', precision=2, scale=1) == Decimal('2.4')
#- Decimal('2.4', precision=5, scale=4) == Decimal('2.4000')
#- Remember, these literals are frequently coming from an
#- external source that must be constrained to a given schema.
> I like it a lot, but not for Decimal.
This is another face of "what do do with float"
Just because your default context has n digits of precision
doesn't mean that all your input will.
If my input has 2.4000 (but the extra zeros were measured)
then I want to keep that information.
If my input has 2.4 (and I didn't measure beyond those digits)
I want to know that for error analysis.
If my input has 1.1 (only measured to two digits) but my
context is 25, I don't want to assume that the machine's
float-rounding is correct; the fairest "I don't know"
estimate is still zero, even out to digit 100.