Re: [Python-Dev] IMPORTANT: release24-maint branch is FROZEN from 2005-09-21 00:00 UTC for 2.4.2

[Michael Hudson]

Michael Hudson <[EMAIL PROTECTED]> writes:

> Jeremy Maxfield <[EMAIL PROTECTED]> writes:
>
>> Sorry I think you're 'much mistaken'...
>>  
>> The revision of PyState.c in the rc242c1  looks like 2.38.22 (should be
>> 2.42)
>> and threadmodule.c looks like  2.59 (should be 2.64)
>
> Looks like you're right but SF CVS is being *astonishingly* slow right
> now.  The fixes will be in 2.4.2.

OK, I've finally managed to get these changes checked in.

Cheers,
mwh

-- 
. <- the pointyour article -> .
|- a long way |
   -- Christophe Rhodes, ucam.chat
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] IMPORTANT: release24-maint branch is FROZEN from 2005-09-21 00:00 UTC for 2.4.2

[Jeremy Maxfield]

That's great - thanks alot.
Cheers,
Max
 
On 9/23/05, Michael Hudson <[EMAIL PROTECTED]> wrote:
Michael Hudson <[EMAIL PROTECTED]> writes:> Jeremy Maxfield <
[EMAIL PROTECTED]> writes:>>> Sorry I think you're 'much mistaken'... The revision of PyState.c in the rc242c1  looks like 2.38.22 (should be
>> 2.42)>> and threadmodule.c looks like  2.59 (should be 2.64)>> Looks like you're right but SF CVS is being *astonishingly* slow right> now.  The fixes will be in 2.4.2.OK, I've finally managed to get these changes checked in.
Cheers,mwh--   . <- the pointyour article -> .   |- a long way |  -- Christophe Rhodes, 
ucam.chat___Python-Dev mailing listPython-Dev@python.orghttp://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/anothermax%40gmail.com
-- flickr: http://www.flickr.com/photos/anothermax/sets 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Repository for python developers

[Mikhail Kashkin]

Moscow, Russia, September 23th, 2005

We are happy to spread good news about `Key Solutions' 
`_ new initiative. We have created a new public 
repository for python developers. The ulitimate goal of this project is 
to unite companies and people under the umbrella of 
Russian-speaking-python (Zope/Plone/Zope3/Twisted/etc) open source 
programmers community, so that we could jointly push forward new 
programs and technologies in Russia.

The repository powered by `subversion `_.

**Links**:

- `Press release in russian `_

- `Новость на русском `_

- `Subversion `_

About Key Solutions


Key Solutions is an open source company with primary focus in 
development of corporative CRM Internet/intranet systems and 
web-communities. The company promotes and supports Zope, Plone, Asterisk 
platforms in Russia.

To learn more about Key Solutions visit `eng.keysolutions.ru 
`_ and
`keysolutions.ru `_

