Re: [Python-Dev] "and" and "or" operators in Py3.0
Guido van Rossum <[EMAIL PROTECTED]> writes: > On 9/19/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: >> I propose that in Py3.0, the "and" and "or" operators be simplified to >> always return a Boolean value instead of returning the last evaluated >> argument. > > While you're at it, maybe we should switch to && and || as well? > That's another thing I always mistype when switching between > languages... You're joking, surely? > Also, this proposal needs to be considered together with the addition > of a proper conditional operator, like x?y:z. I think this discussion has been had before, you know. Cheers, mwh -- > Look I don't know. Thankyou everyone for arguing me round in > circles. No need for thanks, ma'am; that's what we're here for. -- LNR & Michael M Mason, cam.misc ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "and" and "or" operators in Py3.0
"Raymond Hettinger" <[EMAIL PROTECTED]> writes: > I propose that in Py3.0, the "and" and "or" operators be simplified to > always return a Boolean value instead of returning the last evaluated > argument. -1 > 2) When going back and forth between languages, it is easy to forget > that only Python returns something other than a boolean. As others point out, this isn't true. > 3) Even when it isn't being used, the possibility of non-boolean return > value complicates the bytecode and parser. To allow for "and/or", the > conditional opcodes leave the tested value on the stack. Huh? I thought this was for chained expressions? Things like 1 < x < 3. I _like_ the explanation of 'and' and 'or' as they are now. They are basically control flow constructs -- and have to be to get short-circuiting to work -- and adding a coercion to bool at the end seems to add complexity, not reduce it (on some levels, anyway). > P.S. Simplifying "and" and "or" may create a need to introduce a > conditional operator but that is a discussion for another day. ... which was in the past, I thought. Cheers, mwh -- The meaning of "brunch" is as yet undefined. -- Simon Booth, ucam.chat ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] For/while/if statements/comprehension/generator expressions unification
Alexander Myodov wrote: > To increase my understanding of Python-way, can you (or someone else) > explain the reasons why such proposals were rejected? I wasn't around for the discussion Josiah refers to, but I would guess it is because they don't improve the power or readability of the language, and may in fact be significantly less readable than simply nesting the corresponding statements. In particular, with the current syntax, the local variables bound by the for statement are clearly visible immediately after the 'for' keyword. If multiple instances of the keyword were allowed in a single for statement, the names being bound could be hidden after an arbitrarily complex expression. This 'hidden local' problem is one of the concerns with the current behaviour where list comprehensions make their loop variables visible in the surrounding scope (this behaviour will be fixed in Py3k, and was deliberately avoided for generator expressions). > 1. Bring 'if'-s from generator/comprehension 'for' syntax to 'for' > statement. That's truly inconsistent that one may write > > list2 = [i for i in list if cond(i)] > > but cannot write > > for i in list if cond(i): No, instead you write: for i in list: if cond(i): The order of execution of loops and conditionals is entirely unambiguous, as it is shown explicitly by the nesting. Python has never been shy about requiring vertical and horizontal whitespace at the statement level in order to make the sequence of control flow more explicit. The rules are different for list comprehensions and generator expressions, because whitespace is only used to delimit tokens inside expressions, rather than being a token in its own right as it can be at the statement level. However, the order of execution of these expressions can be disambiguated by conversion to the nested statement version of the same code. > 2. Bring "several for-s in a row" ability from > generators/comprehensions to the statement (and expand it to "several > for-s and if-s", of course). We can write > > list2 = [f(i, j) for i in list1 for j in list2] > > but cannot write > > for i in list1 for j in list2: > yield f(i, j) > That looks inconsistent as well. If the apparent inconsistency genuinely bothers you, you can always write the statement version as: for x in (f(i, j) for i list1 for j in list2): yield x Note that this preserves the fact that only 'x' is bound in the surrounding scope, and this name is prominent in the 'for' statement. > Yes, for this little case we could do some kind of cross, but what if > there are more loops, and/or some of them require filtering by if-s? Then readers of the code could probably be helped out if some of the intermediate steps were named to explain what's going on. Alternately, just use a genexp as I show above. > 3. Bring 'while' into the loops, both statements and iterators. Now no > need to worry about "hidden-goto" 'break', especially for the cases of > nested loops, while it can be easily checked right inside the looping > condition? 'break' is no more a 'hidden-goto' than any other form of non-sequential control flow (like say, conditionals or loops) is a goto. The problem with having an actual goto is that it can go *anywhere*, leading to a high chance of writing spaghetti code - this is not the case when using break, as you can't go anywhere other than the statement immediately following the loop. Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "and" and "or" operators in Py3.0
Raymond Hettinger wrote: > I propose that in Py3.0, the "and" and "or" operators be simplified to > always return a Boolean value instead of returning the last evaluated > argument. No, please not. It's useful sometimes and doesn't hurt most times. > 1) The construct can be error-prone. When an error occurs it can be > invisible to the person who wrote it. I got bitten in published code > that had survived testing and code review: > > def real(self): > 'Return a vector with the real part of each input element' > # do not convert integer inputs to floats > return self.map(lambda z: type(z)==types.ComplexType and z.real or > z) I'm surprised you wrote that in the first place. The "and/or conditional" is one of the few occurences where one will carefully look for false values in the "and" part. > The code fails silently when z is (0+4i). It took a good while to trace > down a user reported error (when Matlab results disagreed with my matrix > module results) and determine that the real() method contained an error. > Even when traced down, I found it hard to see the error in the code. > Now that I know what to look for, it has not happened again, but I do > always have to stare hard at any "and/or" group to mentally verify each > case. [...] > P.S. Simplifying "and" and "or" may create a need to introduce a > conditional operator but that is a discussion for another day. Exactly. A conditional was turned down some time ago, for good reasons. Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "and" and "or" operators in Py3.0
Michael Hudson wrote: > I _like_ the explanation of 'and' and 'or' as they are now. They are > basically control flow constructs -- and have to be to get > short-circuiting to work -- and adding a coercion to bool at the end > seems to add complexity, not reduce it (on some levels, anyway). Agreed. However, Raymond and Brett seem to have some ideas about optimising the normal comparison bytecode without changing the semantics, which would be good. >>P.S. Simplifying "and" and "or" may create a need to introduce a >>conditional operator but that is a discussion for another day. > > > ... which was in the past, I thought. C'mon, PEP 308 was fun for everybody };) The ease of writing buggy code when trying to fake a conditional operator using and/or does seem to cause the question to keep coming up despite the fate of PEP 308, though. But the only way I can ever see a conditional operator happening is if Guido simply selects which of the top 4** PEP 308 solutions he likes best and says "make it so!". Cheers, Nick. ** I say top 4, because there was daylight between the votes for the first 4 choices and all of the other PEP 308 options. And many of the pros and cons of those 4 choices are so subjective that I wouldn't expect further discussion to significantly change anyone's opinion. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "and" and "or" operators in Py3.0
> > 2) When going back and forth between languages, it is easy to forget > > that only Python returns something other than a boolean. > > As others point out, this isn't true. In C, C++, C#, Java, and JavaScript, what do you get when you print the result of 3 || 10? Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "and" and "or" operators in Py3.0
Michael Hudson wrote: >> While you're at it, maybe we should switch to && and || as well? >> That's another thing I always mistype when switching between >> languages... > > You're joking, surely? for Python 3000, I'd recommend switching to "and then" and "or else" instead of the current ambiguous single-keyword versions. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "and" and "or" operators in Py3.0
On Tuesday 2005-09-20 11:40, Raymond Hettinger wrote: > > > 2) When going back and forth between languages, it is easy to forget > > > that only Python returns something other than a boolean. > > > > As others point out, this isn't true. > > In C, C++, C#, Java, and JavaScript, what do you get when you print the > result of 3 || 10? JavaScript does the same as Python, according to section 11.11 of the EMCA standard as of December 1999, which is what I have to hand. The others you mention don't, because doing so would fit very uncomfortably with their static type systems. Those are not the only languages that exist other than Python. Perl and Ruby both have Python-like behaviour in this respect. So do all the Lisp variants I can readily check (CL, elisp, Scheme, Dylan). So does Lua. I can't, offhand, think of any dynamically typed language that doesn't behave this way. Oh, except Smalltalk, which has a radically different approach to the whole business. -- g ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "and" and "or" operators in Py3.0
On 9/19/05, Andrew McNamara <[EMAIL PROTECTED]> wrote: > > I agree. I find I often have an object with an optional friendly name > (label) and a manditory system name. So this sort of thing becomes common: > > '%s blah blah' % (foo.label or foo.name) > > The if-else-expression alternative works, but isn't quite as readable: > > '%s blah blah' % (foo.label ? foo.label : foo.name) Where does this work? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] IMPORTANT: release24-maint branch is FROZEN from 2005-09-21 00:00 UTC for 2.4.2
Starting in about 11 hours time, the release24-maint branch is FROZEN for the 2.4.2c1 release. The freeze will last for around a day, and then we're in a state of mostly-frozen for another week, until 2.4.2 (final). During that week, please don't check things into the branch unless you check with me first. Let's make this a nice painless release. I'll send another message once 2.4.2 is done. Thanks, Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.path.diff(path1, path2)
Hi,
> IMO, the relpath method should just work textually on
> the pathnames. It's up to the user to ensure it makes
> sense to do so, e.g. by resolving symlinks beforehand
> if necessary.
I guess so. Don't forget to mention this quirk in the docs, though :)
> The alternative would be for relpath to do this itself,
> but that would make it very unusual compared to the
> other path-munging functions, none of which touch the file
> system.
Yes, and this behaviour would make it unusable for virtual file systems
within the application, too. Path names needn't refer to the local file
system, right? Then again, the `os' module _is_ platform-specific, as is
`os.path', so one shouldn't use it for those things either way.
In fact, relpath _cannot_ dereference symlinks on its own, as it has no
way of knowing the absolute pathname if only relative pathnames are
given as arguments (for example, relpath("a/b/c", "../d")).
But this begs the question: What is relpath good for, anyway? And what
are the hidden costs? One-time scripts might benefit from it, but having
this function in the standard library could make application developers
use it without considering the consequences, resulting in strange bugs
that occur on one machine, but not on another. The more I think about
it, the more I'm afraid that this might lead to severe security
vulnerabilities if misused in tools run by the system administrator.
Better place a big, fat warning in the docs, then.
Bye,
Matthias
Matthias Andreas Benkard, Anarchokommunist und Pythonprogrammierer
Persönliche Website: http://www.mulk.de.vu/
Persönlicher Weblog: http://www.kompottkin.de.vu/
Flames bitte nach /dev/null schicken.
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "and" and "or" operators in Py3.0
Would this change break x < y < z ? Hope not. +1 on x?y:z -1 on && || replacing and/or unless and/or kept with current semantics and && || introduced Raymond's boolean idea, but then -1 too many unrelated but different spellings On 9/19/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 9/19/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > I propose that in Py3.0, the "and" and "or" operators be simplified to > > always return a Boolean value instead of returning the last evaluated > > argument. > > While you're at it, maybe we should switch to && and || as well? > That's another thing I always mistype when switching between > languages... > > Also, this proposal needs to be considered together with the addition > of a proper conditional operator, like x?y:z. > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ldlandis%40gmail.com > -- LD Landis - N0YRQ - from the St Paul side of Minneapolis ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "and" and "or" operators in Py3.0
> >> While you're at it, maybe we should switch to && and || as well? > >> That's another thing I always mistype when switching between > >> languages... > > > > You're joking, surely? > > for Python 3000, I'd recommend switching to "and then" and "or else" instead > of the current ambiguous single-keyword versions. Wouldn't it be possible to omit "and" and "or" to just "then" and "else"? x = 3 and 7 or 44 x = 3 and then 7 or else 44 x = 3 then 7 else 44 And then have another set of and and or for non short-circuiting? -- mvh Björn ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Adding a conditional expression in Py3.0
On 9/20/05, Michael Hudson <[EMAIL PROTECTED]> wrote: > Guido van Rossum <[EMAIL PROTECTED]> writes: > > > On 9/19/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > >> I propose that in Py3.0, the "and" and "or" operators be simplified to > >> always return a Boolean value instead of returning the last evaluated > >> argument. > > > > While you're at it, maybe we should switch to && and || as well? > > That's another thing I always mistype when switching between > > languages... > > You're joking, surely? I wasn't, but I wasn't pushing for it either. Consider it withdrawn given the response. > > Also, this proposal needs to be considered together with the addition > > of a proper conditional operator, like x?y:z. > > I think this discussion has been had before, you know. Unfortunately, if we were to accept Raymond's proposal, we'd have to revisit the discussion, since his proposal removes several ways we currently avoid the need. In fact, I think Raymond's example is more properly considered an argument for adding a conditional expression than for removing the current behavior of the and/or shortcut operators; had we had a conditional expression, he wouldn't have tried to use the "x and y or z" syntax that bit him. Given this realization, I'm now -1 on Raymond's idea, and +1 on adding a conditional expression. I believe (y if x else z) was my favorite last time, wasn't it? I've changed the subject accordingly. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "and" and "or" operators in Py3.0
Greg Ewing canterbury.ac.nz> writes:
>
> Raymond Hettinger wrote:
> > I propose that in Py3.0, the "and" and "or" operators be simplified to
> > always return a Boolean value instead of returning the last evaluated
> > argument.
>
> But then I would no longer be able to write
>
>foo = something or default_value
>
> which is one of my favourite Pythonisms!
Same here. I use this frequently. In fact, I sometimes use it in preference
to a default param in {}.get():
foo = somedict.get("blarg") or expensive_default()
That way the expensive default isn't calculated unless you need it. (Of
course, the dict has to only store values that evaluate to non-False, which
might not be possible in all situations.)
Skip
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "and" and "or" operators in Py3.0
> That leaves error reduction and clarity as the main motivations for > changing 'and' and 'or' to act like '&&' and '||' and for introducing a > conditional operator to handle everyone's favorite use cases. I predict that people who use "and" and "or" correctly today will start confusing "&&" with "&" and "||" with "|", which in many instances will pass silently. In fact, I'll wager that lots of people who are familiar with boolean and/or will have never used bitwise and/or. Skip ___ Python-Dev mailing list [email protected] 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 a conditional expression in Py3.0
Guido van Rossum <[EMAIL PROTECTED]> writes: > Unfortunately, if we were to accept Raymond's proposal, we'd have to > revisit the discussion, since his proposal removes several ways we > currently avoid the need. > > In fact, I think Raymond's example is more properly considered an > argument for adding a conditional expression than for removing the > current behavior of the and/or shortcut operators; had we had a > conditional expression, he wouldn't have tried to use the "x and y or > z" syntax that bit him. Indeed. > Given this realization, I'm now -1 on Raymond's idea, and +1 on adding > a conditional expression. I believe (y if x else z) was my favorite > last time, wasn't it? I've changed the subject accordingly. It's not the version from the PEP, if that means anything at all... Cheers, mwh -- 34. The string is a stark data structure and everywhere it is passed there is much duplication of process. It is a perfect vehicle for hiding information. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "and" and "or" operators in Py3.0
Fredrik Lundh wrote: > Michael Hudson wrote: > > >>>While you're at it, maybe we should switch to && and || as well? >>>That's another thing I always mistype when switching between >>>languages... >> >>You're joking, surely? > > > for Python 3000, I'd recommend switching to "and then" and "or else" instead > of the current ambiguous single-keyword versions. > > Keeping the current behaviors in some form would probably be good. Alternate operators might be a good way. They could also be functions. first_true(a, b, c) <--- a and b and d true_else(a, b) <--- a or b This would compliment: all_true(a, b, c) none_true(a, b, c) The '?' could just be used in place of the current 'or' and the '*' would work as "and value" operator when used with bools. val = a ? b ? c# val = a or b or c val = a and b * c # val = bool(a and b) and c val = a or b * c ? d # val = bool(a or b) and c or d And a vague idea of a suggestion... For the function versions above ... If speed or the need to avoid early evaluation is a concern, one thought would be to have a few "well selected" builtin C tuple operators that look and act like functions but are instead optimized operations. Functions that don't use any intermediate values and/or are so simple that the function call is large percent of the overall execution time could be candidates. It also might be possible to avoid early evaluation in cases where it makes since to do so. Just a thought. I have no idea how hard this would be, and since one of the goals of Python 3000 is to simplify and/or clean up the core, this might not be desirable. Cheers, Ron ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 2.4.2c1 fails test_unicode on HP-UX ia64
I just built and ran the latest Python 2.4.2c1 from CVS on our HP-UX
Itanium 2 box. sys.maxint is 9223372036854775807 on this box.
I get the following failure from test_unicode (all other tests pass):
File "/var/tmp/guido/p4/Lib/test/test_unicode.py", line 553, in
test_codecs_errors
self.assertEqual(u'Andr\202 x'.encode('ascii','replace'), "Andr? x")
AssertionError: 'Andr x' != 'Andr? x'
When I try it on the command line I get the same result:
Python 2.4.2c1 (#4, Sep 20 2005, 09:15:22) [C] on hp-ux11
Type "help", "copyright", "credits" or "license" for more information.
>>> u'Andr\202 x'.encode('ascii','replace')
'Andr x'
>>>
The test passes on Linux. We have about 6 hours until code freeze...
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] For/while/if statements/comprehension/generator expressions unification
Alexander Myodov <[EMAIL PROTECTED]> wrote: > Hello Josiah, > > JC> Alexander, > JC> The essence of what you have proposed has been proposed (multiple times) > before, > JC> and I seem to remember it was shot down. > > To increase my understanding of Python-way, can you (or someone else) > explain the reasons why such proposals were rejected? > > JC> The below functions offer the equivalent of list comprehensions with a > JC> final post-processing step. > > Well, what I was suggesting is not just a cross of two lists but the > syntax sugar which would make statements more consistent to the > generators/comprehensions and also give some new opportunities. > I think that my large proposal can be splitted to several > almost-independent ones, each carrying separate features, able to > be implemented independently and worth independent reconsidering: Try using the code I offered. It allows the cross of an aribitrary number of restartable iterables, in the same order as an equivalent list comprehension or generator expression. >>> list(cross([1,2], [3,4], [5,6])) [(1, 3, 5), (1, 3, 6), (1, 4, 5), (1, 4, 6), (2, 3, 5), (2, 3, 6), (2, 4, 5), (2, 4, 6)] There were a few hoops I had to jump through in cross in order to be able to hande single iterables as well as tuples embedded in the passed iterables, but they work as they should. >>> list(cross([(1,1),(2,2)], [(3,3),(4,4)], [(5,5),(6,6)])) [((1, 1), (3, 3), (5, 5)), ((1, 1), (3, 3), (6, 6)), ((1, 1), (4, 4), (5, 5)), ((1, 1), (4, 4), (6, 6)), ((2, 2), (3, 3), (5, 5)), ((2, 2), (3, 3), (6, 6)), ((2, 2), (4, 4), (5, 5)), ((2, 2), (4, 4), (6, 6))] > 1. Bring 'if'-s from generator/comprehension 'for' syntax to 'for' > statement. That's truly inconsistent that one may write > > list2 = [i for i in list if cond(i)] > > but cannot write > > for i in list if cond(i): Note: list comprehensions and generator expressions have not been in Python since the beginning. List comprehensions were added in Python 2.0 as syntactic sugar for the common case of list construction with simple predicates. x = [] for i in y: for j in z: if f(i,j): x.append((i,j)) x = [(i,j) for i in y for j in z if f(i,j)] If you are good, you can add predicates anywhere you want inside of for loops using ifilter. def f(i): return i%2==0 def g(i): return i**2%3 < 2 for i in ifilter(f, x): for j in ifilter(g, y): ... No need to have syntax for something that is simple enough to use... If you want to filter on multiple items (updated in each loop), there is always the curry decorator and/or class offered in PEP 309 (minor modification would offer a rightcurry). For all of the reasons you offer, Nick has a great point that there is no need to complicate the for loop with generator/list comprehension semantics when you can embed either of them in the right side of the for loop. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.4.2c1 fails test_unicode on HP-UX ia64
This seems to disappear when I disable -O. I guess the HP-UX optimizer
is as bad as it always was. Or perhaps we have an old version
installed. Sorry!
On 9/20/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I just built and ran the latest Python 2.4.2c1 from CVS on our HP-UX
> Itanium 2 box. sys.maxint is 9223372036854775807 on this box.
>
> I get the following failure from test_unicode (all other tests pass):
>
> File "/var/tmp/guido/p4/Lib/test/test_unicode.py", line 553, in
> test_codecs_errors
> self.assertEqual(u'Andr\202 x'.encode('ascii','replace'), "Andr? x")
> AssertionError: 'Andr x' != 'Andr? x'
>
> When I try it on the command line I get the same result:
>
> Python 2.4.2c1 (#4, Sep 20 2005, 09:15:22) [C] on hp-ux11
> Type "help", "copyright", "credits" or "license" for more information.
> >>> u'Andr\202 x'.encode('ascii','replace')
> 'Andr x'
> >>>
>
> The test passes on Linux. We have about 6 hours until code freeze...
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
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 a conditional expression in Py3.0
Guido van Rossum wrote: > Given this realization, I'm now -1 on Raymond's idea, and +1 on adding > a conditional expression. I believe (y if x else z) was my favorite > last time, wasn't it? I've changed the subject accordingly. As the PEP states, I'm not sure if changing the customary order of "arguments" in conditional expressions is good. Also, I assume the thing will be short-circuiting, and it's confusing to grasp that y in (y if x else z) will possibly never be evaluated. Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] For/while/if statements/comprehension/generator expressions unification
On Tue, Sep 20, 2005 at 10:20:44AM -0700, Josiah Carlson wrote: > Try using the code I offered. It allows the cross of an aribitrary > number of restartable iterables, in the same order as an equivalent list > comprehension or generator expression. > > >>> list(cross([1,2], [3,4], [5,6])) > [(1, 3, 5), (1, 3, 6), (1, 4, 5), (1, 4, 6), (2, 3, 5), (2, 3, 6), (2, 4, > 5), (2, 4, 6)] > > There were a few hoops I had to jump through in cross in order to be > able to hande single iterables as well as tuples embedded in the passed > iterables, but they work as they should. > > >>> list(cross([(1,1),(2,2)], [(3,3),(4,4)], [(5,5),(6,6)])) > [((1, 1), (3, 3), (5, 5)), ((1, 1), (3, 3), (6, 6)), ((1, 1), (4, 4), (5, > 5)), ((1, 1), (4, 4), (6, 6)), ((2, 2), (3, 3), (5, 5)), ((2, 2), (3, 3), > (6, 6)), ((2, 2), (4, 4), (5, 5)), ((2, 2), (4, 4), (6, 6))] This comes up on c.l.p every month or two. Folks offer their own solutions optimized for speed, memory, or golfed for char length. I'll throw in my same two bits as always, sprat:~# python Python 2.4.1 (#2, Mar 30 2005, 21:51:10) [GCC 3.3.5 (Debian 1:3.3.5-8ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import probstat >>> c = probstat.Cartesian([[1,2], [3,4], [5,6]]) >>> list(c) [[1, 3, 5], [2, 3, 5], [1, 4, 5], [2, 4, 5], [1, 3, 6], [2, 3, 6], [1, 4, 6], [2, 4, 6]] >>> c = probstat.Cartesian([[(1,1),(2,2)], [(3,3),(4,4)], [(5,5),(6,6)]]) >>> list(c) [[(1, 1), (3, 3), (5, 5)], [(2, 2), (3, 3), (5, 5)], [(1, 1), (4, 4), (5, 5)], [(2, 2), (4, 4), (5, 5)], [(1, 1), (3, 3), (6, 6)], [(2, 2), (3, 3), (6, 6)], [(1, 1), (4, 4), (6, 6)], [(2, 2), (4, 4), (6, 6)]] The signature is slightly different (list of lists) but otherwise does what you want. Unchanged since 2002! http://probstat.sourceforge.net/ -jackdied ___ Python-Dev mailing list [email protected] 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 a conditional expression in Py3.0
On Tue, Sep 20, 2005 at 09:04:53AM -0700, Guido van Rossum wrote: > On 9/20/05, Michael Hudson <[EMAIL PROTECTED]> wrote: > > Guido van Rossum <[EMAIL PROTECTED]> writes: > > > > > On 9/19/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > >> I propose that in Py3.0, the "and" and "or" operators be simplified to > > >> always return a Boolean value instead of returning the last evaluated > > >> argument. > > > > > > While you're at it, maybe we should switch to && and || as well? > > > That's another thing I always mistype when switching between > > > languages... > > > > You're joking, surely? > > I wasn't, but I wasn't pushing for it either. Consider it withdrawn > given the response. > > > > Also, this proposal needs to be considered together with the addition > > > of a proper conditional operator, like x?y:z. > > > > I think this discussion has been had before, you know. > > Unfortunately, if we were to accept Raymond's proposal, we'd have to > revisit the discussion, since his proposal removes several ways we > currently avoid the need. > > In fact, I think Raymond's example is more properly considered an > argument for adding a conditional expression than for removing the > current behavior of the and/or shortcut operators; had we had a > conditional expression, he wouldn't have tried to use the "x and y or > z" syntax that bit him. > > Given this realization, I'm now -1 on Raymond's idea, and +1 on adding > a conditional expression. I believe (y if x else z) was my favorite > last time, wasn't it? I've changed the subject accordingly. I'm +1 for allowing authors to write return bool(thing or default) when they mean a function to return a bool. I had the "privilege" of working in a large base of perl code (a learning experience) and while some engineers abused functions that were documented as only returning true/false by depending on the side effects of 'and' and 'or' this was easily fixed. The functions were changed to literally return a plain true or false value and those engineers were summarily fired. I'm a dependable Hettinger fanboy but on this one I have to agree with the we're-all-adults club. Let the authors type an extra few chars if they want to make the code match the intent. -jackdied ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "and" and "or" operators in Py3.0
On 9/20/05, Michael Hudson <[EMAIL PROTECTED]> wrote: [SNIP] > I _like_ the explanation of 'and' and 'or' as they are now. They are > basically control flow constructs -- and have to be to get > short-circuiting to work -- and adding a coercion to bool at the end > seems to add complexity, not reduce it (on some levels, anyway). > If you change the definition of 'and' and 'or' to be boolean comparison operators (as Raymond is proposing) and not as control flow constructs then is it really that complicated? I think it would actually simplify things very slightly since you just say a boolean is returned instead of the last executed expression by the operator. > > P.S. Simplifying "and" and "or" may create a need to introduce a > > conditional operator but that is a discussion for another day. > > ... which was in the past, I thought. It was, but changing 'and' and 'or' does tweak the usefulness of a conditional operator. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 2.4.2c1: test_macfs failing on Tiger (Mac OS X 10.4.2)
test test_macfs failed -- Traceback (most recent call last): File "/Users/gvr/p4/Lib/test/test_macfs.py", line 53, in test_dates self.assertEqual(dates, (now, now-1, now-2)) AssertionError: (1127241062, 1127241062, 1127241061) != (1127241063, 1127241062, 1127241061) Any takers? What does this mean? (It looks like an off-by-one-error in the first timestamp, but I don't know what the code is trying to do). Is the filesystem perhaps truncating times? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] test_ossaudiodev hangs
On my Linux box (Red Hat Enterprise 3), test_ossaudiodev hangs forever when I enable it: ./python -E -tt ../Lib/test/regrtest.py -u all test_ossaudiodev test_ossaudiodev Traceback (most recent call last): File "../Lib/test/regrtest.py", line 1178, in ? main() File "../Lib/test/regrtest.py", line 333, in main ok = runtest(test, generate, verbose, quiet, testdir, huntrleaks) File "../Lib/test/regrtest.py", line 473, in runtest the_package = __import__(abstest, globals(), locals(), []) File "/home/guido/projects/python-2.4/dist/src/Lib/test/test_ossaudiodev.py", line 136, in ? test() File "/home/guido/projects/python-2.4/dist/src/Lib/test/test_ossaudiodev.py", line 124, in test play_sound_file(data, rate, ssize, nchannels) File "/home/guido/projects/python-2.4/dist/src/Lib/test/test_ossaudiodev.py", line 63, in play_sound_file dsp.write(data) KeyboardInterrupt This happens both with 2.4.2c1 and with 2.5a0 from current CVS. I know in order to debug you need more info about my audio device, but since I never use audio on Linux, you'll have to talk me through providing the info. I'm [EMAIL PROTECTED] on Google talk BTW. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] 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 a conditional expression in Py3.0
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > In fact, I think Raymond's example is more properly considered an > argument for adding a conditional expression than for removing the > current behavior of the and/or shortcut operators; had we had a > conditional expression, he wouldn't have tried to use the "x and y or > z" syntax that bit him. I agree. > Given this realization, I'm now -1 on Raymond's idea, There are a lot of people who use 'or', especially, as intended. > and +1 on adding a conditional expression. I believe (y if x else z) > was my favorite last time, wasn't it? No. That was your original proposal, which you later rejected. "The original version of this PEP proposed the following syntax: if else The out-of-order arrangement was found to be too uncomfortable for many of participants in the discussion; especially when is long, it's easy to miss the conditional while skimming." Your final 'favorite' was apparently (at the top) "Proposal The proposed syntax is as follows: (if : else: ) " (+ elif parts) selected from "Summary of the Current State of the Discussion Groups are falling into one of three camps: 1. Adopt a ternary operator built using punctuation characters: ? : 2. Adopt a ternary operator built using new or existing keywords. The leading examples are: then else (if : else: ) 3. Do nothing." Given the later addition of generator expressions with mandatory parentheses , the mandatory-parentheses version of a conditional expression looks less strange to me than it did then ;-). So I could happily use it even though I may still lean toward the other option 2 version (then-else) due to its not needing ':'s or a third elseif term for chaining. *If* you want general community input, I would suggest a runoff ballot with those four choices (and a summary of pros and cons of each), or fewer if you see any as unacceptible. Terry J. Reedy > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org > > ___ Python-Dev mailing list [email protected] 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 a conditional expression in Py3.0
On 9/20/05, Terry Reedy <[EMAIL PROTECTED]> wrote: > "Guido van Rossum" <[EMAIL PROTECTED]> wrote in message > > and +1 on adding a conditional expression. I believe (y if x else z) > > was my favorite last time, wasn't it? > > No. That was your original proposal, which you later rejected. Thanks for setting me straight; upon re-reading the PEP I couldn't even remember which one I favored at the time! > Your final 'favorite' was apparently (at the top) > > "Proposal > The proposed syntax is as follows: > (if : else: ) " (+ elif parts) > > selected from > > "Summary of the Current State of the Discussion >Groups are falling into one of three camps: > 1. Adopt a ternary operator built using punctuation characters: > ? : > 2. Adopt a ternary operator built using new or existing keywords. > The leading examples are: > then else > (if : else: ) > 3. Do nothing." > > Given the later addition of generator expressions with mandatory > parentheses , the mandatory-parentheses version of a conditional expression > looks less strange to me than it did then ;-). So I could happily use it > even though I may still lean toward the other option 2 version (then-else) > due to its not needing ':'s or a third elseif term for chaining. I think I'd prefer (if then else ) i.e. no colons. None of the other expression forms (list comprehensions and generator expressions) involving statement keywords use colons. > *If* you want general community input, I would suggest a runoff ballot with > those four choices (and a summary of pros and cons of each), or fewer if > you see any as unacceptible. If there's one thing I've learned from the PEP 308 vote, it is that votes for language don't work. I prefer some discussion on Python-dev after which I pick one. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] 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 a conditional expression in Py3.0
At 12:17 PM 9/20/2005 -0700, Guido van Rossum wrote: >I think I'd prefer (if then else ) i.e. no >colons. None of the other expression forms (list comprehensions and >generator expressions) involving statement keywords use colons. +1, despite the fact that we seem on a slippery slope towards becoming a kind of infix Lisp. ;) Between (yield x), (x for x in y), and now (if x then y else z), it seems that parentheses are all the rage now. Will we get (try finally ) next? <0.5 wink> > > *If* you want general community input, I would suggest a runoff ballot with > > those four choices (and a summary of pros and cons of each), or fewer if > > you see any as unacceptible. > >If there's one thing I've learned from the PEP 308 vote, it is that >votes for language don't work. I prefer some discussion on Python-dev >after which I pick one. Also +1. :) ___ Python-Dev mailing list [email protected] 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 a conditional expression in Py3.0
[Guido van Rossum] > > In fact, I think Raymond's example is more properly considered an > > argument for adding a conditional expression than for removing the > > current behavior of the and/or shortcut operators; had we had a > > conditional expression, he wouldn't have tried to use the "x and y or > > z" syntax that bit him. [Terry Reedy] > I agree. Me too. > Given the later addition of generator expressions with mandatory > parentheses , the mandatory-parentheses version of a conditional > expression > looks less strange to me than it did then ;-). Same here. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GIL, Python 3, and MP vs. UP (was Re: Variant of removing GIL.)
On Sun, 18 Sep 2005, Guido van Rossum wrote: > On 9/17/05, John J Lee <[EMAIL PROTECTED]> wrote: [...snip...] [guido] > If my hunch is right, I expect that instead of writing massively > parallel applications, we will continue to write single-threaded > applications that are tied together at the process level rather than > at the thread level. I tend to agree. [...] > > I realize that not all algorithms (nor all computational problems) scale > > well to MP hardware. Is it feasible to usefully compile both MP and a UP > > binaries from one Python source code base? > > That's an understatement. I expect that *most* problems (even most > problems that we will be programming 10-20 years from now) get little > benefit out of MP. Perhaps, but I suspect we'll also get better at thinking up multiprocessor algorithms when better motivated by lack of exponential uniprocessor speed increases. [...] > > Of course, it still takes a (anti-)hero to step forward and do the work... > > Be my guest. Prove me wrong. Talk is cheap; instead of arguing my > points (all of which can be argued ad infinitum), come back when > you've got a working GIL-free Python. Doesn't have to be CPython-based > -- C# would be fine too. I don't actively want a GIL-free Python. I was just making some arguments in favour of GIL-removal that I hadn't seen made on a public list before. (In particular, removal now, since now is a special time.) John ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] IMPORTANT: release24-maint branch is FROZEN from 2005-09-21 00:00 UTC for 2.4.2
Hi, A quick note, the profile.py module is broken -- crashes on some examples and real-world programs. I think I should be able to fix it by tomorrow, but not tonight. (See example checked in in the CVS trunk -- Lib/test/test_profile -- which passes, but for some reason I get completely unrealistic results on a real-world application. Can't investigate more now...) Armin ___ Python-Dev mailing list [email protected] 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 a conditional expression in Py3.0
On 9/20/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 12:17 PM 9/20/2005 -0700, Guido van Rossum wrote: > >I think I'd prefer (if then else ) i.e. no > >colons. None of the other expression forms (list comprehensions and > >generator expressions) involving statement keywords use colons. > > +1, despite the fact that we seem on a slippery slope towards becoming a > kind of infix Lisp. ;) Between (yield x), (x for x in y), and now (if x > then y else z), it seems that parentheses are all the rage now. Will we get > (try finally ) next? <0.5 wink> > +1 from me as well. The use will be much more obvious to a newbie than `` ? : ``. And I have used the syntactic-heavy listcomps in Haskell and I must say that Python's version is much nicer. I like the wordy version. =) > > > > *If* you want general community input, I would suggest a runoff ballot > > > with > > > those four choices (and a summary of pros and cons of each), or fewer if > > > you see any as unacceptible. > > > >If there's one thing I've learned from the PEP 308 vote, it is that > >votes for language don't work. I prefer some discussion on Python-dev > >after which I pick one. > > Also +1. :) > +1 from me, although I sure got lambasted by some people when I said I liked this style during the whole decorator debate. =) -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GIL, Python 3, and MP vs. UP
On Mon, 19 Sep 2005, Florian Weimer wrote: > The real problem is that you can ditch most extension modules. 8-( [...] *Is* that a showstopper for Python 3.0, though? John ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GIL, Python 3, and MP vs. UP (was Re: Variant of removing GIL.)
On Tue, 20 Sep 2005, John J Lee wrote: [...] > I don't actively want a GIL-free Python. I was just making some arguments [...] Actually, FWIW, I don't know if I even *passively* want a GIL-free Python, if it encourages threaded code (though I'd like to have that option for my occasional personal use, it seems to be an attractive nuisance for many other programmers). John ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GIL, Python 3, and MP vs. UP
On 9/20/05, John J Lee <[EMAIL PROTECTED]> wrote: > On Mon, 19 Sep 2005, Florian Weimer wrote: > > > The real problem is that you can ditch most extension modules. 8-( > [...] > > *Is* that a showstopper for Python 3.0, though? Who knows. I bet Guido doesn't even know how much breakage he is going to want to push. Some people have rather strongly pointed out (usually after I have proposed something), breaking stuff without a good reason is not worth the added level of breakage for when people try to update code to Python 3.0. Completely changing how garbage collection works is not exactly a minor thing and there is the possibility it won't pan out. It would really suck for everyone to have to learn an entirely new way of handling garbage collection and have there not be a perk for doing so, especially since this kind of change will not be directly visible to the language itself. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GIL, Python 3, and MP vs. UP
On Mon, 19 Sep 2005, Tim Lesher wrote: > On 9/19/05, Michael Hudson <[EMAIL PROTECTED]> wrote: > > I was disappointed that that article (hey, it was the only issue of > > ddj I've ever actually bought! :) didn't consider any concurrency > > models other than shared memory threading. > > The problem is that, for all its limitations, shared-memory threading > is the most popular concurrency model on the most popular operating > system, so future hardware platforms targeting that system will be > optimizing for that case. > > We can either rail against the sea, or accept it. Hmm, that's an interesting point. Aside from that point I tend to agree with Guido: threading is not the only, nor the best, concurrency model. But maybe these chips designed with threading in mind blow that argument out of the water. I don't know enough to know whether that's true or not... John ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GIL, Python 3, and MP vs. UP
On Tue, 20 Sep 2005, Brett Cannon wrote: > On 9/20/05, John J Lee <[EMAIL PROTECTED]> wrote: > > On Mon, 19 Sep 2005, Florian Weimer wrote: > > > > > The real problem is that you can ditch most extension modules. 8-( > > [...] > > > > *Is* that a showstopper for Python 3.0, though? > > Who knows. I bet Guido doesn't even know how much breakage he is > going to want to push. Some people have rather strongly pointed out > (usually after I have proposed something), breaking stuff without a > good reason is not worth the added level of breakage for when people > try to update code to Python 3.0. Oh, absolutely. > Completely changing how garbage > collection works is not exactly a minor thing and there is the > possibility it won't pan out. It would really suck for everyone to > have to learn an entirely new way of handling garbage collection and > have there not be a perk for doing so, especially since this kind of > change will not be directly visible to the language itself. I didn't intend to refer to garbage collection in particular, but to removing the GIL, thus breaking extension modules (perhaps in a less-drastic way than implied by the copying garbage-collection proposal). John ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] IMPORTANT: release24-maint branch is FROZEN from 2005-09-21 00:00 UTC for 2.4.2
Hi, On Tue, Sep 20, 2005 at 09:21:14PM +0200, Armin Rigo wrote: > A quick note, the profile.py module is broken -- crashes on some > examples and real-world programs. I think I should be able to fix it by > tomorrow, but not tonight. It was easier than I thought, sorry for the alarm. Armin ___ Python-Dev mailing list [email protected] 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 a conditional expression in Py3.0
Guido van Rossum wrote: > I think I'd prefer (if then else ) i.e. no > colons. None of the other expression forms (list comprehensions and > generator expressions) involving statement keywords use colons. FWIW, I find this quite intuitive. It follows the same pattern as LCs and GEs -- remove the colons and add parentheses (or brackets for LCs). So I'm +1. STeVe -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list [email protected] 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 a conditional expression in Py3.0
(Adding python-dev back to the CC list) On 9/20/05, Jason Orendorff <[EMAIL PROTECTED]> wrote: > > If there's one thing I've learned from the PEP 308 vote, it is that > > votes for language don't work. I prefer some discussion on Python-dev > > after which I pick one. > > +1 > > Some visual aids: > > return (if q: q.popleft() else: None) > return (if q then q.popleft() else None) > return q ? q.popleft() : None > > Hmmm. Score one for ?:. But: Why? Just because it's shorter? > menu.append( > if gotHerring(): popHerring() > elif gotAnyFish(): popAnyFish() > else: Tofurbot()) > > menu.append(gotHerring() ? popHerring() : gotAnyFish() ? > popAnyFish() : Tofurbot()) > > Here, I like the way the verbose syntax politely spreads itself out > over multiple lines. In C, I never know where to put the line breaks. Ouch. You're bringing up another valid issue: whether to support "elif". I think if we go with (if ... then ... else ...) or (if ...: ... else: ...) we'll have to support elif as well: (if ... then ... elif ... then ... else ...) or (if ...: ... elif ...: ... else: ...) I really don't like the latter. Here's a suggestion for a way to decide between a "wordy" version or C-style "?:" -- if we abandon and/or in favor of &&/||, we should also go with ?:; if we keep and/or, we should use a keyword-based conditional as well. Since so far the feedback is overwhelmingly in favor of keeping and/or, I think that settles the case in favor of a wordy version. My preference then would be (if ... then ... elif ... then ... else ...) which gives my a nice nostalgic feeling because (except for the elif part) Algol-60 had the same thing -- the first programming language I ever learned. :) (Oh, and a way to decide between colon or no colon: we're not using colons in list comps and genexprs either.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GIL, Python 3, and MP vs. UP
On 9/20/05, John J Lee <[EMAIL PROTECTED]> wrote: > threading is not the only, nor the best, concurrency model. > But maybe these chips designed with threading in mind blow that argument > out of the water. I don't know enough to know whether that's true or > not... I don't know that any chips are designed with threading in mind. Fast threading benefits from fast context switches which benefits from small register sets. I believe the trend is towards ever large register sets. Also, multiple processors with shared memory don't scall all that well; multiple processors with explicit IPC channels scale much better. All arguments for multi-processing and against multi-threading. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] bool(iter([])) changed between 2.3 and 2.4
I just finished debugging some code that broke after upgrading to Python 2.4 (from 2.3). Turns out the code was testing list iterators for their boolean value (to distinguish them from None). In 2.3, a list iterator (like any iterator) is always true. In 2.4, an exhausted list iterator is false; probably by virtue of having a __len__() method that returns the number of remaining items. I realize that this was a deliberate feature, and that it exists in 2.4 as well as in 2.4.1 and will in 2.4.2; yet, I'm not sure I *like* it. Was this breakage (which is not theoretical!) considered at all? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] 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 a conditional expression in Py3.0
On Tue, 2005-09-20 at 17:40, Guido van Rossum wrote: > Ouch. You're bringing up another valid issue: whether to support > "elif". I think if we go with (if ... then ... else ...) or (if ...: > ... else: ...) we'll have to support elif as well: I'm not so sure. Once you start writing such a complicated thing, I think readability will favor just breaking the code out into traditional if-blocks. I'd be happy enough with just a binary condition. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bool(iter([])) changed between 2.3 and 2.4
On Tuesday 20 September 2005 17:49, Guido van Rossum wrote: > I realize that this was a deliberate feature, and that it exists in > 2.4 as well as in 2.4.1 and will in 2.4.2; yet, I'm not sure I *like* I wasn't paying any attention at the time, so I don't know what was discussed. Some discussion here just now leads me to believe that at least two of us here (including myself) think iterators shouldn't have length at all: they're *not* containers and shouldn't act that way. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GIL, Python 3, and MP vs. UP
On Sep 20, 2005, at 5:43 PM, Guido van Rossum wrote: > On 9/20/05, John J Lee <[EMAIL PROTECTED]> wrote: > >> threading is not the only, nor the best, concurrency model. >> But maybe these chips designed with threading in mind blow that >> argument >> out of the water. I don't know enough to know whether that's true or >> not... >> > > I don't know that any chips are designed with threading in mind. Fast > threading benefits from fast context switches which benefits from > small register sets. I believe the trend is towards ever large > register sets. Also, multiple processors with shared memory don't > scall all that well; multiple processors with explicit IPC channels > scale much better. All arguments for multi-processing and against > multi-threading. Well, in many operating systems, there isn't a whole lot of difference between threads and processes (both are kernel threads). When using threads, you can typically still use IPC, so you could scale similarly. I think the biggest argument for threading is simply that lots of existing C/C++ code wants to use threads. What we have now works OK, but you can't reliably use Python in a real-time thread (e.g. a CoreAudio callback) or (reliably) in a signal handler because it might block too long because of something else going on. Of course, a lot of other design decisions in Python would prevent you from using it in that context too, so GIL-free threading wouldn't be a panacea. Personally my biggest issue with the way the CPython VM works is that you can't reliably do multiple interpreters in a single process. If that worked well, you could start an independent interpreter per thread and with a per-interpreter GIL you'd have pretty much everything you needed... but this would horribly break the C API and may be a performance hit. My use case for this isn't so much about threads, but plug-ins. Writing multiple Python-based plug-ins for an application is always a mess, because they share too much (sys.modules, sys.path, etc.). PyObjC would benefit greatly from this feature, because you can write Python-based plug-ins for any Cocoa app that supports plug-ins, even if they're otherwise unaware of Python's existence. There are workarounds, of course, with import hooks and similar hacks. I think that mod_python would also benefit from this, and probably other such systems. -bob ___ Python-Dev mailing list [email protected] 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 a conditional expression in Py3.0
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On 9/20/05, Terry Reedy <[EMAIL PROTECTED]> wrote: >> Given the later addition of generator expressions with mandatory >> parentheses , the mandatory-parentheses version of a conditional >> expression >> looks less strange to me than it did then ;-). So I could happily use >> it >> even though I may still lean toward the other option 2 version >> (then-else) >> due to its not needing ':'s or a third elseif term for chaining. > > I think I'd prefer (if then else ) i.e. no > colons. None of the other expression forms (list comprehensions and > generator expressions) involving statement keywords use colons. I presume this revision would continue to include elif clauses. If I put on a 'designing Python for everyone' hat, then the presence of the leading 'if' looks better than the slightly-too-cute (especially for Python) abbreviated version. +1 >> *If* you want general community input, I would suggest a runoff ballot >> with >> those four choices (and a summary of pros and cons of each), or fewer if >> you see any as unacceptible. > > If there's one thing I've learned from the PEP 308 vote, it is that > votes for language don't work. I prefer some discussion on Python-dev > after which I pick one. If we reject both the status quo and the symbol-tax form and agree on the above as the best wordy form, then it is a moot point anyway ;-) C.l.p. newcomers continue to periodically request "How do I write conditional expressions?". I think most will be happier with something clear and readable. Terry J. Reedy ___ Python-Dev mailing list [email protected] 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 a conditional expression in Py3.0
On 9/20/05, Guido wrote: > On 9/20/05, Jason Orendorff <[EMAIL PROTECTED]> wrote: > > return (if q: q.popleft() else: None) > > return (if q then q.popleft() else None) > > return q ? q.popleft() : None > > > > Hmmm. Score one for ?:. > > Why? Just because it's shorter? Just a gut response to the look. The verbose forms strike me as cluttered in this particular case. In the multiline case, it doesn't look like clutter because the if/elif/else bits line up, which fits the way Python has already trained my brain. > (Oh, and a way to decide between colon or no colon: we're not using > colons in list comps and genexprs either.) (grin) Easily fixed: print "average weight:", avg(for c in chefs: c.weight) rdict = dict(for k, v in D.iteritems(): v, k) Honestly, I think I would prefer this syntax. Examples from real code, before and after: lines = [line for line in pr.block.body if line.logical_line.strip() != ''] lines = [for line in pr.block.body: if line.logical_line.strip() != '': line] row.values = \ [line[col.start:col.end].strip() for col in columns] row.values = \ [for col in columns: line[col.start:col.end].rstrip()] return [p for p in self.listdir(pattern) if p.isdir()] return [for p in self.listdir(pattern): if p.isdir(): p] -j ___ Python-Dev mailing list [email protected] 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 a conditional expression in Py3.0
Steven Bethard wrote: > Guido van Rossum wrote: > >>I think I'd prefer (if then else ) i.e. no >>colons. None of the other expression forms (list comprehensions and >>generator expressions) involving statement keywords use colons. > > > FWIW, I find this quite intuitive. It follows the same pattern as LCs > and GEs -- remove the colons and add parentheses (or brackets for > LCs). So I'm +1. *But*, in LC's and GE's, the body of the main clause of the statement is also pulled out and placed in front of the keyword: def gen(): for VAR in ITERABLE: if COND: yield EXPR becomes: gen = (EXPR for VAR in ITERABLE if COND) This makes sense to me, because the most important thing in the generator expression is the way each element is populated - the source iterable and the filtering condition do matter, but they aren't as important. It also makes the expression forms more declarative in nature, rather than being procedural statements embedded inside an expression. Notice also that, in this case, if ITERABLE is empty, or COND always evaluates false in boolean context, then EXPR is never executed - in other words, Python already has precedent for out of order code execution in expression evaluation. Guido's original PEP 308 proposal worked much the same way: if COND: x = EXPR1 else: x = EXPR2 became: x = (EXPR1 if COND else EXPR2) I see this as similar in spirit to the current form of LC's and GE's - the most important things are the two possible values rather than the condition for choosing between them, and this form makes them clearly visible at the start and end of the expression, rather than embedding one of them in the middle. The post-filtered form is also similarly declarative rather than procedural. This version doesn't need a separate 'elif' form - elif can be written as: x = (EXPR1 if COND1 else EXPR2 if COND2 else EXPR3) Note that the keyword count is no higher than if 'elif' was used, because the 'then' keyword isn't needed: x = (if COND1 then EXPR1 elif COND2 then EXPR2 else EXPR3) Here's Raymond's problematic example using this original PEP 308 form: def real(self): 'Return a vector with the real part of each input element' # do not convert integer inputs to floats return self.map(lambda z: (z.real if type(z)==types.ComplexType else z)) And the other non-colon, keyword based proposal in PEP 308's top four: def real(self): 'Return a vector with the real part of each input element' # do not convert integer inputs to floats return self.map(lambda z: (if type(z)==types.ComplexType then z.real else z)) Another common use case would be for mutable default arguments: x = ([] if arg is None else list(arg)) x = (if arg is None then [] else list(arg)) Basically, I'm +1 on the original PEP 308 form because it reads more naturally (and more like LC's and GE's) to me in expression contexts, and +0 on the "if/then/elif/else" form (because I would like a real conditional operator). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] 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 a conditional expression in Py3.0
Guido van Rossum wrote: > I think I'd prefer (if then else ) i.e. no colons. > None of the other expression forms (list comprehensions and generator > expressions) involving statement keywords use colons. While I like the looks of the form without colons better, I can't quite follow this argument for it. In LCs and GEs, colons wouldn't make any sense in the first place because the expression controlled by "for" and "if" is written before it: [expression(x) for x in y]. Just where would anyone put a colon there, anyway? A colon does make sense if something follows it, as is currently the case in lambda expressions. It would also be the case in an (if x: y else: z) form. I have a feeling that trying to make all expression forms which happen to use statement keywords colon-free is seeking an artificial consistency. I'm happy to be proven wrong, though. +1 on the idea of introducing a conditional expression in the first place, though. -- Thomas ___ Python-Dev mailing list [email protected] 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 a conditional expression in Py3.0
Barry Warsaw wrote: > I'm not so sure. Once you start writing such a complicated thing, I think > readability will favor just breaking the code out into traditional > if-blocks. I'd be happy enough with just a binary condition. Nothing prevents you from spreading the code over multiple lines, like so: x = (if a then b elif c then d else e) or even x = (if a then b elif c then d else e ) especially as there are going to be parentheses around the whole thing anyway. From a readability point of view, this is no different from if-statement blocks, and the matter is IMO not worth dumbing down an if-expression thingy as compared to its if-statement companion. -- Thomas ___ Python-Dev mailing list [email protected] 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 a conditional expression in Py3.0
On Tue, 2005-09-20 at 18:21, Thomas Lotze wrote: > Nothing prevents you from spreading the code over multiple lines, like so: > > x = (if a then b > elif c then d > else e) > > or even > > x = (if a then > b > elif c then > d > else > e > ) > > especially as there are going to be parentheses around the whole thing > anyway. From a readability point of view, this is no different from > if-statement blocks, and the matter is IMO not worth dumbing down an > if-expression thingy as compared to its if-statement companion. I guess that's my point. To me, your latter is actually worse than if a: x = b elif c: x = d else: x = e I think the conditional stuff gets the most bang for the buck in situations like: d[foo] = if a then b else c -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Adding a conditional expression in Py3.0
Guido van Rossum: > I think I'd prefer (if then else ) In isolation, (if .. then ... else) is an improvement, but I'm not sure it should be viewed in isolation. At one point, you wanted to strengthen the distinction between statements and expressions. Is that still true? x = (if y then y.val else default) x = (if y: y.val else: default) If any statement can become an expression, that could be very useful. There are times when it would be convenient to just grab the newly created function (def replacing lambda) or class, or the newly imported module. The distinction between exec and eval starts to look increasingly arbitrary as well. But if everything becomes expression-able, people *will* start to use parentheses instead of indentation. -jJ ___ Python-Dev mailing list [email protected] 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 a conditional expression in Py3.0
Barry Warsaw wrote: >> x = (if a then >> b >> elif c then >> d >> else >> e >> ) [...] > > I guess that's my point. To me, your latter is actually worse than > > if a: > x = b > elif c: > x = d > else: > x = e Can't see a difference as far as readability is concerned. But then, tastes differ. > I think the conditional stuff gets the most bang for the buck in > situations like: > > d[foo] = if a then b else c And I think similar holds for LCs and GEs. Unwinding a complex sequence of for and if clauses is certainly no fun unless one is really used to it. (Which doesn't take long, though.) But your example poses another question: Up until now, I had the impression that parentheses should be mandatory around a conditional expression. There's certainly no avoiding them in situations like (if x then 1 else 2) + 3. But what about unambiguous cases like your example line? -- Thomas ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bool(iter([])) changed between 2.3 and 2.4
Fred L. Drake, Jr. wrote: > On Tuesday 20 September 2005 17:49, Guido van Rossum wrote: > > I realize that this was a deliberate feature, and that it exists in > > 2.4 as well as in 2.4.1 and will in 2.4.2; yet, I'm not sure I > *like* > > I wasn't paying any attention at the time, so I don't know what was > discussed. Some discussion here just now leads me to believe that at > least two of us here (including myself) think iterators shouldn't > have length at all: they're *not* containers and shouldn't act that > way. In any case, it's simple to get the 2.3 behaviour back - just add __nonzero__. I think that could validly be considered a bugfix. Tim Delaney ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bool(iter([])) changed between 2.3 and 2.4
On 9/20/05, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote: > In any case, it's simple to get the 2.3 behaviour back - just add > __nonzero__. I think that could validly be considered a bugfix. Alas not -- it would still be a functionality change relative to 2.4 and 2.4.1. Also, an object whose __len__() returns 0 but whose __nonzero__() returns True would be an anomaly. The best we can do IMO is to change it back in 2.5. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] 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 a conditional expression in Py3.0
On Wed, 21 Sep 2005, Thomas Lotze wrote:
> Barry Warsaw wrote:
>
> >> x = (if a then
> >> b
> >> elif c then
> >> d
> >> else
> >> e
> >> )
> [...]
> >
> > I guess that's my point. To me, your latter is actually worse than
> >
> > if a:
> > x = b
> > elif c:
> > x = d
> > else:
> > x = e
>
> Can't see a difference as far as readability is concerned. But then,
> tastes differ.
[...]
With the former, we have a more C-style syntax where meaning is determined
purely by delimeters rather than by whitespace. Instead of braces '{' and
'}', we have 'then' and 'elif'/'else'. That's a real difference.
The stricter form where you don't allow 'elif' will get used in more
restricted circumstances, so gives less encouragement for widespread abuse
of conditional expressions by people who don't like whitespace-based
syntax.
John
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bool(iter([])) changed between 2.3 and 2.4
[Guido] > I just finished debugging some code that broke after upgrading to > Python 2.4 (from 2.3). Turns out the code was testing list iterators > for their boolean value (to distinguish them from None). In 2.3, a > list iterator (like any iterator) is always true. In 2.4, an exhausted > list iterator is false; probably by virtue of having a __len__() > method that returns the number of remaining items. > > I realize that this was a deliberate feature, and that it exists in > 2.4 as well as in 2.4.1 and will in 2.4.2; yet, I'm not sure I *like* > it. Was this breakage (which is not theoretical!) considered at all? It was not considered. AFAICT, 2.3 code assuming the Boolean value of an iterator being true was relying on an accidental implementation detail that may not also be true in Jython, PyPy, etc. Likewise, it is not universally true for arbitrary class based iterators which may have other methods including __nonzero__ or __len__. The Boolean value of an iterator is certainly not promised by the iterator protocol as specified in the docs or the PEP. The code, bool(it), is not really clear about its intent and seems a little weird to me. The reason it wasn't considered was that it wasn't on the radar screen as even a possible use case. On a tangential note, I think in 2.2 or 2.3, we found a number of bugs related to None testing. IIRC, the outcome of that conversation was a specific recommendation to NOT determine Noneness by Boolean tests. That recommendation ended-up making it into PEP 290: http://www.python.org/peps/pep-0290.html#testing-for-none [Fred] > think iterators shouldn't have length at all: > they're *not* containers and shouldn't act that way. Some iterators can usefully report their length with the invariant: len(it) == len(list(it)). There are some use cases for having the length when available. Also, there has been plenty of interest in being able to tell, when possible, if an iterator is empty without having to call it. AFAICT, the only downside was Guido's bool(it) situation. FWIW, the origin of the idea came from reading a comp-sci paper about ways to overcome the limitations of linking operations together using only iterators (the paper's terminology talked about map/fold operations). The issue was that decoupling benefits were partially offset by the loss of useful information about the input to an operation (i.e. the supplier may know and the consumer may want to know the input size, the input type, whether the elements are unique, whether the data is sorted, its provenance, etc.) Raymond ___ Python-Dev mailing list [email protected] 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 a conditional expression in Py3.0
On Tue, 20 Sep 2005, John J Lee wrote:
[...]
> With the former, we have a more C-style syntax where meaning is determined
> purely by delimeters rather than by whitespace. Instead of braces '{' and
> '}', we have 'then' and 'elif'/'else'. That's a real difference.
[...]
Um, not clear, sorry: the "real difference" I meant to refer to above is
that between delimiter-based and whitespace-based syntaxes (and not
between braces and differently-spelled delimiters).
John
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bool(iter([])) changed between 2.3 and 2.4
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >I just finished debugging some code that broke after upgrading to > Python 2.4 (from 2.3). Turns out the code was testing list iterators > for their boolean value (to distinguish them from None). This seem unnecessarily indirect. Why not 'it != None' or now, 'it is not None'? >In 2.3, a > list iterator (like any iterator) is always true. In 2.4, an exhausted > list iterator is false; probably by virtue of having a __len__() > method that returns the number of remaining items. According to 2.4 News, dict iterators also got __len__ method, though I saw no mention of list. > I realize that this was a deliberate feature, I presume there were two reasons: internal efficiency of preallocations (list(some_it) for example) and letting people differentiate iterator with something left to return versus nothing, just as we can differentiate collections with something versus nothing. > and that it exists in > 2.4 as well as in 2.4.1 and will in 2.4.2; yet, I'm not sure I *like* > it. Was this breakage (which is not theoretical!) considered at all? Searching the gmane archive with the link given on the python site for 'iterator len', I could not find any discussion of the __len__ method addition itself. Terry J. Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bool(iter([])) changed between 2.3 and 2.4
On 9/20/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [Guido] > > I just finished debugging some code that broke after upgrading to > > Python 2.4 (from 2.3). Turns out the code was testing list iterators > > for their boolean value (to distinguish them from None). In 2.3, a > > list iterator (like any iterator) is always true. In 2.4, an exhausted > > list iterator is false; probably by virtue of having a __len__() > > method that returns the number of remaining items. > > > > I realize that this was a deliberate feature, and that it exists in > > 2.4 as well as in 2.4.1 and will in 2.4.2; yet, I'm not sure I *like* > > it. Was this breakage (which is not theoretical!) considered at all? > > It was not considered. That's too bad. > AFAICT, 2.3 code assuming the Boolean value of > an iterator being true was relying on an accidental implementation > detail that may not also be true in Jython, PyPy, etc. That's bullshit, and you know it -- you're just using this to justify that you didn't think of this. Whether an object is true or not is well-defined by the language and not by an accident of the implementation. Apart from None, all objects are always true unless they define either __nonzero__() or (in its absence) __len__(). The iterators for builtin sequences were carefully designed to have the minimal API required of iterators -- i.e., next() and __iter__() and nothing more. > Likewise, it is > not universally true for arbitrary class based iterators which may have > other methods including __nonzero__ or __len__. And those are the *only* ones that affect the boolean value. > The Boolean value of an > iterator is certainly not promised by the iterator protocol as specified > in the docs or the PEP. it was implied by not specifying a __nonzero__ or __len__. > The code, bool(it), is not really clear about > its intent and seems a little weird to me. Of course that's not what the broken code actually looked like. If was something like if ...: iter1 = iter(...) else: iter1 = None if ...: iter2 = iter(...) else: iter2 = None ... if iter1 and iter2: ... Where the arguments to the iter() functions were known to be lists. > The reason it wasn't > considered was that it wasn't on the radar screen as even a possible use > case. Could you at least admit that this was an oversight and not try to pretend it was intentional breakage? > On a tangential note, I think in 2.2 or 2.3, we found a number of bugs > related to None testing. IIRC, the outcome of that conversation was a > specific recommendation to NOT determine Noneness by Boolean tests. > That recommendation ended-up making it into PEP 290: > > http://www.python.org/peps/pep-0290.html#testing-for-none And I agree with that one in general (I was bitten by this in Zope once). But it bears a lot more weight when the type of the object is unknown or partially unknown. In my case, there was no possibility that the iter() argument was anything except a list, so the type of the iterator was fully known. > [Fred] > > think iterators shouldn't have length at all: > > they're *not* containers and shouldn't act that way. > > Some iterators can usefully report their length with the invariant: >len(it) == len(list(it)). I still consider this an erroneous hypergeneralization of the concept of iterators. Iterators should be pure iterators and not also act as containers. Which other object type implements __len__ but not __getitem__? > There are some use cases for having the length when available. Also, > there has been plenty of interest in being able to tell, when possible, > if an iterator is empty without having to call it. AFAICT, the only > downside was Guido's bool(it) situation. Theer is plenty of interest in broken features all the time. IMO giving *some* iterators discoverable length (and other properties like reversability) but not all of them makes the iterator protocol more error-prone -- we're back to the situation where someone codes an algorithm for use with arbitrary iterators but only tests it with list and tuple iterators, and ends up breaking in the field. I know you can work around it, but that requires introspection which is not a great match for this kind of application. > FWIW, the origin of the idea came from reading a comp-sci paper about > ways to overcome the limitations of linking operations together using > only iterators (the paper's terminology talked about map/fold > operations). The issue was that decoupling benefits were partially > offset by the loss of useful information about the input to an operation > (i.e. the supplier may know and the consumer may want to know the input > size, the input type, whether the elements are unique, whether the data > is sorted, its provenance, etc.) Not every idea written up in a comp-sci paper is worth implementing (as acquisition in Zope 2 has amply proved). -- --Guido van Rossum (home page: http://www.python.org/~guido/) __
Re: [Python-Dev] bool(iter([])) changed between 2.3 and 2.4
On 9/20/05, Terry Reedy <[EMAIL PROTECTED]> wrote: > I presume there were two reasons: internal efficiency of preallocations > (list(some_it) for example) This could have been implemented without making the implementation details public. > and letting people differentiate iterator with > something left to return versus nothing, just as we can differentiate > collections with something versus nothing. But this is against the very idea of the iterator protocol -- for general iterators, there may be no way to determine whether there is a next item without actually producing the item, so the proper approach is to code with that in mind. When this type of look-ahead is required, a buffering iterator should be inserted, so that the algorithm can work with all iterators rather than only with iterators over built-in containers. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] For/while/if statements/comprehension/generator expressions unification
Alexander Myodov wrote: > for i in largelist while !found: This doesn't cover enough use cases to be worth it, IMO. The exit condition is often buried in the middle of other statements in the loop, not right at the beginning. -- 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.path.diff(path1, path2)
Matthias Andreas Benkard wrote: > But this begs the question: What is relpath good for, anyway? [Assuming you mean "invites", "prompts", etc. the question...:-)] A couple of use cases I've encountered: * Creating symbolic links. I'm traversing a directory hierarchy, and building a parallel hierarchy somewhere else that contains symbolic links into the original one. I want the links to be relative, so that e.g. I can move my home directory without all my links breaking. * In a recent project, I had occasion to store pathnames of picture files in a relational database. I wanted to store the pathnames relative to a user-chosen "Pictures" directory, so that it could be moved without having to update all the pathnames in the database. Both of these happen to involve pathnames that exist on the currrently available file system, but I can easily imagine cases where that would not be so. E.g. I might be generating pathames to go into a tar file that will be unpacked in a different place or on another system. -- 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GIL, Python 3, and MP vs. UP
At 06:10 PM 9/20/2005 -0400, Bob Ippolito wrote: >My use case for this isn't so much about threads, but plug-ins. >Writing multiple Python-based plug-ins for an application is always a >mess, because they share too much (sys.modules, sys.path, etc.). >PyObjC would benefit greatly from this feature, because you can write >Python-based plug-ins for any Cocoa app that supports plug-ins, even >if they're otherwise unaware of Python's existence. There are >workarounds, of course, with import hooks and similar hacks. I think >that mod_python would also benefit from this, and probably other such >systems. To that list of shared things, one can easily add sys.argv, sys.stdin, sys.stdout, sys.stderr, os.environ, and on and on and on. But the ones you mention present special issues for testing, especially testing of import hooks, path management tools and so on. Decimal contexts are slightly better in that they're at least thread-local. But even if all of these things were thread-local, you'd still have problems with task switches between pseudothreads, or just maintaining logically separate contexts between e.g. different plugins. I've actually got an idea of how to solve these problems, at least for Python-level code, although for it to work right with Python's import internals it'd be necessary to use PyObject_* APIs against sys.modules instead of PyDict_* ones. Apart from that, it's implementable in pure Python, so non-CPython implementations should be able to use it too. I've been considering writing a PEP for it, since it also adds a generally-useful way of dealing with "context variables" (like the Decimal context and the sys.* variables), while being able to support switching *all* context variables simultaneously and instantaneously when changing execution contexts (like switching between coroutines). For example, it would let 1000 pseudothreads each have a unique current value for sys.stdout or the current decimal context, addressing a gap in the fit between PEP 343 and PEP 342. There's currently no reasonable way to task switch between co-routines in the body of a 'with:' statement, so things like "with redirecting_stdout()" to two places in different coroutines breaks horribly. But context managers implemented via context variables would handle such situations automatically, and with isolation of effects to the current thread. It would also allow you to have logically distinct plugins by swapping their context variables in when you make callbacks to them, so the notion of the "task" to which a set of context variables applies is not limited to coroutines. My prototype implementation of the basic idea is <200 lines of Python and very fast: ~2usec on my budget PC to switch between two arbitrarily-sized sets of context variables. The data structure is O(1) for switching sets or changing values; it's only O(N) the next time you change a value after taking a read-only snapshot of the whole context. (Taking a snapshot is O(1) due to copy-on-write; you can take as many snapshots of the same unchanged state without creating any new objects.) It also takes about 2uS to read a context variable, alas, but a C version could drop the overhead down to as little as a single dictionary lookup if the "context pointer" were kept in the thread state structure. (A fair bit of the Python implementation's overhead is just getting to the context mapping for the current thread.) The idea isn't fully PEP-ready at this point, though. I still need to flesh out my ideas regarding how context variables would be initialized in new threads, for example, or when you spawn new coroutines. ___ Python-Dev mailing list [email protected] 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 a conditional expression in Py3.0
"John J Lee" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > The stricter form where you don't allow 'elif' will get used in more > restricted circumstances, so gives less encouragement for widespread > abuse > of conditional expressions by people who don't like whitespace-based > syntax. I think 'abusiveness' is somewhat in the eye of the beholder here. In any case, without 'elif', one could still chain expressions by writing x = (if a then b else (if c then d else e)) which is even more Lispish. I personally think one () is enough and prefer x = (if a then b elif c then d else e) which is similar to how I wrote such things in C. Elif has the same justification here as with the statement form, where it is also unnecessary but saves nesting levels. Terry J. Reedy ___ Python-Dev mailing list [email protected] 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 a conditional expression in Py3.0
Terry Reedy wrote: > "The original version of this PEP proposed the following syntax: > if else > The out-of-order arrangement was found to be too uncomfortable > for many of participants in the discussion; especially when > is long, it's easy to miss the conditional while > skimming." Guido wrote that while he was in listen-to-the-masses mode. If he's switched back to follow-my-instincts mode, it may need to be re-evaluated. -- 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 [email protected] 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 a conditional expression in Py3.0
Guido van Rossum wrote: > I think if we go with (if ... then ... else ...) or (if ...: > ... else: ...) we'll have to support elif as well: > > (if ... then ... elif ... then ... else ...) > or > (if ...: ... elif ...: ... else: ...) One nice thing about "x if b else y" is that it chains without needing any more keywords: x if b else y if c else z But if you require parens, it's not so nice: (x if b else (y if c else z)) -- 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bool(iter([])) changed between 2.3 and 2.4
Guido van Rossum wrote: > I just finished debugging some code that broke after upgrading to > Python 2.4 (from 2.3). Turns out the code was testing list iterators > for their boolean value (to distinguish them from None). In 2.3, a > list iterator (like any iterator) is always true. In 2.4, an exhausted > list iterator is false; probably by virtue of having a __len__() > method that returns the number of remaining items. This seems like a misfeature to me. In fact I think an iterator having a len() method at all is a misfeature -- the concept doesn't make sense. -- 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "and" and "or" operators in Py3.0
BJörn Lindqvist wrote: > Wouldn't it be possible to omit "and" and "or" to just "then" and "else"? > > x = 3 and 7 or 44 > x = 3 and then 7 or else 44 > x = 3 then 7 else 44 > > And then have another set of and and or for non short-circuiting? I don't think the OP was suggesting that 'and' and 'or' be non-short-circuiting, only that they coerce their evaluated operands to bool. Short-circuiting vs. non-short-circuiting is an orthogonal issue. -- 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "and" and "or" operators in Py3.0
Fredrik Lundh wrote: > for Python 3000, I'd recommend switching to "and then" and "or else" instead > of the current ambiguous single-keyword versions. And then we could call the language Pyffel. :-) -- 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
