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 ins
> [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 ove
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,
M
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 a
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 latter, to handle the situation where a custo
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 th
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
pr
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 i
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.
On Sat, 12 Mar 2005 10:53:06 -0500, Jeremy Hylton <[EMAIL PROTECTED]> 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
[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 wrote:
I'm now pretty sure we need a 2.4.1rc2 for this week, and a 2.4.1 final the
week after. There's been a few too many changes for my tastes to say that
going straight to a 2.4.1 final is a prudent course of action.
"The week after" will by the PyCon week, in which I won't be ab
[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
"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 fa
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 op
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 i
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 invo
> 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
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 creat
On Sat, 12 Mar 2005, Josiah Carlson wrote:
I say it is magical. Why? The way you propose it, 'yield' becomes an
infix operator, with the name provided on the left being assigned a
value produced by something that isn't explicitly called, referenced, or
otherwise, by the right. In fact, I would s
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
Python-Dev@python.or
"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 h
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 nee
Brian Sabbey <[EMAIL PROTECTED]> wrote:
>
> On Sat, 12 Mar 2005, Josiah Carlson wrote:
>
> > I say it is magical. Why? The way you propose it, 'yield' becomes an
> > infix operator, with the name provided on the left being assigned a
> > value produced by something that isn't explicitly called
[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
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 i
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 wo
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
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 fash
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__, __e
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 s
On Mar 13, 2005, at 08:35, Robey Pointer wrote:
In other words, I don't think that the argument "users may have
written code to work around the bug" is a valid reason to not fix a
bug.
+1, as long as the bugfix doesn't break the workaround (and os.access's
bug seems to meet this criterion).
Ale
38 matches
Mail list logo