-- 
Mikhail Kashkin,
Key Solutions (http://keysolutions.ru/)
Director
Zope/Asterisk/Plone - Solutions/Consulting/Support
Plone на русском http://plone.org.ru/
Plone Foundation Member (http://plone.org/foundation/members/)


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GIL, Python 3, and MP vs. UP

[Michael Hudson]

"Gregory P. Smith" <[EMAIL PROTECTED]> writes:

> On Mon, Sep 19, 2005 at 09:12:05PM +0100, Michael Hudson wrote:
>> Martin Blais <[EMAIL PROTECTED]> writes:
>> > http://www.gotw.ca/publications/concurrency-ddj.htm
>> > The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software
>> > Herb Sutter
>> > March 2005
>> 
>> 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.
>
> Beware.  Multi-core and/or multi-threaded cpus are the only thing the
> high end CPU manufacturers are able to produce today that they can
> still claim to be "faster."  There is a HUGE incentive for them to
> create demand for their design lest it become irrelevant and they be
> forced to sell only low-margin commodity single core hardware.  This
> means we'll see a ton of papers and people paid or coerced into
> suggesting that this is the best thing since time sliced bread.

I'd imagine that the more interesting/easy to deal with concurrency
models can and will be implemented atop shared memory threads.  At
least, for the reasons you give, I hope so :)

Cheers,
mwh

-- 
  ZAPHOD:  OK, so ten out of ten for style, but minus several million
   for good thinking, eh?
-- The Hitch-Hikers Guide to the Galaxy, Episode 2
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding a conditional expression in Py3.0

[Gareth McCaughan]

> The reason I like "a if b else c" is because it has the
> most natural word order. In English,
>My dog is happy if he has a bone, else sad.
> sounds much more natural than
>My dog is, if he has a bone, happy, else sad.

Neither sounds very natural to me; conditional
expressions don't occur much in English. It's
much more common to hear something like

My dog is happy if he has a bone; otherwise he's sad.

And that would correspond to a postfix conditional
operator on *statements*, not expressions; Perl and
Ruby have this, but it doesn't seem very Pythonic.

> Interestingly, it looks *more* odd to me if parens are
> included:
> 
>return (self.arg if self.arg is not None else default)
> 
> I think this is because, without the parens, I tend to read
> the "if" as applying to the whole phrase "return self.arg",
> not just to the "self.arg".

Which is one reason why I *don't* like the proposed
"consequent if antecedent else alternative" syntax;
it looks like a statement modifier when it isn't
really one. When you're forced (by the parens) to
read it correctly, you stop liking it! :-)

*

Conditional expressions do occur in English, though,
and they do generally have the consequent at the front.
But ... they also generally have the "else-marker"
right at the end. "Buy some pork if it's going cheap,
and some beef if not." "You can divide an angle into
N equal parts with ruler and compasses if N is a power
of 2 times a product of distinct Fermat primes, but
not if N has any other form." "I sleep all night
and work all day."

I don't think a syntax that authentically mirrors
the structure of conditional expressions in English
is likely to be very good.

x = (123 if p==q; 321 otherwise)
x = (123 if p==q, else 321 if not)
x = (123 if p==q; else 321 if r==s; else 999 if not)

:-)

-- 
g

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Visibility scope for "for/while/if" statements

[Gareth McCaughan]

On Thursday 2005-09-22 20:00, Josiah Carlson wrote:

[Alexander Myodov:]
> > But for the "performance-oriented/human-friendliness" factor, Python
> > is anyway not a rival to C and similar lowlevellers. C has
> > pseudo-namespaces, though.
> 
> C does not have pseudo-namespaces or variable encapsulation in for loops.
> 
> Ah hah hah!  Look ladies and gentlemen, I caught myself a troll!  Python
> does not rival C in the performance/friendliness realm?  Who are you
> trying to kid?

I think you've misunderstood Alex here; he's saying that Python
and C don't occupy the same region of the spectrum that runs
from "high performance, human-unfriendly" to "lower performance,
human friendly". Which is correct, unlike some other things he's
said :-).

> > "for (int i = 0; i < 10; i++)" works fine nowadays.
> 
> I'm sorry, but you are wrong.  The C99 spec states that you must define
> the type of i before using it in the loop.  Maybe you are thinking of
> C++, which allows such things.

No, Alex is right on this one too. Maybe you are thinking of C89,
which forbids such things.

   6.8.5.3  The for statement

   [#1]  Except for the behavior of a continue statement in the
   loop body, the statement

   for ( clause-1 ; expr-2 ; expr-3 ) statement

   and the sequence of statements

   {
   clause-1 ;
   while ( expr-2 ) {
   statement
   expr-3 ;
   }
   }


   are equivalent (where clause-1 can be  an  expression  or  a
   declaration).123)
...
   123Thus,  clause-1  specifies  initialization  for the loop,
  possibly declaring one or more variables for use  in  the
  loop;  expr-2,  the  controlling expression, specifies an
  evaluation  made  before  each   iteration,   such   that
  execution  of  the  loop  continues  until the expression
  compares equal to 0; expr-3 specifies an operation  (such
  as  incrementing) that is performed after each iteration.
  If clause-1 is a  declaration,  then  the  scope  of  any
  variable  it declares is the remainder of the declaration
  and the entire loop, including the other two expressions.

(This is from a late draft of the C99 spec; I'm fairly sure
the final version is no different.)

