Re: [Python-Dev] RELEASED Python 2.4.1, release candidate 1
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 install locations, repairs, uninstalls, single-user and all-user installs, and I found no problems anywhere. Nice work! Thanks! Somebody reported that it failed to update python24.dll in an update installation; not sure why this would be. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] sum()
> [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 overall sum. Once the inputs are
exhausted, the components of exp2sum should be exact.
from math import frexp
from itertools import chain
def summer2(iterable):
exp2sum = {}
queue = []
for x in chain(iterable, queue):
mant, exp = frexp(x)
while exp in exp2sum:
y = exp2sum.pop(exp)
z = x + y
d = x - z + y # error term
assert z + d == x + y
if d:
queue.append(d)
x = z
mant, exp = frexp(x)
exp2sum[exp] = x
return sum(sorted(exp2sum.itervalues(), key=abs), 0.0)
The implementation can be tweaked to consume the error term right away
so the queue won't grow by more than few pending items. Also, the speed
can be boosted by localizing frexp, exp2sum.pop, and queue.append.
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: RELEASED Python 2.4.1, release candidate 1
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: RELEASED Python 2.4.1, release candidate 1
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, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: distutils fix for building Zope against Python 2.4.1c1
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 HEAD is current? My copy of msvccompiler.py 1.67 reads
def __init__ (self, verbose=0, dry_run=0, force=0):
CCompiler.__init__ (self, verbose, dry_run, force)
self.__version = get_build_version()
if self.__version >= 7:
self.__root = r"Software\Microsoft\VisualStudio"
self.__macros = MacroExpander(self.__version)
else:
self.__root = r"Software\Microsoft\Devstudio"
self.initialized = False
def initialize(self):
self.__paths = self.get_msvc_paths("path")
...
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python2.4.1c1 and win32com
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 an overflow as the byte-code is generated - something in 2.4 bloated the byte-code for these modules." There also seems to be an interaction with PEP 263, for which patch 1101726 might provide a solution. So I think this needs to be investigated; please submit a bug report, including the Python file that causes the crash. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Lib/idlelib NEWS.txt, 1.49.2.3, 1.49.2.4 idlever.py, 1.22.2.1, 1.22.2.2
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 customized IDLE is decoupled from Python. I think there is a 3rd option: 3. Decouple Python and IDLE version numbers. I.e. IDLE version numbers should change only when the IDLE maintainer thinks they should, not when the Python release manager bumps the Python versions. For 2.4.1, the IDLE version number should just be rolled back (or forward) to "1.1.1". Unless you plan to include IDLE 1.1.2 with Python 2.4.2, it will stay at 1.1.1 in the 2.4 branch. Whether or not updating the IDLE code base to include new features is another issue - it might be that an exception can be made for IDLE; OTOH, it might be reasonable to apply the same strict requirements for idlelib as we do for the rest of the Python library, i.e. no new features. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: RELEASED Python 2.4.1, release candidate 1
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, but I'm not sure if it is related to the install. The previous install (Python 2.3) worked fine. Jeremy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: RELEASED Python 2.4.1, release candidate 1
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 connection." I believe the > problem is the firewall, but I'm not sure if it is related to the > install. The previous install (Python 2.3) worked fine. http://www.python.org/2.4/bugs.html -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death." --GvR ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: RELEASED Python 2.4.1, release candidate 1
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 problem is the firewall, but I'm not sure if it is related to the install. The previous install (Python 2.3) worked fine. What firewall software are you using? Any exceptions in the console when starting IDLE? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Open issues for 2.4.1
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 is a bug fix, but I'd appreciate any comments (pro or con). If no-one comments, I'll go with whatever my gut feeling says is the right answer. - The unitest changes Changes to unitest to fix subclassing broke Zope's unittests. Should this change be reverted before 2.4.1, or was the Zope test suite doing something particularly dodgy? I'm talking about - unittest.TestCase.run() and unittest.TestSuite.run() can now be successfully extended or overridden by subclasses. Formerly, the subclassed method would be ignored by the rest of the module. (Bug #1078905). I've not looked too closely at the broken Zope code - can someone from ZC comment? How likely is it that other programs will also have been broken by this? At this point, I'm leaning (very slightly) towards the feeling that this should probably be backed out before 2.4.1, mostly because it seems to me that this is an incompatibility, rather than a pure bug fix. 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. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Lib/idlelib NEWS.txt, 1.49.2.3, 1.49.2.4 idlever.py, 1.22.2.1, 1.22.2.2
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 version numbers > should change only when the IDLE maintainer thinks they should, not > when the Python release manager bumps the Python versions. This is only a brief note here - I have a longer post coming on the subject of uncoupled libraries in the Python core (triggered by Greg's recent Optik post), but I doing mind any of the options above. I'm wondering if we shouldn't have a centralised place in the CVS for these version numbers? > For 2.4.1, the IDLE version number should just be rolled back (or > forward) to "1.1.1". Unless you plan to include IDLE 1.1.2 with Python > 2.4.2, it will stay at 1.1.1 in the 2.4 branch. > > Whether or not updating the IDLE code base to include new features > is another issue - it might be that an exception can be made for IDLE; I would be very strongly against this. If the code is distributed as part of the stdlib, it should conform to the same rules as the rest of the stdlib. > OTOH, it might be reasonable to apply the same strict requirements > for idlelib as we do for the rest of the Python library, i.e. no new > features. Exactly right. Expecting users to understand that "no new features, except for this or that or the other package" is unreasonable, particularly when the delimiter is the (from a user's point of view) arbitrary distinction based on whether the source of the module is also separately available. See back to my earlier post of the subject of the rationale behind no-new-features - if we're going to keep to this, we should do it right. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: RELEASED Python 2.4.1, release candidate 1
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 firewall software is blocking the connection." I believe the > problem is the firewall, but I'm not sure if it is related to the > install. The previous install (Python 2.3) worked fine. Did your firewall have an exception for Python 2.3, which doesn't apply to 2.4 (for example, it included the full path to the exempted executable)? Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sum()
[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 itertools import chain
>
> def summer2(iterable):
>exp2sum = {}
>queue = []
>for x in chain(iterable, queue):
>mant, exp = frexp(x)
>while exp in exp2sum:
>y = exp2sum.pop(exp)
>z = x + y
>d = x - z + y # error term
>assert z + d == x + y
Much more is true there, but hard to assert in Python: the
mathematical sum z+d is exactly equal to the mathematical sum x+y
there, and the floating-point |d| is less than 1 unit in the last
place relative to the floating-point |z|. It would be clearer to name
"z" as "hi" and "d" as "lo".
More, that's not _generally_ true: it relies on that x and y have the
same binary exponent. For example, pick x=1 and y=1e100, and you end
up with hi=1e100 and lo=0. The mathematical x+y isn't equal to the
mathematical hi+lo then. It's a real weakness of "Kahan summation"
that most spellings of it don't bother to account for this; it's
sufficient to normalize first, swapping x and y if necessary so that
abs(x) >= abs(y) (although that isn't needed _here_ because we know
they have the same binary exponent). There's another way to handle
the general case that doesn't require test, branch, or abs(), but at
the cost of several more addition/subtractions.
>if d:
>queue.append(d)
If x and y have different signs, this part doesn't trigger. If all
inputs are positive, then we expect it to trigger about half the time
(the cases where exactly one of x's and y's least-significant bits is
set). So 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 can be tweaked to consume the error term right away
> so the queue won't grow by more than few pending items.
Theorem 10 in Shewchuk's "Adaptive Precision Floating-Point Arithmetic
and Fast Robust Geometric Predicates" gives the obvious correct
way to do that, although as a practical matter it greatly benifits
from a bit more logic to eliminate zero entries as they're produced
(Shewchuk doesn't because it's not his goal to add a bunch of
same-precision floats). BTW, extracting binary exponents isn't
necessary in his approach (largely specializations to "perfect" 754
arithmetic of Priest's earlier less-demanding methods).
> Also, the speed can be boosted by localizing frexp, exp2sum.pop, and
> queue.append.
I'm very glad you quit while it was still interesting .
People who are paranoid about fp sums should use something like this.
Even pairing is prone to disaster, given sufficiently nasty input.
For example:
>>> xs = [1, 1e100, 1, -1e100] * 1
>>> sum(xs) # and the obvious pairing method gives the same
0.0
>>> sum(sorted(xs)) # the result is nearly incomprehensible
-8.0076811737544552e+087
>>> sum(sorted(xs, reverse=True))
8.0076811737544552e+087
>>> summer2(xs) # exactly right
2.0
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: distutils fix for building Zope against Python 2.4.1c1
[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 sure your HEAD is current? Of course I was sure. I was also wrong about that, but I resent the implication that I wasn't sure . I'll port the fix sometime this weekend. Thanks! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Open issues for 2.4.1
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 able to roll a release. The week after that, I'll have to give exams from Wednesday on, so I would prefer to produce my MSI file on March 29. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Open issues for 2.4.1
[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 >unittests. Should this change be reverted before 2.4.1, No. >or was the Zope test suite doing something particularly dodgy? Yes, it was overriding a documented, public method, but with no awareness that it was overriding anything -- a subclass just happened to define a method with the same name as an advertised unittest base class method. >I'm talking about >- unittest.TestCase.run() and unittest.TestSuite.run() can now be > successfully extended or overridden by subclasses. Formerly, > the subclassed method would be ignored by the rest of the module. > (Bug #1078905). Since there was no _intent_ in the zdaemon tests to override run(), it's just an accident that unittest used to ignore run() overrides. The fix in zdaemon source was s/run/_run/g. It shouldn't have used "run" to begin with. >I've not looked too closely at the broken Zope code - can someone from >ZC comment? Not officially . >How likely is it that other programs will also have been broken by this? Approximately equal to the odds that someone else defined a method named "run()" in a TestCase or TestSuite subclass without realizing they were actually overriding an advertised base class method (but one that didn't actually work as advertised, so there was no visible consequence before). ZC has a relatively huge number of test suites, and it should be noted that only the zdaemon suite was affected by this. Since the zdaemon tests don't run at all on Windows, I never noticed this; if I had, I would have changed the zdaemon test source as a matter of course (i.e., the thought "Python bug" wouldn't have crossed my mind in this case). >At this point, I'm leaning (very slightly) towards the feeling that this > should >probably be backed out before 2.4.1, mostly because it seems to me that >this is an incompatibility, rather than a pure bug fix. It looked like pilot error on zdaemon's side. > 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. OK by me! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Lib/idlelib NEWS.txt, 1.49.2.3, 1.49.2.4 idlever.py, 1.22.2.1, 1.22.2.2
"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 latter, to handle the situation >> where a customized IDLE is decoupled from Python. > > I think there is a 3rd option: > > 3. Decouple Python and IDLE version numbers. I.e. IDLE version numbers > should change only when the IDLE maintainer thinks they should, not > when the Python release manager bumps the Python versions. > > For 2.4.1, the IDLE version number should just be rolled back (or > forward) to "1.1.1". Unless you plan to include IDLE 1.1.2 with Python > 2.4.2, it will stay at 1.1.1 in the 2.4 branch. Well, I had to read this several times to understand it :-) While your third approach makes some sense, I believe it's actually the source of the current confusion. IMHO it would be better to bump the micro number to agree with Python's, and have an empty entry in the IDLE NEWS.txt. We tried your suggestion with 2.3 and it got confusing. Part of the problem is, who bumps idlever.py and the header in NEWS.txt? Anthony and I have been stepping on each other a bit. My suggestion: IDLE maintainer starts the new NEWS.txt header if Python release mgr hasn't, but leaves it "What's New in IDLE" i.e. no release number and lets the release manager handle the release numbers. I still prefer making IDLE's version the same as Python's. > Whether or not updating the IDLE code base to include new features > is another issue - it might be that an exception can be made for IDLE; > OTOH, it might be reasonable to apply the same strict requirements > for idlelib as we do for the rest of the Python library, i.e. no new > features. I've always taken that approach: only bug fixes on the maintainance branches. -- KBK ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] code blocks using 'for' loops and generators
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), the syntax you
propose is quite awful,
I find it quite natural. Stuff on the right of 'yield' is going out,
stuff on the left is coming in. Since 'yield' is different than return in
that it marks a spot at which execution both leaves and re-enters the
frame, it makes sense that 'yield' should have a syntax that indicates as
much.
and the functionality you desire does not
require syntax modification to be possible.
Was the functionality provided by generators or decorators or anything
else impossible before those were introduced? Of course not. The point
is to make things easier and more natural, not to enable some previously
impossible functionality.
Strawman 1: the syntax
def pickled_file(name):
f = open(name, 'r')
l yield pickle.load(f)
^
--
|f.close()
|f = open(name, 'w')
|pickle.dump(l, f)
|f.close()
|
While this is currently a syntax error, it is not clear that an
assignment is happening /at all/, and I don't believe it would be /even
if/ if were documented, and every time someone opened up Python it said
"This is an assignment!" with an example. It looks too magical to me
(and from a guy who had previously proposed 'Some' as the opposite of
'None', that's saying something).
Perhaps you are right, I don't know. It seems to me that most people
would have to see the syntax once to know exactly what is going on, but I
certainly don't know that for sure. Either way, I'd hate to have all my
suggestions dismissed because of the syntax of this one piece.
Strawman 2: putting data back into a generator
def pickled_file(name):
f = open(name, 'r')
yield pickle.load(f)
f.close()
f = open(name, 'w')
pickle.dump(l, f)
f.close()
Keep your code, except toss that leading 'l'.
for l in pickled_file('greetings.pickle'):
l.append('hello')
l.append('howdy')
Toss that 'continue l', and your code will work (as long as both the
function and the for are sitting in the same namespace).
But they're *not* in the same namespace necessarily. That is entirely the
point. One is changing scope but has no clean way to pass values. How is
making 'l' some (more) global variable possibly a clearer way to pass it
to the generator? Your argument is like saying one does not need to
return values from a function because we could always just use a global
variable to do it.
Hrm, not good enough? Use a Queue, or use another variable in a
namespace accessable to both your function and your loop.
Again, I entirely realize it's possible to do these things now, but that
is not the point.
I'm sorry if this email comes off harsh,
I'm just relieved someone responded :)
-Brian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] code blocks using 'for' loops and generators
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
> > (whether my opinion means anything is another matter), the syntax you
> > propose is quite awful,
>
> I find it quite natural. Stuff on the right of 'yield' is going out,
> stuff on the left is coming in. Since 'yield' is different than return in
> that it marks a spot at which execution both leaves and re-enters the
> frame, it makes sense that 'yield' should have a syntax that indicates as
> much.
Inventors always find their ideas to be quite natural; if they weren't,
they wouldn't have come to them.
> > and the functionality you desire does not
> > require syntax modification to be possible.
>
> Was the functionality provided by generators or decorators or anything
> else impossible before those were introduced? Of course not. The point
> is to make things easier and more natural, not to enable some previously
> impossible functionality.
I don't find the syntax you provide to be 'natural'. Trying to convince
me of the 'naturalness' of it is probably not going to be productive,
but as I said in my original email, "whether my opinion means anything
is another matter".
Being that no one else has publically responded to your post, and it has
been nearly 24 hours, my feeling is that either there are more important
things going on (Python 2.4.1, sum/product/any/all discussion, etc.),
people haven't been paying attention in recent days (due to the higher
volume), people are not sufficiently one side or another to comment, or
some other thing.
> > Strawman 1: the syntax
> >
> > def pickled_file(name):
> > f = open(name, 'r')
> > l yield pickle.load(f)
> > ^
> > --
> > |f.close()
> > |f = open(name, 'w')
> > |pickle.dump(l, f)
> > |f.close()
> > |
> > While this is currently a syntax error, it is not clear that an
> > assignment is happening /at all/, and I don't believe it would be /even
> > if/ if were documented, and every time someone opened up Python it said
> > "This is an assignment!" with an example. It looks too magical to me
> > (and from a guy who had previously proposed 'Some' as the opposite of
> > 'None', that's saying something).
>
> Perhaps you are right, I don't know. It seems to me that most people
> would have to see the syntax once to know exactly what is going on, but I
> certainly don't know that for sure. Either way, I'd hate to have all my
> suggestions dismissed because of the syntax of this one piece.
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 say, it would be akin to the
calling code modifying gen.gi_frame._f_locals directly. Such "action at
a distance", from what I understand, is wholly frowned upon in Python.
There also does not exist any other infix operator that does such a
thing (=, +=, ... assign values, but where the data comes from is
obvious).
Bad things to me (so far):
1. Assignment is not obvious.
2. Where data comes from is not obvious.
3. Action at a distance like nothing else in Python.
4. No non-'=' operator assigns to a local namespace.
> > Strawman 2: putting data back into a generator
> >
> > def pickled_file(name):
> > f = open(name, 'r')
> > yield pickle.load(f)
> > f.close()
> > f = open(name, 'w')
> > pickle.dump(l, f)
> > f.close()
> >
> > Keep your code, except toss that leading 'l'.
> >
> > for l in pickled_file('greetings.pickle'):
> > l.append('hello')
> > l.append('howdy')
> >
> > Toss that 'continue l', and your code will work (as long as both the
> > function and the for are sitting in the same namespace).
>
> But they're *not* in the same namespace necessarily. That is entirely the
> point. One is changing scope but has no clean way to pass values. How is
> making 'l' some (more) global variable possibly a clearer way to pass it
> to the generator? Your argument is like saying one does not need to
> return values from a function because we could always just use a global
> variable to do it.
Or you could even use a class instance.
class foo:
def pickled_file(self, name):
f = open(name, 'r')
yield pickle.load(f)
f.close()
f = open(name, 'w')
pickle.dump(self.l, f)
f.close()
fi = foo()
for l in fi.pickled_file('greetings.pickle'):
l.append('hello')
l.append('howdy')
fi.l = l
If you can call the function, there is always a shared namespace. It
may not be obvious (you may need to place the function as a method of an
instance), but it is still there.
> > Hrm, not good enou
[Python-Dev] Re: Adding any() and all()
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 someone remove the condition. It will make more sense to me to support that syntax instead (unless I miss something): [for x in list if x > 0] Regards, Nicolas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] code blocks using 'for' loops and generators
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 function passed to
> __call__ instead of activating the currently implemented 'yield'
> mechanism.
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 creates a weird asymmetry because the last
yield throws away its arguments, and depending on how the generator is
written, different calls to next may require a different number of
arguments. This means that, unless the code is extremely well
documented, you have to read the source code for the generator to know
how to call it.
Because of these and other complications, I believe the PEP is now
lobbying for a way to get the generator instance object and a way to
cause an exception to be thrown from outside the generator. Take a
look and see if the PEP might meet your needs -- I haven't seen much
action on it recently, but it seems much less invasive than your
proposal...
> As an example of the syntax I am suggesting, here is something I was
> desiring recently, a generator to open, unpickle, repickle and close a
> file:
>
> def pickled_file(name):
> f = open(name, 'r')
> l yield pickle.load(f)
> f.close()
> f = open(name, 'w')
> pickle.dump(l, f)
> f.close()
I believe with PEP 288, this would look something like:
def pickled_file(name):
self = mygen.get_instance()
f = open(name, 'r')
yield pickle.load(f)
f.close()
f = open(name, 'w')
pickle.dump(self.l, f)
f.close()
> This function would be used like this:
>
> for l in pickled_file('greetings.pickle'):
> l.append('hello')
> l.append('howdy')
> continue l
>
And this would be written something like:
gen = pickled_file('greetings.pickle')
for l in gen:
l.append('hello')
l.append('howdy')
gen.l = l
Personally, I find this use of a generator thoroughly confusing, and I
don't see what you gain from it. The PEP 288 examples are perhaps
somewhat more convincing though...
Steve
[1] http://www.python.org/peps/pep-0288.html
--
You can wordify anything if you just verb it.
--- Bucky Katt, Get Fuzzy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] sum()
> 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 can be tweaked to consume the error term right
away
> > so the queue won't grow by more than few pending items.
>
> Theorem 10 in Shewchuk's "Adaptive Precision Floating-Point Arithmetic
> and Fast Robust Geometric Predicates" gives the obvious correct
> way to do that, although as a practical matter it greatly benifits
> from a bit more logic to eliminate zero entries as they're produced
> (Shewchuk doesn't because it's not his goal to add a bunch of
> same-precision floats). BTW, extracting binary exponents isn't
> necessary in his approach (largely specializations to "perfect" 754
> arithmetic of Priest's earlier less-demanding methods).
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 friendly than with the
previous queue approach.
from math import frexp
def summer3(iterable):
exp2sum = {}# map to a value with a given exponent
errdict = {}# map error terms to an occurrence count
def addone(x, exppop=exp2sum.pop, errget=errdict.get, frexp=frexp):
mant, exp = frexp(x)# extract exponent from float
representation
while exp in exp2sum:
y = exppop(exp) # pair with a value having the same exp
z = x + y # sum may be inexact by less than 1 ulp
of z
d = x - z + y # difference is the error term
assert z + d == x + y # sum plus error term is
exact!
errdict[d] = errget(d, 0) + 1 # count occurrences of each
term
x = z # continue with new sum
mant, exp = frexp(x)
exp2sum[exp] = x
for x in iterable:
addone(x)
while errdict:
d, q = errdict.popitem()
assert frexp(d)[0] in [-0.5, 0.0, 0.5] # error terms are 1 bit
# product of 1 bit error term with an integer count is exact
addone(d * q)
dummy = errdict.pop(0.0, None)
# At this point, the errdict is empty, all partial sums are exact,
# and each partial sum has a different exponent. They can now be
# added smallest absolute value to largest and only lose bits that
# cannot fit in the final result. IOW, the final result is accurate
# to full precision (assuming no representation error in the
inputs).
return sum(sorted(exp2sum.itervalues(), key=abs), 0.0)
Aside from being a nice recipe, this was a good exercise in seeing what
pure Python can do with IEEE-754 guarantees. The modest memory
consumption and the typical O(n) runtime are a nice plus (no pun
intended).
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] code blocks using 'for' loops and generators
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 creates a weird asymmetry because the last
yield throws away its arguments, and depending on how the generator is
written, different calls to next may require a different number of
arguments. This means that, unless the code is extremely well
documented, you have to read the source code for the generator to know
how to call it.
The intention of my proposal was for using generators with 'for' loops.
In this case, the generator runs to completion, so the arguments to the
last yield are never thrown away. If 'next' were not able to take any
arguments, that would be compatible with my proposal.
Also, there was the issue that there is an asymmetry because the first
call to 'next' does not take any arguments. This asymmetry does not
exist, however, when using the generator in a 'for' loop, because there is
no "first" call to 'continue' in such a case.
Because of these and other complications, I believe the PEP is now
lobbying for a way to get the generator instance object and a way to
cause an exception to be thrown from outside the generator. Take a
look and see if the PEP might meet your needs -- I haven't seen much
action on it recently, but it seems much less invasive than your
proposal...
This PEP solves similar problems, yes. And I would agree that my proposal
is much more invasive on python's implementation. From the users' point
of view, however, I think it is much less invasive. For example, no doubt
there will be many users who write a generator that is to be used in a
'for' loop and are baffled that they receive a syntax error when they try
to write some try/finally cleanup code. With the PEP, they would have to
figure out that they have to use the 'throw' method of generators to
trigger cleanup code (and then have to remember to call it each time they
are done with the generator). With this proposal, try/finally would just
work as they expect and they would be non the wiser.
def pickled_file(name):
self = mygen.get_instance()
f = open(name, 'r')
yield pickle.load(f)
f.close()
f = open(name, 'w')
pickle.dump(self.l, f)
f.close()
And this would be written something like:
gen = pickled_file('greetings.pickle')
for l in gen:
l.append('hello')
l.append('howdy')
gen.l = l
Personally, I find this use of a generator thoroughly confusing, and I
don't see what you gain from it. The PEP 288 examples are perhaps
somewhat more convincing though...
The disadvantage of doing it this way (or with a class wrapping the
generator) is that it is implicit. If I were reading the pickled_file
code, I would have no idea where the self.l comes from. If it is coming
from the 'for' loop, why not just be able to explicitly say that?
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.
-Brian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] code blocks using 'for' loops and generators
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 say, it would be akin to the
calling code modifying gen.gi_frame._f_locals directly. Such "action at
a distance", from what I understand, is wholly frowned upon in Python.
There also does not exist any other infix operator that does such a
thing (=, +=, ... assign values, but where the data comes from is
obvious).
Bad things to me (so far):
1. Assignment is not obvious.
2. Where data comes from is not obvious.
3. Action at a distance like nothing else in Python.
4. No non-'=' operator assigns to a local namespace.
If it is too much action at a distance, one could also use the syntax "a =
yield b", as has been suggested before, but I preferred it without the
'='. With the '=', I don't see how it is any more action at a distance
than "a = yield_func(b)" or "for i in f()". In all of these cases, values
are being passed when the scope is changing.
If you want to argue that both of these syntaxes are too ugly to be
allowed, then ok.
Or you could even use a class instance.
class foo:
def pickled_file(self, name):
f = open(name, 'r')
yield pickle.load(f)
f.close()
f = open(name, 'w')
pickle.dump(self.l, f)
f.close()
fi = foo()
for l in fi.pickled_file('greetings.pickle'):
l.append('hello')
l.append('howdy')
fi.l = l
If you can call the function, there is always a shared namespace. It
may not be obvious (you may need to place the function as a method of an
instance), but it is still there.
The disadvantage of this method is that it is not clear where the self.l
values is coming from just by reading the generator method definition. If
it is coming from the code block, why not be able to explicity write it
that way? Similarly, "continue l" explicitly shows that you are passing a
value back to the generator.
Hrm, not good enough? Use a Queue, or use another variable in a
namespace accessable to both your function and your loop.
Again, I entirely realize it's possible to do these things now, but that
is not the point.
The point of your proposed syntax is to inject data back into a
generator from an external namespace. Right?
The point is to inject data back into a generator in a clean, explicit
way; I understand there are other ways in which one can already do this.
Furthermore, I would say that using yield semantics in the way that you
are proposing, while being discussed in other locations (the IBM article
on cooperative multithreading via generators springs to mind), is a
clever hack, but not something that should be supported via syntax.
My impression is that being able to use yield in this way is one of the
primary reasons for the success of ruby. Therefore, I do not see it as
just a clever hack. It is a clean, explicity way to pass values when
changing scope.
-Brian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sum()
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.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RELEASED Python 2.4.1, release candidate 1
"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 strange experiences. Windows2000: I downloaded the 2.4.1c1 installer to the desktop and clicked on it. It complained that it couldn't access the installer. I then clicked on the 2.4.1b2 installer and that started ok. Cancelled it. Repeated this sequence a second time. Same. The third time I clicked on 2.4.1c1 it started up and installed Python ok. For ducks I installed Python at D:\"Python 2.4". It installed in the correct location, also found C:\Python24 and uninstalled that. Python and IDLE appear to run ok. Shortcuts on Run work, and file association was updated, so right clicking a .py used IDLE from Python 2.4.1c1, in no-subprocess mode. -- KBK ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] code blocks using 'for' loops and generators
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 more convincing... I don't find your approach[*], e.g.
def pickled_file(name):
f = open(name, 'r')
data yield pickle.load(f)
f.close()
f = open(name, 'w')
pickle.dump(data, f)
f.close()
for data in pickled_file('greetings.pickle'):
data.append('hello')
data.append('howdy')
continue data
any clearer than, say:
class PickledFile(object):
def __init__(self, name):
self.name = name
f = open(self.name, 'r')
self.data = pickle.load(f)
f.close()
def close(self):
f = open(self.name, 'w')
pickle.dump(self.data, f)
f.close()
p = PickledFile('greetings.pickle')
p.data.extend(['hello', 'howdy'])
p.close()
Note that I'm not using the iteration construct (for-in) because I'm
not really doing an iteration here. Pehaps I could be taught to read
for-in otherwise, but without an obvious benefit for doing so, I'm
really not inclined to.
Steve
[*] I've renamed your "l" to "data". The first time I read your post,
it looked even more confusing to me because "l" (lower case L) is
rendered too similarly to "|" (or-bar) in my browser.
--
You can wordify anything if you just verb it.
--- Bucky Katt, Get Fuzzy
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] code blocks using 'for' loops and generators
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, referenced, or
> > otherwise, by the right. In fact, I would say, it would be akin to the
> > calling code modifying gen.gi_frame._f_locals directly. Such "action at
> > a distance", from what I understand, is wholly frowned upon in Python.
> > There also does not exist any other infix operator that does such a
> > thing (=, +=, ... assign values, but where the data comes from is
> > obvious).
> >
> > Bad things to me (so far):
> > 1. Assignment is not obvious.
> > 2. Where data comes from is not obvious.
> > 3. Action at a distance like nothing else in Python.
> > 4. No non-'=' operator assigns to a local namespace.
>
> If it is too much action at a distance, one could also use the syntax "a =
> yield b", as has been suggested before, but I preferred it without the
> '='. With the '=', I don't see how it is any more action at a distance
> than "a = yield_func(b)" or "for i in f()". In all of these cases, values
> are being passed when the scope is changing.
Right, but as I said before, when using any other assignment operator,
where the value comes from is obvious: the call or statement offered to
the right of the operator. In your example, the data comes from the
caller, and even if you were to offer documentation, it is not obvious
who or what the caller is, or whether or not they would actually provide
such a value (what would happen if they didn't?).
Essentially what you are wanting to do is to take what would normally be
multiple function calls and place them in a generator to package up setup,
body, finalization.
l = load_pickle(filename) #setup
l.append(...) #body
write_pickle(filename, l) #finalization
The above is /the/ canonical way to do this in basically every
programming language. Sticking it in a generator for a sense of being
'clean' is preposterous.
> If you want to argue that both of these syntaxes are too ugly to be
> allowed, then ok.
I stand by my original "ick".
> > Or you could even use a class instance.
> >
> > class foo:
> >def pickled_file(self, name):
> >f = open(name, 'r')
> >yield pickle.load(f)
> >f.close()
> >f = open(name, 'w')
> >pickle.dump(self.l, f)
> >f.close()
> >
> > fi = foo()
> > for l in fi.pickled_file('greetings.pickle'):
> > l.append('hello')
> > l.append('howdy')
> > fi.l = l
> >
> > If you can call the function, there is always a shared namespace. It
> > may not be obvious (you may need to place the function as a method of an
> > instance), but it is still there.
>
> The disadvantage of this method is that it is not clear where the self.l
> values is coming from just by reading the generator method definition. If
> it is coming from the code block, why not be able to explicity write it
> that way? Similarly, "continue l" explicitly shows that you are passing a
> value back to the generator.
External to pickled_file, it is explicit where your 'l' or 'self.l' thing
is coming from. You hit the nail on the head, the problem with /both/
your syntax and the equivalent that I offer above is that inside
pickled_file, it is not obvious where self.l (or equivalently the 'l' in
"l yield...") is coming from. Why? Because pulling the body out of a
setup/body/finalization series messes that up.
You would be better off either calling 3 functions like I provided above
(saving people the confusion of "what the hell is this for loop doing
here?"), or putting everything in one function/method, with a callback
like...
def pickled_file(filename, callback):
#setup...
callback(args) #body
#finalization
> > The point of your proposed syntax is to inject data back into a
> > generator from an external namespace. Right?
>
> The point is to inject data back into a generator in a clean, explicit
> way; I understand there are other ways in which one can already do this.
But it is neither explicit nor clean. Explicit from the outside,
perhaps, but not inside your generator. And it certainly is not clean
because it pisses all over the history of "don't to anything too magical"
that Python seems to have strived for.
What if I were to tell you that "a and b" would start assigning a value
to "a" that wasn't "b" or "a", wasn't anything even related to "a" or "b",
and would be produced by code that isn't even referenced by "a", "b", or
anything else in the local namespace? You'd probably tell me that I'd
had a few too many drinks, and you'd probably be right. You are
essentially asking for "yield" to behave like this, and I think you've
had a few too many drinks *wink*.
Steven has pointed out PEP 288, and in my opinion, PEP 288 is the right
thing to do in regards to p
Re: [Python-Dev] sum()
[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 friendly than with the > previous queue approach. Cool! That's a nice approach. For contrast, here's one that doesn't use frexp(), and is probably faster because of that; internally, len(sums) probably won't exceed 5 in real life (but could get as large as 2K for pathological inputs, spanning fp's full dynamic range): def summer4(iterable): sums = [0.0] for x in iterable: sums.append(x) for i in xrange(len(sums)-2, -1, -1): y = sums[i] if abs(x) < abs(y): x, y = y, x hi = x+y lo = y - (hi - x) if lo: sums[i+1] = lo else: del sums[i+1] x = hi sums[0] = x return sum(reversed(sums), 0.0) In effect, that keeps an arbitrarily long list of "error terms" so that no info is lost before the final sum(). I think it's surprising at first how short that list usually is. > ... > Aside from being a nice recipe, this was a good exercise in seeing what > pure Python can do with IEEE-754 guarantees. Now you know I how feel everytime sometime proclaims that fp arithmetic is inherently unreliable <0.3 wink>. Learning how to use it correctly is indeed the blackest of obscure arts, though. > The modest memory consumption and the typical O(n) runtime are a nice > plus (no pun intended). Yup, they're all emminently practical if you don't care too much about speed. The one above is the fastest I tried, and it still takes some 40x longer than plain sum() over a million-element random.random() list. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] code blocks using 'for' loops and generators
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
would be worth it.
I guess I need some more convincing... I don't find your approach[*], e.g.
def pickled_file(name):
f = open(name, 'r')
data yield pickle.load(f)
f.close()
f = open(name, 'w')
pickle.dump(data, f)
f.close()
for data in pickled_file('greetings.pickle'):
data.append('hello')
data.append('howdy')
continue data
any clearer than, say:
class PickledFile(object):
def __init__(self, name):
self.name = name
f = open(self.name, 'r')
self.data = pickle.load(f)
f.close()
def close(self):
f = open(self.name, 'w')
pickle.dump(self.data, f)
f.close()
p = PickledFile('greetings.pickle')
p.data.extend(['hello', 'howdy'])
p.close()
Note that I'm not using the iteration construct (for-in) because I'm
not really doing an iteration here. Pehaps I could be taught to read
for-in otherwise, but without an obvious benefit for doing so, I'm
really not inclined to.
In the real world, I need to lock and unlock the pickled files. So if I
forget to call p.close(), then it would be a problem. I would need a
try/finally block. If I could use the above 'for' loop approach, I am
able to encapsulate the try/finally code.
This is the same problem that is addressed in PEP 310. Copied from the
PEP, here is the basic idea:
The syntax of a 'with' statement is as follows::
'with' [ var '=' ] expr ':'
suite
This statement is defined as being equivalent to the following
sequence of statements:
var = expr
if hasattr(var, "__enter__"):
var.__enter__()
try:
suite
finally:
var.__exit__()
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__, __enter__, etc.
-Brian
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] code blocks using 'for' loops and generators
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 wonder where data is coming from), and the necessity of a new syntax to make such things "easier" (if (ab)using generators in such a way makes /anything/ "easier"). I will also agree to disagree. If I may also summarize, you see such syntax as magical, non-obvious and unnecessary, and I find it clean and useful. -Brian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] code blocks using 'for' loops and generators
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 poor > > style, and too much brain overhead to wonder where data is coming from), > > and the necessity of a new syntax to make such things "easier" (if > > (ab)using generators in such a way makes /anything/ "easier"). > > I will also agree to disagree. If I may also summarize, you see such > syntax as magical, non-obvious and unnecessary, and I find it clean and > useful. Small correction: I find the syntax magical, the data flow to be non-obvious, and the functionality unnecessary (for the reasons previously specified). - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding any() and all()
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 fashion. Is there really any need for another module just for this? The distinction between reductive and non-reductive operations on iterators seems rather too fine to me to deserve a whole new module. Why not just put them all in itertools? [1] While any()/all() read well in the context of an if statement, I think anytrue()/alltrue() better convey the reductive nature of the operations, read nearly as well in the if context, and read significantly better when isolated from the if context (e.g. assigned to a variable). I don't agree. I think 'any' and 'all' are fine names for boolean-valued functions in any context. Including 'true' in their names smacks of the same kind of redundancy as if blarg == True: ... which is widely regarded as a naive-newbie style blunder in any language. +1 on 'any' and 'all' -1 on any names including 'true' or 'false' Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] code blocks using 'for' loops and generators
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__, __enter__, etc. But this is an abuse of both the for-loop and the generator. It's using a for-loop for something that does not loop and is never intended to loop, and it's using yield to do something other than producing a value for consumption. I'd rather see a new mechanism altogether for this very different use case. -Brian -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] comprehension abbreviation (was: Adding any() and all())
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 ()). . . How about: (for x in seq if f(x)) It still has the word 'for' in it and avoids mentioning x more times than necessary. Although I can't help feeling that it should be some other word instead, such as (all x in seq if f(x)) or (every x in seq if f(x)) -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Open issues for 2.4.1
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 saying that this is a bug fix, but I'd appreciate any comments (pro or con). If no-one comments, I'll go with whatever my gut feeling says is the right answer. (I've been lurking for a while but this is my first post. I maintain paramiko and enjoy harrassing people on sourceforge to fix the new-style Exception bug that vexes me. Nice to meet you all.) :) I agree 100% with the arguments made over the past couple of weeks about strictly refusing to add new features to micro releases (like 2.4.1). But I don't think fixing the os.access bug is anything but a bug fix, and here's my rationale: It's entirely possible that some python users have worked around this bug by special-casing their use of os.access to manually encode the filename, but that doesn't mean that bringing os.access behavior in line with the other filename methods should be considered a "feature add". Pretend there was a bug with "int" such that you could add any number to it except 1. You can work around this bug by replacing "+1" with "+2-1" but it doesn't make it any less of a bug or any less important to fix. 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. robey ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Open issues for 2.4.1
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). Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
