[Neal Norwitz]
> There were some SystemErrors on one of the Windows build slaves.
Not always, though -- looks to be rare.
> Does anyone have any ideas what might be the cause? I looked through about
> 5 previous logs on the same slave and didn't see the same problem.
I'm home today and fired up
[Neal Norwitz]
> ...
> The way to fix the files is to run: python ./Tools/scripts/reindent.py -r Lib
I apply it to everything in the checkout. That is, I run reindent.py
from the root of my sandbox, and use "." instead of "Lib". The goal
is that every .py file (not just under Lib/) that eventua
[Skip]
> Maybe \s should expand to a single space by the lexer so people who want to
> rely on trailing spaces can be explicit about it. There already exists
> non-whitespace escape sequences for tabs and newlines.
Trailing whitspace is never significant on a code line, only inside a
multiline st
[Skip]
> Just a little FYI, python-mode (the one Barry and I manage - dunno about the
> one distributed w/ GNU Emacs these days) is one of those tools that leaves
> trailing whitespace behind when advancing to the next line..
Shouldn't be -- unless the behavior of the Emacs newline-and-indent
has
[Neal Norwitz]
>> In rev 54982 (the first time this crash was seen), I see something
>> which might create a problem. In python/trunk/Modules/posixmodule.c
>> (near line 6300):
>>
>> + PyMem_FREE(mode);
>>Py_END_ALLOW_THREADS
Shouldn't do that.
[Brett Cannon]
> The PyMem_MALLOC cal
[Raymond Hettinger]
> ...
> My intention for the module is to be fully compliant with the spec and all of
> its
> tests. Code written in other languages which support the spec should expect
> to be transferrable to Python and run exactly as they did in the original
> language.
>
> The module its
[Greg Ewing]
>> Taking a step back from all this, why does Python allow
>> NaNs to arise from computations *at all*?
[Mark Dickinson]
> History, I think. There's a c.l.p. message from Tim Peters somewhere
> saying something along the lines that he'd love to make (e.g
[Armin Rigo]
> On another level, would there be interest here for me to revive my old
> attempt at throwing away this messy procedure, which only made sense in
> a world where reference cycles couldn't be broken?
Definitely.
> Nowadays the fact that global variables suddenly become None when the
[Nick Coghlan]
> test_pow is failing on the alpha Debian buildbot, complaining that a
> negative number can't be raised to a fractional power. Now, to work
> around some bugs in platform implementations of math.fpow(), pow() does
> its own check to see if the exponent is an integer.
>
> The way pow
[EMAIL PROTECTED]
> Thanks for the pointer. Given that it's [round-to-even[ been an ASTM
> standard since 1940 and apparently in fairly common use since the
> early 1900s, I wonder why it's not been more widely used in the past
> in programming languages.
Because "add a half and chop" was also in
[Tim]
>> Because "add a half and chop" was also in wide use for even longer, is
>> also (Wikipedia notwithstanding) part of many standards (for example,
>> the US IRS requires it if you do your taxes under the "round to whole
>> dollars" option), and-- probably the real driver --is a little cheaper
[Mark Dickinson]
> quantize is about as close as it gets. Note that it's a Decimal method as
> well as a Context method, so you can invoke it directly on a given decimal:
>
>
> >>> Decimal("2.34567").quantize(Decimal("0.01"))
> Decimal("2.35")
This "reads better" in many cases if you define a con
[Tim]
>> Curiously, round-to-nearest
>> can be unboundedly more expensive to implement in some obscure
>> contexts when floats can have very large exponents (as they can in
>> Python's "decimal" module -- this is why the proposed decimal standard
>> allows operations like "remainder-near" to fail i
What would be useful is a method that generates (i.e., a generator in
the Python sense) the (continued fraction) convergents to a rational.
People wanting specific constraints on a rational approximation
(including, but not limited to, the two you identified) can easily
build them on top of such a
[Neal Norwitz]
> It's not just size. Architectures may require data aligned on 4, 8,
> or 16 addresses for optimal performance depending on data type. IIRC,
> malloc aligns by 8 (not sure if that was a particular arch or very
> common).
Just very common. Because malloc has no idea what the poin
[Barry]
> ...
> How about we recruit additional moderators? Any volunteers?
Sure -- add me as a python-dev admin, send me the password, and go
back to eating in peace :-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/l
[Antoine Pitrou]
>> Would it be helpful if the GC was informed of memory growth by the
>> Python memory allocator (that is, each time it either asks or gives back
>> a block of memory to the system allocator) ?
[Martin v. Löwis]
> I don't see how. The garbage collector is already informed about me
[Michael Foord]
>> ...
>> Adding the following new asserts:
>>
>> ...
>> assertNotIs (first, second, msg=None)
[Steve Holden]
> Please, let's call this one "assertIsNot".
+1
> I know it's valid Python to say
>
> if a not is b:
Nope, that's a syntax error.
> but it's a much less natural wa
[Guido]
> My best guess as to why 'F' is the same as 'f' is that somebody
> (could've been me :-) thought, like several others in this thread,
> that %f never prints an exponent. I agree that making it emit an 'E'
> when an exponent is used is the right thing to do. Do it now!
The C standard doesn
;> efficient 32bit*32bit -> 64bit multiply so there is no good reason to
>> limit python itself to 15bit digits when on either x86 or x86_64.
[Martin v. Löwis]
> Perhaps Tim Peters should also comment here - but if you can come up
> with a patch that does that in a portable way, I w
27;t know
whether that was adopted. I do know that "*" remained "single-width".
[Tim Peters]
>> Note that while 32x32->64 multiply is supported by x86 HW, that
>> doesn't mean there's a uniform way to get at this HW capability across
>> C compi
[Tim Peters]
>> ..
>> Whenever two digits are multiplied, the code intends to
>> cast (at least) one of them to "twodigits" first (if you
>> ever see a spot where this doesn't happen, it's a bug).
[Mark Dickinson]
> There are indeed one or two spot
[M.-A. Lemburg]
>> These long exit times are usually caused by the garbage collection
>> of objects. This can be a very time consuming task.
[Leif Walsh]
> In that case, the question would be "why is the interpreter collecting
> garbage when it knows we're trying to exit anyway?".
Because user-de
[Mike Coleman]
>> ... Regarding interning, I thought this only worked with strings.
Implementation details. Recent versions of CPython also, e.g.,
"intern" the empty tuple, and very small integers.
>> Is there some way to intern integers? I'm probably creating 300M
>> integers more or less unif
[Leif Walsh]
> ...
> It might be a semantic change that I'm looking for here, but it seems
> to me that if you turn off the garbage collector, you should be able
> to expect that either it also won't run on exit,
It won't then, but "the garbage collector" is the gc module, and that
only performs /
I can't find it now, but I believe Marc-Andre mentioned that CPython's
list.sort() was vulnerable to attack too, because of its O(n log n)
worst-case behavior.
I wouldn't worry about that, because nobody could stir up anguish
about it by writing a paper ;-)
1. O(n log n) is enormously more forgiv
[Anthony Baxter]
> I didn't see any replies to the last post, so I'll ask again with a
> better subject line - as I said last time, as far as I'm aware, I'm
> not aware of anyone having done a fix for the issue Tim identified
> ( http://www.python.org/sf/1069160 )
>
> So, my question is: Is this i
FYI, I just changed SF so that bugs with Category "Regular
Expressions" are auto-assigned to Gustavo (they were being
auto-assigned to Fredrik, which doesn't appear to do much good
anymore).
[Gustavo Niemeyer]
> I'm really ashamed. The SRE bug #1072259, reported in
> 2004-11-24, and fixed a few mi
[EMAIL PROTECTED]
> Removed Files:
>whrandom.py
> Log Message:
> Remove the deprecated whrandom module.
Woo hoo! It's about friggin' time .
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscr
[Andreas Jung]
> While using Zope 2.7
Do you mean 2.7, or do you mean 2.7.3, or ...?
> with Python 2.4 we discovered some strange behaviour
> of the security machinery.
> I could track this down to some Zope code in cAccessControl.c
> where an Unauthorized exception is raised because of a call to
[Jim Fulton]
> Ugh. Part of the problem is that all of those calls are unchecked,
> Dang us. If they were checked, then, who knows, we might have
> gotten informative exceptions.
They certainly "should" be checked, but as a pragmatic matter
PyInt_FromLong(1) can't fail -- Python allocates an int
[Tim]
>> ... but as a pragmatic matter PyInt_FromLong(1) can't fail --
[Jim]
> I know. I'm sure that's why we don't bother. But, obviously,
> it can fail.
I disagree -- it's not obvious at all. Looking at the code, it's far
more likely that Andreas misunderstood the cause of the failure than
th
[A.M. Kuchling]
> Is it possible that some other Python API call is raising an
> exception, but a NULL return isn't being checked for, and
> PyInt_FromLong() happens to be the first bit of code that does 'if
> (PyErr_Occurred())'? Though from a quick glance at
> PyInt_FromLong() and the macros it
[Andreas Jung]
> Sorry, false alarm :-( There assignment of the NULL occurs in the
> if-clause of the corresponding code (I have overseen the ASSIGN
> call):
Thanks for the followup!
>if (! PyInt_Check(p))
> {
>if (PyDict_Check(p))
>>> if (! PyInt_Check(p))
>>> {
>>> if (PyDict_Check(p))
>>> {
>>> if (PyString_Check(name) || PyUnicode_Check(name))
>>> {
>>> ASS
[Raymond, says test_glob and test_urllib fail on WinME now]
[Andrew MacIntyre]
>> I don't see any possible way for those checkins to affect any platform
>> other than OS/2.
>>
>> 2 of the files are platform specific files (PC/os2emx/getpath.c,
>> PC/os2vacpp/getpath.c), and the checkin to Modules/
[Jeremy Hylton on a quick 2.4.1]
>>> Nothing wrong with an incremental release, but none of these sound
>>> like critical bugs to me.
[Aahz]
>> You don't think a blowup in marshal is critical? Mind expanding on
>> that?
[Jeremy]
> An undocumented extension to marshal causes a segfault. It's
> c
[Armin Rigo]
> Some code in the 'py' lib used to use marshal to send simple objects between
> the main process and a subprocess. We ran into trouble when we extended the
> idea to a subprocess that would actually run via ssh on a remote machine, and
> the remote machine's Python version didn't mat
[Bob Ippolito]
> Quite a few notable places in the Python sources expect realloc(...) to
> relinquish some memory if the requested size is smaller than the
> currently allocated size.
I don't know what "relinquish some memory" means. If it means
something like "returns memory to the OS, so that t
[Bob Ippolito]
> ...
> Your expectation is not correct for Darwin's memory allocation scheme.
> It seems that Darwin creates allocations of immutable size. The only
> way ANY part of an allocation will ever be used by ANYTHING else is if
> free() is called with that allocation.
Ya, I understood t
[Tim Peters]
>> Ya, I understood that. My conclusion was that Darwin's realloc()
>> implementation isn't production-quality. So it goes.
[Bob Ippolito]
> Whatever that means.
Well, it means what it said. The C standard says nothing about
performance metrics of a
[Bob Ippolito]
> ...
> What about for list objects that are big at some point, then
> progressively shrink, but happen to stick around for a while? An
> "event queue" that got clogged for some reason and then became stable?
It's less plausible that we''re going to see a lot of these
simultaneousl
[Guido]
> In my blog I wrote:
>
> Let's get rid of unbound methods. When class C defines a method
> f, C.f should just return the function object, not an unbound
> method that behaves almost, but not quite, the same as that
> function object. The extra type checking on the first argument that
> un
[EMAIL PROTECTED]
> I submitted patch "[ 742621 ] ast-branch: msvc project sync" in
> the VC6.0 days. There were some required changes to headers
> as well as the project files. It had discouraged me in the past
> when Jeremy made calls for help on the astbranch and I wasn't
> even sure if the so
[Tim Peters]
>> ... Unbound methods are used most often (IME) to call a
>> base-class method from a subclass, like
>> my_base.the_method(self, ...).
>> It's especially easy to forget to write `self, ` there, and the
>> exception msg then is quite focused b
[Guido]
>> Then why is the title "Python's Super Considered Harmful" ???
>>
>> Here's my final offer. Change the title to something like "Multiple
>> Inheritance Pitfalls in Python" and nobody will get hurt.
[Bill Janssen]
> Or better yet, considering the recent thread on Python marketing,
> "Mul
[Andrew McNamara]
>> Also, review comments from Jeremy Hylton, 10 Apr 2003:
>>
>>I've been reviewing extension modules looking for C types that should
>>participate in garbage collection. I think the csv ReaderObj and
>>WriterObj should participate. The ReaderObj it contains a referen
[Martin asks whether Irmen wants to be a tracker admin on SF]
[Irmen de Jong]
> That sounds very convenient, thanks.
> Does the status of 'python project member' come with
> certain expectations that must be complied with ? ;-)
If you're using Python, you're already required to comply with all of
[Martin v. Löwis]
...
> - Add an entry to Misc/NEWS, if there is a new feature,
> or if it is a bug fix for a maintenance branch
> (I personally don't list bug fixed in the HEAD revision,
> but others apparently do)
You should. In part this is to comply with license requirements:
we're a d
[Tim Peters]
>> It's also extremely useful in practice to have a list of repaired
>> bugs in NEWS!
[Martin v. Löwis]
> I'm not convinced about that - it makes the NEWS file almost
> unreadable, as the noise is now so high if every tiny change is
> listed; it is very
[Anthony Baxter]
>>> I didn't see any replies to the last post, so I'll ask again with a
>>> better subject line - as I said last time, as far as I'm aware, I'm
>>> not aware of anyone having done a fix for the issue Tim identified
>>> ( http://www.python.org/sf/1069160 )
>>>
>>> So, my question is
...
[Evan Jones]
> What I was trying to ask with my last email was what are the trouble
> areas? There are probably many that I am unaware of, due to my
> unfamiliarity the Python internals.
Google on "Python free threading". That's not meant to be curt, it's
just meant to recognize that the tas
[Thomas Heller]
> ...
> For the spambayes binary, maybe there should be another person adding
> the msvcr71.dll to the distribution that Tony builds? Someone who has a
> MSVC license, and also is developer on the spambayes project?
To the best of my knowledge, Tony is distributing my duly license
[Anthony Baxter]
>> Ok, so here's the state of play: 2.3.5 is currently aimed for next
>> Tuesday, but there's an outstanding issue - the new copy code appears
>> to have broken something, see www.python.org/sf/1114776 for the gory
>> details.
...
[Alex Martelli]
> The problem boils down to: deepc
[Matthias Klose]
> A Debian user pointed out (http://bugs.debian.org/293932), that the
> current license for the Python profiler is not conforming to the DFSG
> (Debian free software guidelines).
>
> http://www.python.org/doc/current/lib/node829.html states
>
> "This permission is explicitly restr
[Trent Mick]
> The copyright date was updated to 2005 in Python/getcopyright.c. Should
> the same be done in PC/python_nt.rc?
Yes.
> Or perhaps, is there any reason python_nt.rc should NOT be updated?
Only reason I can think of is your inexcusable laziness for not having
done it yourself .
_
[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.dateti
[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),
[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 conj
[Trent Mick]
> Has anyone else noticed that viewcvs is broken on SF?
It failed the same way from Virginia just now. I suppose that's your
reward for kindly updating the Python copyright .
The good news is that you can use this lull in your Python work to
contribute to ZODB development! ViewCVS
t, y and z. We are currently working on
resolving this issue.
So that means it wouldn't even do us any good to rename the project to
Thomas, Trent, Mick, Tim, Peters, or ZPython either! All right.
Heller 2.5, here we come.
___
Python-Dev mailing
[Jeremy Hylton]
>> Unfortunately a license that says it is in the public domain is
>> unacceptable (and should be for Debian, too). That is to say, it's
>> not possible for someone to claim that something they produce is in
>> the public domain. See http://www.linuxjournal.com/article/6225
[Mich
[Troels Walsted Hansen]
> The Python binding in libxml2 uses the following code for __repr__():
>
> class xmlNode(xmlCore):
> def __init__(self, _obj=None):
> self._o = None
> xmlCore.__init__(self, _obj=_obj)
>
> def __repr__(self):
> return "" % (self.name, id (se
[James Y Knight]
> I think it'd be nice to change it, too. Twisted also uses a similar
> function.
>
> However, last time this topic came up, this Tim Peters guy argued
> against it. ;)
>
> Quoting
> http://mail.python.org/pipermail/python-dev/2004-November/0500
[Gfeller Martin]
> I'm running a large Zope application on a 1x1GHz CPU 1GB mem
> Window XP Prof machine using Zope 2.7.3 and Py 2.3.4
> The application typically builds large lists by appending
> and extending them.
That's historically been an especially bad case for Windows systems,
although the
[Fredrik Lundh]
> can anyone explain the struct.pack and ZODB use cases? the first one
> doesn't make sense to me,
Not deep and surely not common, just possible. If you're on a 32-bit
box and doing struct.pack("...i...", ... id(obj) ...), it in fact
cannot fail now (no, that isn't guaranteed by
[Fredrik Lundh]
> does anyone remember if there were any big changes in pymalloc between
> the 2.1 series (where it was introduced) and 2.3 (where it was enabled by
> default).
Yes, huge -- few original lines survived exactly, although many
survived in intent.
> or in other words, is the 2.1.3 py
[Evan Jones]
> After I finally understood what thread-safety guarantees the Python
> memory allocator needs to provide, I went and did some hard thinking
> about the code this afternoon. I believe that my modifications provide
> the same guarantees that the original version did. I do need to declar
[Tim Peters]
>> As I said before, I don't think we need to support this any more.
>> More, I think we should not -- the support code is excruciatingly
>> subtle, it wasted plenty of your time trying to keep it working, and
>> if we keep it in it's going to cont
Rev 2.66 of funcobject.c made func.__name__ writable for the first
time. That's great, but the patch also introduced what I'm pretty
sure was an unintended incompatibility: after 2.66, func.__name__ was
no longer *readable* in restricted execution mode. I can't think of a
good reason to restrict
[Michael Hudson]
> ...
> Well, I fixed it on reading the bug report and before getting to
> python-dev mail :) Sorry if this duplicated your work, but hey, it was
> only a two line change...
Na, the real work was tracking it down in the bowels of Zope's C-coded
security machinery -- we'll let you
[Michael Hudson]
> ...
> Well, I fixed it on reading the bug report and before getting to
> python-dev mail :) Sorry if this duplicated your work, but hey, it was
> only a two line change...
Na, the real work was tracking it down in the bowels of Zope's C-coded
security machinery -- we'll let you
[Fredrik Lundh]
> does anyone ever use the -u options when running tests?
Yes -- I routinely do -uall, under both release and debug builds, but
only on Windows. WinXP in particular seems to do a good job when
hyper-threading is available -- running the tests doesn't slow down
anything else I'm do
[sorry for the near-duplicate msgs -- looks like gmail lied when it claimed the
first msg was still in "draft" status]
>> Did you add a test to ensure this remains fixed?
[mwh]
> Yup.
Bless you. Did you attach a contributor agreement and mark the test
as being contributed under said contributo
[Raymond Hettinger]
>> For test_subprocess, consider adopting the technique used by
>> test_decimal. When -u decimal is not specified, a small random
>> selection of the resource intensive tests are run. That way, all of the
>> tests eventually get run even if no one is routinely using -u all.
[
[Tim Peters]
>> # This is a puzzle: there's no way to know the natural width of
>> # addresses on this box (in particular, there's no necessary
>> # relation to sys.maxint).
[Armin Rigo]
> Isn't this natural width nowadays available a
H can handle. Its limit is 16KB. A Python
list with 50K elements requires a contiguous chunk of 200KB on a
32-bit machine to hold the list guts.
> As I said, I don't speak C, so I can only speculate - do the lists at some
> point
>grow beyond the upper limit of obmalloc, but are ha
[Tim Peters]
...
>> Then you allocate a small object, marked 's':
>>
>> bbbsfff
[Evan Jones]
> Isn't the whole point of obmalloc
No, because it doesn't matter what follows that introduction:
obmalloc has sev
[Phillip J. Eby]
>> Still, it's rather interesting that tuple.__contains__ appears slower than a
>> series of LOAD_CONST and "==" operations, considering that the tuple
>> should be doing basically the same thing, only> without bytecode fetch-and-
>> decode overhead. Maybe it's tuple.__contains__
[Raymond Hettinger]
> ...
> The problem with the transformation was that it didn't handle the case
> where x was non-hashable and it would raise a TypeError instead of
> returning False as it should.
I'm very glad you introduced the optimization of building small
constant tuples at compile-time.
[Tim Peters]
>> grow the list to its final size once, at the start (overestimating if
>> you don't know for sure). Then instead of appending, keep an index to
>> the next free slot, same as you'd do in C. Then the list guts never
>> move, so if that doesn't
[EMAIL PROTECTED]
> Modified Files:
>compile.c
> Log Message:
> Teach the peepholer to fold unary operations on constants.
>
> Afterwards, -0.5 loads in a single step and no longer requires a runtime
> UNARY_NEGATIVE operation.
Aargh. The compiler already folded in a leading minus for int
Florent Guillaume recently wrote a valuable addin for Zope:
http://www.zope.org/Members/nuxeo/Products/DeadlockDebugger
When a Zope has threads that are hung, this can give a report of
Python's current state (stack trace) across all threads -- even the
ones that are hung (the deadlocked threa
[Phillip J. Eby]
> What would you suggest calling it? sys._current_frames(), returning a
> dictionary?
I don't fight about names -- anything that doesn't make Guido puke
works . I channel that sys._current_frames() would be fine. A
dict mapping thread id to current thread frame would be lovely!
[Fazal Majid]
> Since I started this, I might as well finish it. I do have some Python
> developer experience (hey, I even voted for comp.lang.python back
> when...) but not in the core interpreter itself.
Cool! WRT your current module, it would need changes to follow
Python's C coding style, to
[Greg Ward]
>> What would be *really* spiffy is to provide a way for
>> externally-triggered thread dumps. This is one of my top two Java
>> features [1]. The way this works in Java is a bit awkward --
>> "kill -QUIT" the Java process and it writes a traceback for every
>> running thread to stdou
I don't know how far I'll get with this. Using the current
Zope-2_7-branch of the Zope module at cvs.zope.org:/cvs-repository,
building Zope via
python setup.py build_ext -i
worked fine when I got up today, using the released Python 2.4. One
of its tests fails, because of a Python bug that
[Anthony Baxter]
> It works on Linux, with Zope 2.7.4.
Thanks!
> Just as a note to others (I've mentioned this to Tim already) if you set an
> environment variable DISTUTILS_DEBUG before running a setup.py, you get
> very verbose information about what's going on, and, more importantly, full
> tr
This is going to need someone who understands distutils internals.
The strings we end up passing to putenv() grow absurdly large, and
sooner or later Windows gets very unhappy with them.
os.py has a
elif name in ('os2', 'nt'): # Where Env Var Names Must Be UPPERCASE
class controlling intro
[ A.M. Kuchling]
> In distutils.msvccompiler:
>
>def __init__ (self, verbose=0, dry_run=0, force=0):
>...
>self.initialized = False
>
>def compile(self, sources,
>output_dir=None, macros=None, include_dirs=None, debug=0,
>extra_preargs=None,
[Tres Seaver]
> Unit tests for Zope 2.7.4's 'zdaemon' package, which passed under Python
> 2.4, now fail under 2.4.1c1:
Are you sure they passed under 2.4? Derrick Hudson changed run() to
_run() in the SVN version of zdaemon way back on Jan 19, with this
checkin comment:
Log message for rev
[Martin v. Löwis]
> I'd like to encourage feedback on whether the Windows installer works
> for people. It replaces the VBScript part in the MSI package with native
> code, which ought to drop the dependency on VBScript, but might
> introduce new incompatibilities.
Worked fine here. Did an all-de
[Trent Mick]
> http://mail.python.org/pipermail/python-checkins/2005-March/045185.html
>
> Note that I also could not build PyWin32 against 2.4.1c1 and I suspect
> this was the same problem. (Still checking to see if this change fixes
> the PyWin32 build for me.)
Be sure to speak up if it doesn't
[Trent Mick]
> Investigation has turned up that I cannot keep my Python trees straight.
> That patch *does* fix building PyWin32 against 2.4.1c1.
Good! Please send a check for US$1000.00 to the PSF by Monday .
___
Python-Dev mailing list
Python-Dev@pyth
FYI, there are a lot of ways to do accurate fp summation, but in
general people worry about it too much (except for those who don't
worry about it at all -- they're _really_ in trouble <0.5 wink>).
One clever way is to build on that whenever |x| and |y| are within a
factor of 2 of each other, x+y
[Tim Peters]
...
> One clever way is to build on that whenever |x| and |y| are within a
> factor of 2 of each other, x+y is exact in 754 arithmetic.
Ack, I'm fried. Forget that, it's wrong. The correct statement is
that x-y is always exact whenever x and y are within a facto
[Raymond Hettinger]
> Computing an error term can get the bit back and putting that term back
> in the input queue restores the overall sum.
Right!
> Once the inputs are exhausted, the components of exp2sum should be exact.
Ditto. I'll cover some subtleties below:
> from math import frexp
> f
[Tim]
>> Don't think it's needed on HEAD. As the checkin comment said:
>>
>> This doesn't appear to be an issue on the HEAD (MSVCCompiler initializes
>> itself via __init__() on the HEAD).
>>
>> I verified by building Zope with unaltered HEAD too, and had no
>> problem with that.
[Martin]
[Anthony Baxter]
> So here's a list of open items I'm thinking about for the 2.4.1
> release.
>
> [... sorry, but my editor automatically deletes all paragraphs
> mentioning problems with Unicode ...]
> - The unitest changes>Changes to unitest to fix subclassing broke Zope's
>unittes
[Raymond Hettinger]
> The approach I'm using relies on being able to exactly multiply the 0 or
> 1 bit error term mantissas by an integer (a count of how many times the
> term occurs). With a Python dictionary keeping the counts, many steps
> are saved and the tool becomes much more memory friendl
501 - 600 of 1049 matches
Mail list logo