-- 
g

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Visibility scope for "for/while/if" statements

[Andrew Koenig]

> Interestingly enough, not all C++ compilers (Microsoft) hid variables
> created in for loops
> (http://www.devx.com/cplus/10MinuteSolution/28908/0/page/2).

That's because the C++ spec changed during standardization, when the
standards committee realized the original idea was a mistake.

One of the convincing cases:

if (x)
for (int i = 0; i != 10; ++i) { }

Is I in scope after the if statement?  If so, what value does it have if x
is false?  If not, then apparently the subject of an "if" statement is a
scope...so why can't I write this?

if (x)
int i = 42;

and have i go out of scope?



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GIL, Python 3, and MP vs. UP

[Paul Moore]

On 9/21/05, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> >
> >
> > > The best way to make people stop complaining about the GIL and start
> > > using
> > > process-based multiprogramming is to provide solid, standardized support
> > > for process-based multiprogramming.
> >
> > 100% agreed. I needed a portable way to know if a program was already
> > running (and then to send it a simple command), the only simple solution
> > I found was to listen on a local TCP socket and store the port number in
> > a file in a known location. Not very elegant IMO.
>
> On *nix, use a unix domain socket (location in the filesystem which acts
> as a listening socket).  On Windows, you can use cTypes, pywin32, etc.,
> to create a global mutex and/or COM interface.

Yes, but that's the point - having a cross-platform solution available
"out of the box" (where the box may be the stdlib, or it may be third
party).

The problems I see are:

1. Encapsulating a suitable core feature set in a nice API
2. Making it cross-platform

With something covering both of these, a case could be made for
including it in the stdlib, to support/encourage multiprocess style
coding in place of multithreading.

I use threading quite a lot, often to spawn multiple workers all doing
"the same thing" on different targets. A simple thread pool plus
threading.Queue is perfect for this. A package which provided a
similar abstraction using worker processes would be fine for me. Of
course, *I* want it for Windows, and most multiprocess stuff tends to
be Unix specific (where multiprocessing is natural and fast). And I'm
happy enough with threads (I'm scaling up the number of blocking calls
I'm waiting on - which already release the GIL - and so I don't care
too much about SMP per se).

This is getting offtopic, though, and probably more suitable for
c.l.p, where design issues of a multiprocessing module should be
thrashed out before coming back to python-dev with a proposal for the
stdlib.

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding a conditional expression in Py3.0

[Paul Moore]

On 9/20/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> 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).

I agree that (expr if cond else expr) fits far more naturally these
days given the ordering of generator expressions (and list
comprehensions, but they were around when PEP 308 was discussed, so I
don't think they work as well as evidence :-)) Also, (expr if cond
else expr) doesn't naturally admit an elif case, reducing complexity
(and the tendency to overuse the construct in complex ways) a little.
And it doesn't need a new keyword.

I have a vague fondness for this form. I really can't express it very
well, but the if-then-else version just feels a little too "boring and
conventional". I'm sure people will get used to it (heck, we've got
decorators and print >> :-)) but maybe pushing a (mildly)
idiosyncratic form isn't worth opening that can of worms again.

I'm +1 on a conditiona expression. I suspect the time is now right.

I'm +1 on *one* of

(expr if cond else expr)
or
(if cond then expr else expr)

With the latter, I don't mind if elif is added or not.

I'm +10 on Guido just making the decision. No more votes, please!

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding a conditional expression in Py3.0

[Josiah Carlson]

Gareth McCaughan <[EMAIL PROTECTED]> wrote:
[seems to have gone off list with a portion of the discussion]
> > The reason I like "a if b else c" is because it has the
> > most natural word order. In English,
> >My dog is happy if he has a bone, else sad.
> > sounds much more natural than
> >My dog is, if he has a bone, happy, else sad.
> 
> Neither sounds very natural to me; conditional
> expressions don't occur much in English. It's
> much more common to hear something like
> 
> My dog is happy if he has a bone; otherwise he's sad.


Natural english wise, this also sounds natural:

If my dog has a bone he's happy, otherwise he's sad.


