Guido van Rossum wrote:
> [Guido]
>
>>>Let me give you what you expect. If all the "X if C else Y" syntax
>>>does is prevent that atrocity from ever being introduced, it would be
>>>worth it. :)
>
>
> [Steve]
>
>>Well, fine. However, it does allow atrocities like
>>
>>func(f for f in lst if f >
On 9/29/05, Evan Jones <[EMAIL PROTECTED]> wrote:
>
> Any chance that someone wants to commit this tiny two line fix?
That's reallly not the question you *want* to be asking. :-)
> This might be the kind of fix that might be elegible to be backported to
> Python 2.4 as well. It passes "make test
Patch / Bug Summary
___
Patches : 337 open ( +0) / 2947 closed ( +6) / 3284 total ( +6)
Bugs: 912 open ( +4) / 5278 closed (+16) / 6190 total (+20)
RFE : 195 open ( +1) / 187 closed ( +0) / 382 total ( +1)
New / Reopened Patches
__
fix for d
Guido van Rossum wrote:
...
> Flames, pleas to reconsider, etc., to /dev/null.
>
> Congratulations gracefully accepted.
Congratulations for a clear decision!
Personally, I would have preferred a "no, never in my life"
alternative response slightly more, but a clear say is better than
endless d
Guido van Rossum wrote:
> Congratulations gracefully accepted.
Whilst I'm not personally fond of the syntax, congratulations. Whilst I
don't feel this is a big step in the evolution of the language, it shuts
up a *very* frequently asked question (and opens up a new one ;)
Tim Delaney
___
On 9/29/05, Guido van Rossum wrote:
> After a long discussion I've decided to add a shortcut conditional
> expression to Python 2.5.
>
> The syntax will be
>
> A if C else B
>
[snip]
>
> Congratulations gracefully accepted.
Congratulations, and many thanks for making this decision before the
t
> How about this:
> Can someone update the PEP on conditional expressions to point to
> this email and update the status, etc?
Already done.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
On 9/29/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> Flames, pleas to reconsider, etc., to /dev/null.
>
> Congratulations gracefully accepted.
>
> It's still my language! :-)
I don't like those options. :-)
How about this:
Can someone update the PEP on conditional expressions to point to
After a long discussion I've decided to add a shortcut conditional
expression to Python 2.5.
The syntax will be
A if C else B
This first evaluates C; if it is true, A is evaluated to give the
result, otherwise, B is evaluated to give the result.
The priorities will be such that you can writ
Nick Coghlan wrote:
> i.e., it's
> like an "or", only we're asking that the decision be made based on something
> other than the truth value of the left hand operand.
Hmmm, then maybe it should be
a or c if b
or perhaps
a or, if b, c
:-)
--
Greg Ewing, Computer Science Dept, +--
The following Python script causes Python 2.3, 2.4 and the latest CVS
to crash with a Segmentation Fault:
import xml.dom.minidom
x = u'\nComment \xe7a va ? Tr\xe8s
bien ?'
dom = xml.dom.minidom.parseString( x.encode( 'latin_1' ) )
print repr( dom.childNodes[0].localName )
The problem is that
[Guido]
> > Let me give you what you expect. If all the "X if C else Y" syntax
> > does is prevent that atrocity from ever being introduced, it would be
> > worth it. :)
[Steve]
> Well, fine. However, it does allow atrocities like
>
> func(f for f in lst if f > -1 if f < 0 else +1)
No it doesn't!
Bruce Eckel wrote:
> 3) Tasks are cheap enough that I can make
> thousands of them, ...
> 4) Tasks are "self-guarding," so they prevent
> other tasks from interfering with them. The
> only way tasks can communicate with each
> other is through some kind of formal
> mechanism (something queue-ish,
Micah Elliott <[EMAIL PROTECTED]> wrote:
> Josiah> an unofficial spec is sufficient. See koders.com and search
> Josiah> for 'fixme' to see some common variants.
>
> But that's the problem -- there are already a bunch of "unofficial"
> specs, which don't serve much purpose as such. It's a cool
http://yro.slashdot.org/yro/05/09/28/1955256.shtml?tid=103&tid=17&tid=219
Congratulations David! (Don't have his email.)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
Guido van Rossum wrote:
> On 9/29/05, Steve Holden <[EMAIL PROTECTED]> wrote:
>
>>I would argue for mandatory parentheses around the expression, leaving
>>room later (probably after Guido is no longer around to be sick at the
>>site of it) for:
>>
>>def f(condition):
>> return something if con
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> After all there's nothing wrong with and/or.
This is one reason 'no addition' got a relatively high rank in the vote.
Examples...
> telnet~1.py:'DO' if cmd == DO else 'DONT',
versuscmd =
Fredrik Lundh wrote:
> M.-A. Lemburg wrote:
>
>
>>* Unicode variant (UCS2, UCS4)
>
>
> don't forget the "Py_UNICODE is wchar_t" subvariant.
True, but that's not relevant for binary compatibility of
Python package (at least not AFAIK).
UCS2 vs. UCS4 matters because the two versions use and exp
Bob Ippolito wrote:
> On Sep 29, 2005, at 3:53 PM, M.-A. Lemburg wrote:
>
>
>>Perhaps a flag that fires up Python and runs platform.py
>>would help too.
>
>
> python -mplatform
Cool :-)
Now we only need to add some more information to it (like e.g.
the Unicode variant).
--
Marc-Andre Lembur
[ongoing discussion of conditional expressions]
I waited until I had caught up on my reading before saying anything. Now I'll
express my opinion in a single posting then keep quiet unless I actually find I
have something novel to contribute (difficult in a topic that's been talked to
death 3 or 4
Guido van Rossum wrote:
> I did this for my favorite proposal, and ended up with the list shown
> further down below.
>
> I think they all looks great!
I'm sorry for my bad English
IMHO, if condition is nontrivial, then the syntax:
expr1 if some complex condition else expr2
can be more ha
M.-A. Lemburg wrote:
> * Unicode variant (UCS2, UCS4)
don't forget the "Py_UNICODE is wchar_t" subvariant.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/ma
On Sep 29, 2005, at 3:53 PM, M.-A. Lemburg wrote:
> Perhaps a flag that fires up Python and runs platform.py
> would help too.
python -mplatform
-bob
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
> I'd like to restart this discussion; I didn't mean to put forth active
> objects as "the" solution, only that it seems to be one of the better,
> more OO solutions that I've seen so far.
Thanks for doing this. I think this is an issue that is going to be
more and more important as Python conti
Steven Bethard wrote:
> On 9/29/05, Robey Pointer <[EMAIL PROTECTED]> wrote:
>
>>Yesterday I ran into a bug in the C API docs. The top of this page:
>>
>> http://docs.python.org/api/unicodeObjects.html
>>
>>says:
>>
>>Py_UNICODE
>> This type represents a 16-bit unsigned storage type which
Bruce Eckel wrote:
> I'd like to restart this discussion; I didn't mean to put forth active
> objects as "the" solution, only that it seems to be one of the better,
> more OO solutions that I've seen so far.
>
> What I'd really like to figure out is the "pythonic" solution for
> concurrency. Guido
On 9/29/05, Robey Pointer <[EMAIL PROTECTED]> wrote:
> Yesterday I ran into a bug in the C API docs. The top of this page:
>
> http://docs.python.org/api/unicodeObjects.html
>
> says:
>
> Py_UNICODE
> This type represents a 16-bit unsigned storage type which is
> used by Python internall
Yesterday I ran into a bug in the C API docs. The top of this page:
http://docs.python.org/api/unicodeObjects.html
says:
Py_UNICODE
This type represents a 16-bit unsigned storage type which is
used by Python internally as basis for holding Unicode ordinals. On
platforms where wcha
Michael Hudson wrote:
> Bruce Eckel <[EMAIL PROTECTED]> writes:
>
>
>>I'd like to restart this discussion; I didn't mean to put forth active
>>objects as "the" solution, only that it seems to be one of the better,
>>more OO solutions that I've seen so far.
>>
>>What I'd really like to figure out
> > It only takes about five minutes to try out a given syntax proposal
on
> > all the fragments listed below. That short exercise provides an
> > excellent insight into the look and feel of each proposal in real
world
> > code.
>
> I did this for my favorite proposal, and ended up with the list
"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
> At 09:30 AM 9/29/2005 -0600, Bruce Eckel wrote:
>>This paper looks very interesting and promises some good ideas. It
>>also looks like it will require time and effort to digest.
>>
>>I've only read the first few pages, but one thing that does leap out
At 10:48 AM 9/29/2005 -0600, Bruce Eckel wrote:
>I haven't spent the weekends on the paper yet (but it looks like that
>is what it would take), but I had the impression that they were
>talking about the lock-free techniques such as the ones used in Java
>5. Basically, you start a write operation "i
> 1) It works by default, so that novices can use it without falling
> into the deep well of threading. That is, a program that you write
> using threading is broken by default, and the tool you have to fix it
> is "inspection." I want something that allows me to say "this is a
> task. Go." and hav
On 9/29/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> My point about the lack of motivation was that there was little reason
> shown why this should be a PEP instead of either:
>
> 1. Documentation for a specific tool, or group of tools
> 2. A specific project's process documentation
That's what
> I spent a few weekends studying that paper earlier this year in order to
> see if anything could be stolen for Python; my general impression was "not
> easily" at the least. One notable feature of the presented concept was
> that when code would otherwise block, they *rolled it back* to the last
On 9/29/05, Steve Holden <[EMAIL PROTECTED]> wrote:
> I would argue for mandatory parentheses around the expression, leaving
> room later (probably after Guido is no longer around to be sick at the
> site of it) for:
>
> def f(condition):
> return something if condition # no else!
> retur
At 12:14 PM 9/29/2005 -0400, Viren Shah wrote:
> File "/root/svn-install-apps/setuptools-0.6a4/pkg_resources.py", line
> 949, in _get
> return self.loader.get_data(path)
>OverflowError: signed integer is greater than maximum
Interesting. That looks like it might be a bug in the Python zipi
Antoine Pitrou wrote:
>>The only problem is that it's not easy to come up with a regex-based
>>way to transform
>>
>>C and X or Y
>>
>>into
>>
>>X if C else Y
One way is to parse it manually to a list. This was just a test, but
more samples can be added friarly easy.
samples = [
#
At 09:30 AM 9/29/2005 -0600, Bruce Eckel wrote:
>This paper looks very interesting and promises some good ideas. It
>also looks like it will require time and effort to digest.
>
>I've only read the first few pages, but one thing that does leap out
>is at the beginning of section 3, they say:
>
>"..
At 09:10 AM 9/28/2005 -0700, Micah Elliott wrote:
>I agree that proof of value is necessary. Without a spec though it
>will be hard to get people to know about a convention/toolset, so it's
>a bit of a chicken-egg problem -- I can't have a pep until the tools are
>in use, but the tools won't be us
Guido van Rossum wrote:
> On 9/29/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
>>FWIW, I scanned the standard library for all the and/or pairings where a
>>conditional expression was applicable. This sampling can serve as a
>>reference for what "typical" uses would look like in real Python
Guido van Rossum wrote:
file = os.path.abspath(file) if file else '?'
...
These are all unreadable. In C "a ? b : c" is not used very often. A
quick check of the Python source found 476 occurences.
-1 to conditional expressions.
___
Python-Dev mailing
FWIW, the Perl 6 community is also investigating STM, so it appears to
be a worthwhile idea for an impure, multi-paradigm language as well.
Regards,
Michael
On 9/29/05, Bruce Eckel <[EMAIL PROTECTED]> wrote:
> This paper looks very interesting and promises some good ideas. It
> also looks like it
At 09:49 AM 9/29/2005 -0400, Viren Shah wrote:
>[I sent this earlier without being a subscriber and it was sent to the
>moderation queue so I'm resending it after subscribing]
>
>Hi,
> I'm running a 64-bit Fedora Core 3 with python 2.3.4. I'm trying to
> install setuptools to use with Trac, and
Antoine Pitrou wrote:
> This is especially true if the "X" in "X if C else Y" happens to be a
> non-trivial expression - witness your example from unittest.py:
> return doc.split("\n")[0].strip() if doc else None
>
> ... because then the condition (which is the most important part of the
>
This paper looks very interesting and promises some good ideas. It
also looks like it will require time and effort to digest.
I've only read the first few pages, but one thing that does leap out
is at the beginning of section 3, they say:
"... a purely-declarative language is a perfect setting fo
Raymond Hettinger wrote:
> [Aahz]
>
>>I'm also opposed to elif in conditional expressions -- let's keep this
>
> a
>
>>simple Pythonic rewrite of C's ternary.
>>
>>I'm +0 on requiring parentheses precisely because they're annoying.
>
> I'm
>
>>still expecting simple boolean expressions to be t
Guido> After all there's nothing wrong with and/or.
Especially if it's correct.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-de
> The only problem is that it's not easy to come up with a regex-based
> way to transform
>
> C and X or Y
>
> into
>
> X if C else Y
(my 2 cents)
I find this proposal very confusing. The order is not logical at all.
One usually expects to find the condition on one side, and the
alter
Guido van Rossum wrote:
> I think they all looks great!
expression if expression?
looks like you've been doing too much Perl hacking lately ;-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
U
On 9/29/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
[a garbled list]
Stupid gmail broke the lines. Here it is again as an attachment.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
XifCelseY.py
Description: application/python
___
On 9/29/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> FWIW, I scanned the standard library for all the and/or pairings where a
> conditional expression was applicable. This sampling can serve as a
> reference for what "typical" uses would look like in real Python code as
> created by a number
Bruce Eckel <[EMAIL PROTECTED]> writes:
> I'd like to restart this discussion; I didn't mean to put forth active
> objects as "the" solution, only that it seems to be one of the better,
> more OO solutions that I've seen so far.
>
> What I'd really like to figure out is the "pythonic" solution for
I'd like to restart this discussion; I didn't mean to put forth active
objects as "the" solution, only that it seems to be one of the better,
more OO solutions that I've seen so far.
What I'd really like to figure out is the "pythonic" solution for
concurrency. Guido and I got as far as agreeing t
Done :)
I summarized my point of view and I'm waiting for comments :)
Pierre
Aahz a écrit :
> On Thu, Sep 29, 2005, Pierre Barbier de Reuille wrote:
>
>>Ok, so I took a closer look at the documentation and tried a few things
>>to understand better what you said and I have some remark ...
>
>
On Thu, Sep 29, 2005, Pierre Barbier de Reuille wrote:
>
> Ok, so I took a closer look at the documentation and tried a few things
> to understand better what you said and I have some remark ...
I've got some counter-remarks, but python-dev is not the place to
discuss them. Please move this threa
[Aahz]
> I'm also opposed to elif in conditional expressions -- let's keep this
a
> simple Pythonic rewrite of C's ternary.
>
> I'm +0 on requiring parentheses precisely because they're annoying.
I'm
> still expecting simple boolean expressions to be the primary use case,
> and my hunch is that ov
On Wed, Sep 21, 2005, Nick Coghlan wrote:
> 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
Bob Ippolito wrote:
> /usr/bin/sw_vers technically calls a private (at least undocumented)
> CoreFoundation API, it doesn't parse that plist directly :)
>
> On further inspection, it looks like parsing the plist directly is
> supported API these days (see the bottom of developer.apple.com/doc
Thanks to all who have read and/or provided feedback. There have been
some great ideas and admonitions that hadn't crossed my mind. I'll
paraphrase some of the responses for the sake of brevity; I don't mean
to misquote anyone.
Tom> ISO 8601 includes a week notation.
That's great. Thanks for p
Guido van Rossum wrote:
> On 9/28/05, Jim Fulton <[EMAIL PROTECTED]> wrote:
>
...
> I think we need to be real careful with chosing a name -- in Jim's
> example, *anyone* could assign to Spam().eggs to override the value.
> The name "readproperty" is too close to "readonlyproperty",
In fact, prop
61 matches
Mail list logo
