Re: [Python-Dev] Open issues for 2.4.1
On Sunday 13 March 2005 18:35, Robey Pointer wrote: > [on the os.access unicode fix] Ok, I'm convinced - Martin, can you check this in? -- 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] RELEASED Python 2.4.1, release candidate 1
Kurt B. Kaiser wrote: I had some strange experiences. Weird indeed. I downloaded the 2.4.1c1 installer to the desktop and clicked on it. It complained that it couldn't access the installer. Do you happen to remember the precise error message? I then clicked on the 2.4.1b2 installer and that started ok. Cancelled it. This must have been 2.4b2, right? However, didn't you have 2.4 installed already? For ducks I installed Python at D:\"Python 2.4". It installed in the correct location, also found C:\Python24 and uninstalled that. That is supposed to happen; I never tested it, though. 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. Good! 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] RELEASED Python 2.4.1, release candidate 1
Martin, This is somewhat of a corner case, but maybe worth investigating: To check what I mentioned on comp.lang.python earlier, I ran the installer again (with 2.4.1 still intact), selected the "Change Python 2.4.1c1" radio button, clicked the "Finish" Button, clicked the "Advanced" button, clicked the "Cancel" button, and clicked "Yes" to the question "Are you sure you want to cancel the Python 2.4.1c1 installation". This crashed msiexec.exe. I was able to reproduce this on Windows XP Professional, Service Pack 2. Regards, -- Vincent Wehren ___ 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
-Original Message- From: "Martin v. Lowis" [mailto:[EMAIL PROTECTED] Sent: Saturday, March 12, 2005 3:12 PM To: Leeuw van der, Tim Cc: python-dev@python.org Subject: 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. > I agree that this needs to be investigated, b/c valid code shouldn't result in a syntax error. But just to make sure there's no misunderstandings: Python2.4.1rc1 fixed the crashes. And the generated file is 1.5Mb big; I think I should not post it as - is but rather compress it? What's the best advice on attaching such large files? > 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: I agree that this needs to be investigated, b/c valid code shouldn't result in a syntax error. But just to make sure there's no misunderstandings: Python2.4.1rc1 fixed the crashes. And the generated file is 1.5Mb big; I think I should not post it as - is but rather compress it? What's the best advice on attaching such large files? If you can store it somewhere on the net, that would be best, putting a link to the file into the SF bug report. SF has a limit on file attachments which is much smaller. 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
new-style sxceptions (was Re: [Python-Dev] Open issues for 2.4.1)
Robey Pointer <[EMAIL PROTECTED]> writes: > (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.) :) Well, hey, you can review my patch if you like: http://python.org/sf/1104669 Writing documentation would be even better :) Cheers, mwh -- Also, whenever a programmer thinks, "Hey, skins, what a cool idea", their computer's speakers should create some sort of cock-shaped soundwave and plunge it repeatedly through their skulls. -- http://www.livejournal.com/talkread.bml?journal=jwz&itemid=123070 ___ 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]
> > 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 ()). . .
[Greg Ewing]
> 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))
I doubt that we'll find a satisfactory solution for this issue. Here's why:
- We're only talking of a savings of 4 characters (plus two spaces) in
the best case, assuming the identifier can be a single letter (it's
scope is only the current expression anyway).
- Ping's proposal ('x in seq if f(x)') IMO loses for several reasons:
it would be a hugely ambiguous use of 'in', and would cut off a
possible future syntax for conditional expression(*): 'A if T else B'.
- The various improvements on Ping's proposal reduce the amount of
typing saved even more ('every' is actually longer than 'for x').
- Before anybody asks, I really do think the reason this is requested
at all is really just to save typing; there isn't the "avoid double
evaluation" argument that helped acceptance for assignment operators
(+= etc.), and I find redability is actually improved with 'for'.
(*) Pleas stop calling it 'ternary expression'. That doesn't explain
what it means. It's as if we were to refer to the + operator as
'binary expression'.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Rationale for sum()'s design?
There are a few design choices we could have made for sum(); in particular, for non-empty sequences we could not have used the identity element (the optional second argument). As it is, we get unjustified but understandable complaints that sum() "only supports numbers". An alternative design could have returned: - the identity (defaulting to 0) if the sequence is empty - the first and only element if the sequence only has one element - (...(((A + B) + C) + D) + ...) if the sequence has more than one element This has surprises too (in particular of returning 0 when invoked without overriding the identity argument for a seqence of addable non-numbers) but works without using the second argument for a larger set of inputs I believe it is often used in such a way that the input is known to be non-empty). I'd be happy to be pointed to a past discussion where this was considered and rejected with a good reason; then I can post that to the blog (where the deficiency in sum() is being berated a bit excessively). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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 Sun, 13 Mar 2005, Greg Ewing wrote: 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. The problem with creating a new mechanism is that sometimes you will want to loop. For example, reading a bunch of items from a shared resource, modifying them, and sending them back. A new, non-looping mechanism will not be adequate for this because it cannot loop, and a 'for' loop will not be adequate for the same reason it is not adequate now: it can't automatically unlock the resource at the end of the loop. I was looking for a single mechanism to handle all of these cases, but I can see why you and most people would not be so keen on the idea of abusing (I prefer "expanding the uses of") 'for' loops this way. -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] Open issues for 2.4.1
Anthony Baxter wrote: Ok, I'm convinced - Martin, can you check this in? Done! 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] Adding any() and all()
I think the discussion should separate numeric calculation and truth value calculation. Numeric calculation need to run through all elements, with the order possibly important. Truth value calculation (as per any() and all()) may terminate before all elements have been seen. Finally, any(), all(), and perhaps some should apply to sets as well. --eric ___ 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: The problem with creating a new mechanism is that sometimes you will want to loop. For example, reading a bunch of items from a shared resource, modifying them, and sending them back. A new, non-looping mechanism will not be adequate for this because it cannot loop, If there is a mechanism for passing a code block as a thunk to an arbitrary function, the function is free to loop or not as it sees fit. I'd just prefer the spelling of it didn't force you to make it look like it's looping when it's not. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ 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 Mon, 14 Mar 2005, Greg Ewing wrote:
Brian Sabbey wrote:
The problem with creating a new mechanism is that sometimes you will want
to loop. For example, reading a bunch of items from a shared resource,
modifying them, and sending them back. A new, non-looping mechanism will
not be adequate for this because it cannot loop,
If there is a mechanism for passing a code block as
a thunk to an arbitrary function, the function is
free to loop or not as it sees fit. I'd just prefer
the spelling of it didn't force you to make it
look like it's looping when it's not.
I think you're right. How about something like below? In the same way
that "self" is passed "behind the scenes" as the first argument, so can
the thunk be. (Many ideas taken from around [1])
def stopwatch(thunk):
t = time.time()
thunk()
return t - time.time()
with stopwatch() result dt:
a()
b()
print 'it took', dt, 'seconds to compute'
=
def pickled_file(thunk, name):
f = open(name)
new_data = thunk(pickle.load(f))
f.close()
f = open(name, 'w')
pickle.dump(new_data, f)
f.close()
with greetings from pickled_file('greetings.pickle'):
greetings.append('hello')
greetings.append('howdy')
value greetings
[1] http://mail.python.org/pipermail/python-dev/2003-February/032732.html
-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] comprehension abbreviation (was: Adding any() and all())
Guido van Rossum: > - Before anybody asks, I really do think the reason this is requested > at all is really just to save typing; there isn't the "avoid double > evaluation" argument that helped acceptance for assignment operators > (+= etc.), and I find redability is actually improved with 'for'. For me, the main motivation is to drop an unnecessarily repeated identifier. If you repeat something there is a chance that one of the occurrances will be wrong which is one reason behind the Don't Repeat Yourself principle. The reader can more readily see that this is a filter expression rather than a transforming expression. Neil ___ 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] Rationale for sum()'s design?
Guido van Rossum wrote: - the identity (defaulting to 0) if the sequence is empty - the first and only element if the sequence only has one element - (...(((A + B) + C) + D) + ...) if the sequence has more than one element While this might be reasonable if the identity argument is not specified, I think that if an identity is specified, it should be used even if the sequence is non-empty. The reason being that the user might be relying on that to get the semantics he wants. Think of the second argument as "accumulator object" rather than "identity". -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ 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: How about something like below? In the same way that "self" is passed "behind the scenes" as the first argument, so can the thunk be. with stopwatch() result dt: a() b() print 'it took', dt, 'seconds to compute' Something like that would be better, yes. Maybe even just dt = stopwatch(): a() b() Whatever keyword is used is bound to not sound right for some usages, so it would be best if no keyword were needed at all. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ 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() andall())
[GvR]
> > - Before anybody asks, I really do think the reason this is
requested
> > at all is really just to save typing; there isn't the "avoid double
> > evaluation" argument that helped acceptance for assignment operators
> > (+= etc.), and I find redability is actually improved with 'for'.
{Neil Hodgson]
>For me, the main motivation is to drop an unnecessarily repeated
> identifier. If you repeat something there is a chance that one of the
> occurrances will be wrong which is one reason behind the Don't Repeat
> Yourself principle.
It's not actually a repetition. Instead, it is a precise expression of
what is to be returned. The proposal adopts a custom syntax to handle
one possible return value (identity) as a default. You're trading away
explictness, giving up on having a uniform syntax, and introducing more
than one way to do it (the current approach would still be valid).
The repeated expression argument carried more weight in the context of
augmented assignment where complex lvalues are common: self.arr[i] +=
j. For genexps and listcomps, simple loop variables are the norm.
Try applying the proposal to existing code. I think you'll see that
you've gained nothing.
> The reader can more readily see that this is a
> filter expression rather than a transforming expression.
Personally, I find the proposed syntax to be difficult to parse. It's a
step backwards.
-1
Sorry, I deem the proposal to be horrendous and hope it gets trounced
before it gets out of hand.
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] Rationale for sum()'s design?
[Guido van Rossum] > > > > - the identity (defaulting to 0) if the sequence is empty > > - the first and only element if the sequence only has one element > > - (...(((A + B) + C) + D) + ...) if the sequence has more than one element [Greg Ewing] > While this might be reasonable if the identity > argument is not specified, I think that if an > identity is specified, it should be used even > if the sequence is non-empty. The reason being > that the user might be relying on that to get > the semantics he wants. > > Think of the second argument as "accumulator > object" rather than "identity". But I think the logical consequence of your approach would be that sum([]) should raise an exception rather than return 0, which would be backwards incompatible. Because if the identity element has a default value, the default value should be used exactly as if it were specified explicitly. Unfortunately my proposal is also backwards incompatible, since currently sum([1,1], 40) equals 42. I guess nobody remembers why we did it the way it is? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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 downloaded the 2.4.1c1 installer to the desktop and clicked on it. >> It complained that it couldn't access the installer. > > Do you happen to remember the precise error message? "This installation package could not be opened." > >> I then clicked on the 2.4.1b2 installer and that started ok. Cancelled it. > > This must have been 2.4b2, right? However, didn't you have 2.4 installed > already? Right, 2.4b2. I never updated to 2.4 on that box. OK, the problem was: I rushed the install. The package had not finished downloading, but the icon appears on the desktop as soon as the download starts. (With Opera you have to pay attention to the download status, it's rather subtle.) If I wait for the download to complete and the virus check to finish, then it's AOK. That's why the third time was the charm. -- 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] Rationale for sum()'s design?
That is like Lisp's +, must be good :P Michael On Sun, 13 Mar 2005 08:38:42 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote: > There are a few design choices we could have made for sum(); in > particular, for non-empty sequences we could not have used the > identity element (the optional second argument). As it is, we get > unjustified but understandable complaints that sum() "only supports > numbers". An alternative design could have returned: > > - the identity (defaulting to 0) if the sequence is empty > - the first and only element if the sequence only has one element > - (...(((A + B) + C) + D) + ...) if the sequence has more than one element > > This has surprises too (in particular of returning 0 when invoked > without overriding the identity argument for a seqence of addable > non-numbers) but works without using the second argument for a larger > set of inputs I believe it is often used in such a way that the input > is known to be non-empty). > > I'd be happy to be pointed to a past discussion where this was > considered and rejected with a good reason; then I can post that to > the blog (where the deficiency in sum() is being berated a bit > excessively). > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > ___ > 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/michael.walter%40gmail.com > ___ 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] Rationale for sum()'s design?
On Mar 14, 2005, at 01:22, Greg Ewing wrote: Guido van Rossum wrote: - the identity (defaulting to 0) if the sequence is empty - the first and only element if the sequence only has one element - (...(((A + B) + C) + D) + ...) if the sequence has more than one element While this might be reasonable if the identity argument is not specified, I think that if an identity is specified, it should be used even if the sequence is non-empty. The reason being that the user might be relying on that to get the semantics he wants. Think of the second argument as "accumulator object" rather than "identity". +1 to Greg's idea -- I do have cases where the items arrive in irregular bunches and I maintain the running total via this mechanism, initializing as running_total = 0 and updating it as running_total = sum(bunch_of_items, running_total) Back to Guido's request for the history of how the design evolved, I did some googling -- it all happened on this mailing list, April 19 to April 21, 2003. Most of it subject: Fwd: summing a bunch of numbers (or "whatevers"), though some had Re: and other lacked Fwd: decorations, in case you're searching on the month's archives by subject. Reading the whole thread will help with the pro's and con's, but the conclusions are mostly in Guido's post http://mail.python.org/pipermail/python-dev/2003-April/034853.html and my concurring reply http://mail.python.org/pipermail/python-dev/2003-April/034855.html . 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