But yeah, I'll use them regardless of the syntax, even if I have
preferences.

 - Josiah

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Compressing MSI files: 2.4.2 candidate?

[Martin v. Löwis]

Vincent Wehren wrote:
> The LZX:21-compressed package worked absolutely fine for me (Windows XP
> Professional Build 2600.xpsp_sp2_gdr).

Thanks for all the confirmations; I'm going to use it then for 2.4.2.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding a conditional expression in Py3.0

[Terry Reedy]

>> Need I continue?  Or is the dead still dead?

Since 'a if b else c' is not obviously dead, I will summarize my argument 
against it thusly:

It is ambiguous to people because it is can be parsed (by people, who are 
not automatons) as either '(a if) b (else c)' or 'a (if b) (else c)'.  The 
first parsing, seeing a as the conditional rather than the consequent, as 
in the the second, is at least as reasonable as the second given precedents 
in both other algorithm languages and natural languages (in English, at 
least, but I suspect others also).

Ambiguity sometimes leads to discomfort.  As important, it sometimes leads 
to bugs either in writing or reading.  The impetus for this discussion was 
a real-life buggy example of the and/or construct.   Its replacement should 
be something not similarly bug-prone, even if for a different reason.

Terry J. Reedy



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding a conditional expression in Py3.0

[Terry Reedy]

"Jim Jewett" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

A nice summary, to which I will add just a little.

