Michael Chermside wrote:
I tried several stranger things, like installing over 2.4.0 but in a
different directory. Everything worked like clockwork. I did NOT try
anything that would have involved a system with various things missing
(like lack of VBScript), but I did play around with alternate
[Tim Peters]
Summer.add() _can_ lose info -- it needs additional
trickery to make it loss-free, and because x+y can lose (at most one
bit) when x and y have the same binary exponent.
Computing an error term can get the bit back and putting that term back
in the input queue restores the
On Sat, 12 Mar 2005 11:38:50 +0100, Martin v. Löwis wrote:
Somebody reported that it failed to update python24.dll in
an update installation; not sure why this would be.
Because it was in use?
Kind regards,
Alexander
___
Python-Dev mailing list
Alexander Schremmer wrote:
Somebody reported that it failed to update python24.dll in
an update installation; not sure why this would be.
Because it was in use?
Perhaps. In that case, Installer should schedule a reboot, and
ask for the reboot when the installation is otherwise complete.
Regards,
Tim Peters wrote:
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.
Are you sure your
Leeuw van der, Tim wrote:
The generated files crash the Python interpreter with Python 2.4
Under Python 2.4.1c1, They give a syntax error!?
Even though the bug was fixed in pywin, it is interesting to observe
that Mark's analysis says
Cause of the underling crash is that the generated .py
causes
I seem to have a problem with the install on XP SP1. Python itself is
installed, but IDLE won't start. The error says: IDLE's subprocess
didn't make connection. Either IDLE can't start a subprocess or
personal firewall software is blocking the connection. I believe the
problem is the firewall,
On Sat, Mar 12, 2005, Jeremy Hylton wrote:
I seem to have a problem with the install on XP SP1. Python itself is
installed, but IDLE won't start. The error says: IDLE's subprocess
didn't make connection. Either IDLE can't start a subprocess or
personal firewall software is blocking the
Jeremy Hylton wrote:
I seem to have a problem with the install on XP SP1. Python itself is
installed, but IDLE won't start. The error says: IDLE's subprocess
didn't make connection. Either IDLE can't start a subprocess or
personal firewall software is blocking the connection. I believe the
So here's a list of open items I'm thinking about for the 2.4.1
release.
- os.access handling unicode filenames
I'm still thinking over whether this is going to cause more problems
for people who find it works for some Python 2.4 and not others. I'm
leaning towards saying that this
On Sunday 13 March 2005 01:19, Martin v. Löwis wrote:
Kurt B. Kaiser wrote:
1. Eliminating the separate IDLE versioning now that it's installed with
Python when Tcl/Tk is available.
2. Bringing its version in sync with Python 2.5.
3. Decouple Python and IDLE version numbers. I.e. IDLE
[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
from
[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]
Are you
[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 changesChanges to unitest to fix subclassing broke Zope's
unittests.
Martin v. Löwis [EMAIL PROTECTED] writes:
Kurt B. Kaiser wrote:
To eliminate this confusion I'd propose either 1. Eliminating the
separate IDLE versioning now that it's installed with Python when
Tcl/Tk is available. or 2. Bringing its version in sync with
Python 2.5. I'm in favor of the
On Fri, 11 Mar 2005, Josiah Carlson wrote:
My first reaction to the proposal was ick. Why? Because every time
I've seen a mechanism for modifying the internals of generators
constructed using yield, the syntax has been awful; in my opinion
(whether my opinion means anything is another matter),
Brian Sabbey [EMAIL PROTECTED] wrote:
On Fri, 11 Mar 2005, Josiah Carlson wrote:
My first reaction to the proposal was ick. Why? Because every time
I've seen a mechanism for modifying the internals of generators
constructed using yield, the syntax has been awful; in my opinion
Reinhold Birkenfeld wrote:
He proposes that
[x in list if x 0]
(which is currently undefined) be exactly equal to:
[x for x in list if x 0]
What about that?
But [x in list] means already something.
Supporting [x in list if condition] will complicate the parser and will
be error-prone if
Brian Sabbey [EMAIL PROTECTED] wrote:
(I) Give generators a __call__ method as an alternative to 'next'.
Method __call__ should take a single parameter: a function. Using
__call__ will cause the generator to start executing normally, but when a
'yield' is reached, the generator will invoke
the queue can be expected to grow to about half the length
of the original iterable by the time the original iterable is
exhausted.
x = z
mant, exp = frexp(x)
exp2sum[exp] = x
return sum(sorted(exp2sum.itervalues(), key=abs), 0.0)
The implementation
On Sat, 12 Mar 2005, Steven Bethard wrote:
The goals behind this seem a lot like the goals of PEP 288[1]. I
remember discussions suggesting code like:
def gen():
a, b, c=3 = yield 1
yield a + b*c
g = gen()
print g.next() # prints 1
print g.next(1, 2) # prints 7
But as you can see, this
You guys have way too much time on your hands and neurons devoted to
this stuff. I'm glad that means that I can spend the afternoon playing
w/ my kids and searching python-dev when I need to add numbers =).
___
Python-Dev mailing list
Martin v. Löwis [EMAIL PROTECTED] writes:
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.
I had some
Brian Sabbey [EMAIL PROTECTED] wrote:
I agree that this is a confusing way to use generators. But it is the
expected way to use code blocks as found in other languages. It would
take some getting used to that 'for' can be used this way, but I think it
would be worth it.
I guess I need some
On Sat, 12 Mar 2005, Steven Bethard wrote:
Brian Sabbey [EMAIL PROTECTED] wrote:
I agree that this is a confusing way to use generators. But it is the
expected way to use code blocks as found in other languages. It would
take some getting used to that 'for' can be used this way, but I think it
On Sat, 12 Mar 2005, Josiah Carlson wrote:
I stand by my clever hack statement, and I will agree to disagree with
you on it, like I agree to disagree with you about both the necessity of
passing arbitrary values back into a generator (I think it is poor
style, and too much brain overhead to
Brian Sabbey [EMAIL PROTECTED] wrote:
On Sat, 12 Mar 2005, Josiah Carlson wrote:
I stand by my clever hack statement, and I will agree to disagree with
you on it, like I agree to disagree with you about both the necessity of
passing arbitrary values back into a generator (I think it is
Nick Coghlan wrote:
A suggestion was made on c.l.p a while back to have a specific module
dedicated to reductive operations. That is, just as itertools is
oriented towards manipulating iterables and creating iterators, this
module would be oriented towards consuming iterators in a reductive
Brian Sabbey wrote:
I prefer re-using the 'for' loop for this purpose because it allows the
problem to be solved in a general way by re-using a structure with which
most users are already familiar, and uses generators, which are easier
to use in this case than defining a class with __exit__,
Nick Coghlan wrote:
That 'x in seq' bit still shouts containment to me rather than
iteration, though.
Perhaps repurposing 'from':
(x from seq if f(x))
That rather breaks TOOWTDI though (since it is essentially new syntax
for a for loop). And I have other hopes for the meaning of (x from ()).
Anthony Baxter wrote:
So here's a list of open items I'm thinking about for the 2.4.1
release.
- os.access handling unicode filenames
I'm still thinking over whether this is going to cause more problems
for people who find it works for some Python 2.4 and not others. I'm
leaning towards
31 matches
Mail list logo