> For a conditional expression, I think the choices are really down
> to the following, which was already way too much freedom last
> (http://www.python.org/peps/pep-0308.html) time:
>
> (1)  Should it be done at all?
>+  It would be useful, and avoid certain types of bugs.
>-  It would encourage bracketing instead of indentation
>
> PEP 308 decided "not yet, anyhow"
>
> (2)  How many of the keywords (if ... then ... else ... elif) should be 
> dropped?
>(if test then True else False)
>+ standard english
>+ standard programming idiom
>- adds a "then" keyword
>(if test True else False)
>+ better parallels the if: statement
>- starts to run together

I think the first form with 'then' better parallels the 'if  :' 
statement because 'then' functions as a separator between test and True 
just as ':' or ':\n' functions as a separator between  and .

>(if test1 Val1 elif test2 Val2 elif test3 Val3)
>+ parallels the if: statement
>- encourages overly long code
>* but still better than nested parens
>
> PEP 308 wasn't entirely clear; the words said to keep "elif", but
> the examples did not.  There was some disagreement on which
> of the other three keywords to represent explicitly.  (Rather than
> only by position.)
>
> (3)  What order should the clauses appear?
>(if test then True else False)
>(if test1 then Val1 elif test2 Val2 elif test3 Val3 else Val4)
>+ Natural Order
>- do we need "then"?
>(True if normal else False)
>(Val1 if test1 else Val2 if test2 else Val3 if test3 else Val4)
>+ Best order for normal/default conditionals
>+ Best order in general if we weren't used to left-right 
> processing

I an far from convinced on either of these, perhaps because I am not sure 
about the actual claim.

>- But we *do* expect left->right almost everywhere except 
> assignments

  - Ambiguous.

When expressions a and b both lack boolean operators, as is common in 
Python given that all objects have a boolean value, a if b else c is 
mentally parseable as either (a if) b (else c) or a (if b) (else c).  I 
initially though the proposal intended the first.

 -- Bug prone.  The left->right expectation leads to the wrong 
parsing.

Hence we may expect occasional bugs both in writing and reading this 
construct.

> PEP 308 made it clear that "else" should be last.  Putting the condition
> before the "then" was not as clearcut.
>
> (4)  What sort of punctuation should augment or replace the keywords?
>
> PEP 308 suggested avoiding punctuation, but it wasn't clearcut.

Terry J. Reedy



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Visibility scope for "for/while/if" statements

[Nick Coghlan]

Andrew Koenig wrote:
>>Interestingly enough, not all C++ compilers (Microsoft) hid variables
>>created in for loops
>>(http://www.devx.com/cplus/10MinuteSolution/28908/0/page/2).
> 
> 
> That's because the C++ spec changed during standardization, when the
> standards committee realized the original idea was a mistake.
> 
> One of the convincing cases:
> 
>   if (x)
>   for (int i = 0; i != 10; ++i) { }
> 
> Is I in scope after the if statement?  If so, what value does it have if x
> is false?  If not, then apparently the subject of an "if" statement is a
> scope...so why can't I write this?
> 
>   if (x)
>   int i = 42;
> 
> and have i go out of scope?

The difference is that C++ uses {} to delineate a new scope, whereas Python 
uses only def statements.

The behaviour in C++ and C99 can indeed be quite handy, and aligns perfectly 
with the static type system of those languages. Importantly, creating a new 
scope is cheap - it's just a matter of moving the stack pointer around a bit 
(and maybe invoking some destructors that would have been invoked eventually 
anyway).

Python, however, uses a dynamic name binding system and scopes are expensive 
because they require setting up all of the machinery to support nested 
visibility. That is, additional inline scoping would add significant *runtime* 
overhead. So a different design choice was made in Python, but that choice is 
still internally consistent.

Using the above example:

 if x:
 for i in range(10): pass
 print i

 if x:
 i = 42
 print i

What happens on the 'print i' line in Python if 'x' is false? Easy: attempting 
to access 'i' will result in "UnboundLocalError" being raised at runtime, just 
as it would if the 'print i' line was *before* the if statement. That's 
because the name 'i' *is* in scope - it just hasn't been bound to anything yet.

As Guido has said, this is really a discussion for c.l.p. Even before taking 
it there, however, I suggest reviewing the c.l.p discussion from January 
regarding the idea of 'statement local namespaces' [1] (and also checking the 
archives to see if the discussion has moved on since then, as I haven't been 
following c.l.p. for a good long while).

Regards,
Nick.

[1] http://mail.python.org/pipermail/python-list/2005-January/259556.html

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://boredomandlaziness.blogspot.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Visibility scope for "for/while/if" statements

[Greg Ewing]

Nick Coghlan wrote:

> Python, however, uses a dynamic name binding system and scopes are expensive 
> because they require setting up all of the machinery to support nested 
> visibility.

Scopes within a function needn't be anywhere near as expensive
as scopes for nested functions are. The compiler can just
allocate all the locals that are going to be needed on
entry to the function, and keep track of which ones are
visible.

The only runtime overhead would be unbinding locals as they
go out of scope, if that were considered necessary or desirable.

The main problem is Python's lack of declarations, which
means that nested locals could only be used in places
where it's clear that a new variable is being introduced,
such as for loops, LCs, etc.

Greg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding a conditional expression in Py3.0

[Terry Reedy]

"Greg Ewing" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Terry Reedy wrote:
>
>> Many people, perhaps most, including me, read
>>
>> exp1 if exp2 else exp3 # as
>> cond if etrue else efalse # in direct analogy with
>> cond ?  etrue : efalse # from C
>
> I'd have thought only Forth programmers would be prone to that!

Never wrote a single line, and may have not read one (in DDJ? Byte?) for 
15-20 years.  How do *you* read such C?  Cond 'Qmark' ?

> It would surprise me greatly if it's really true that *most*
> people would read it that way.

OK.  I withdraw 'possibly most' as not directly relevant.  It would not 
take that many people to have enough people mistakenly write or read it 
that way for this construct to be somewhat as bug prone, in practice, as 
and/or.

During the c.l.p debate, someone counted about 100 correct uses of 'a and b 
or c' in the standard library.  But one real misuse edged Guido toward 
replacing it.  So I think the replacement should be as clear as reasonably 
possible and clearly an improvement.

> Especially given that, in real
> code, you're not going to be looking at abstract names like
> exp1, exp2, exp3, but (hopefully) something a lot more
> meaningful.

Because every object in *Python* (ignoring buggy or unusual __nonzero__ 
methods) has a boolean value, any expression can be a conditional 
expression and hence conditional expressions often lack a boolean operator 
to flag the expression as the likely conditional.

> Can you honestly say that you would read

Given that setup, how could I possible misread :-?

>   return red_value if color == 'red' else blue_value
> as
>   if red_value:
> return color == 'red'
>   else:
> return blue_value
> ?

I can imagine that if I were to read the return naively, I might wonder 
whether the expressions were reversed.  And certainly, not all code I have 
read has had such obvious names.

Now, can you honestly say that you would (naively) read

  return foo if bar else baz

and be certain you knew what it meant?

Terry J. Reedy



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding a conditional expression in Py3.0

[Nick Coghlan]

Terry Reedy wrote:
> During the c.l.p debate, someone counted about 100 correct uses of 'a and b 
> or c' in the standard library.  But one real misuse edged Guido toward 
> replacing it.  So I think the replacement should be as clear as reasonably 
> possible and clearly an improvement.

But I think there's a difference in kind here - to *fix* Raymond's example 
required a fundamental change to the structure of the line, none of which 
looked as clean as the original. There is no way to get the and/or construct 
to gracefully handle the case where the desired result in the 'true' case 
might itself be false: either you change to using an if statement, or you use 
a workaround like the ugly singleton-list approach.

That is, the following is fundamentally broken for pure imaginary numbers:
   return isinstance(z, ComplexType) and z.real or z

Fixing it requires changing to either:
   return (isinstance(z, ComplexType) and [z.real] or [z])[0]

or:
   if isinstance(z, ComplexType)
   return z.real
   else:
   return z

This is not the case with an in-fix notation for conditional expressions - you 
can fix a broken line simply by moving the relevant expressions to the correct 
locations.

   return isinstance(z, ComplexType) if z.real else z # Broken!
   return z.real if isinstance(z, ComplexType) else z # Correct!

I see this as being in the same category of error as writing "return foo ** 
baz" when you really should have written "return baz ** foo" (i.e., not the 
language's problem). (Random aside: it would be nice if "foo ** bar % baz" 
automatically invoked the three argument form of 'pow')

> Now, can you honestly say that you would (naively) read
> 
>   return foo if bar else baz
> 
> and be certain you knew what it meant?

Yes. I'd expect it to read like English - "Return foo if bar is true, 
otherwise return baz". Whether that was was what code was *supposed* to be 
doing, I couldn't assess without additional context (but that is true 
regardless of the syntax).

With the prefix notation used for C's conditional operator, I simply don't 
read it in the order it's written - I read "return bar ? foo : baz" as "if bar 
is true then return foo, otherwise return baz". That's possible with C because 
it uses punctuation - using an English keyword instead makes it significantly 
harder for me to consider interpreting the construct that way (In fact, the 
only way I can get my brain to accept it is by mentally replacing the "if" 
with "?" and the "else" with ":").

Does it help if you think of "if  else" as a parameterised infix operation 
for choosing between the expressions on either side?

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://boredomandlaziness.blogspot.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding a conditional expression in Py3.0

[Michael Urman]

On 9/23/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> But I think there's a difference in kind here - to *fix* Raymond's example
> required a fundamental change to the structure of the line, none of which
> looked as clean as the original. There is no way to get the and/or construct
> to gracefully handle the case where the desired result in the 'true' case
> might itself be false: either you change to using an if statement, or you use
> a workaround like the ugly singleton-list approach.
>
> That is, the following is fundamentally broken for pure imaginary numbers:
>return isinstance(z, ComplexType) and z.real or z

It's hard to say whether this fixes Raymond's example when the goal
wasn't clearly stated, but I find a non ternary option

lambda z: complex(z).real

more readable than any of the variants proposed so far. The obvious
downsides are that it can raise a ValueError, and turns integers into
floats. But if the input list is all numeric, it has clean results.

--
Michael Urman
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding a conditional expression in Py3.0

[Terry Reedy]

"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]



I am reminded of how some people seem to react to fingernails on a 
blackboard, while the screech is just another noise to me, except that I am 
in the opposite position with respect to a if b else c.

> Does it help if you think of "if  else" as a parameterised infix 
> operation
> for choosing between the expressions on either side?

Hmm.  If I parse it as a (if b else) c and sort of ignore the words and 
think of it as  so that the whole thing is a switch pointing either 
left or right?  A bit strange, but perhaps it does.

Terry J. Reedy



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com