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 ...
Phillip J. Eby a ecrit :
At 06:15 PM 9/28/2005 +0200, Pierre Barbier de Reuille wrote:
Regularly, you see questions about augmented assignment on Python-tutor
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, property
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
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 http://
On Wed, Sep 21, 2005, Nick Coghlan wrote:
Steven Bethard wrote:
Guido van Rossum wrote:
I think I'd prefer (if expr then expr else expre) i.e. no
colons. None of the other expression forms (list comprehensions and
generator expressions) involving statement keywords use colons.
FWIW, I find
[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 overall
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 thread
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 ...
I've
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 that
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
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 of
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
___
Guido van Rossum wrote:
I think they all looks great!
expression if expression?
looks like you've been doing too much Perl hacking lately ;-)
/F
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
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
alternatives
Guido After all there's nothing wrong with and/or.
Especially if it's correct. wink
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
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 the primary use
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
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
statement)
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 get
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
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
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 code as
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 used
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:
... a
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 = [
# start, cond,
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 zipimport
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!
return
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, 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
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 have it
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 in
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
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 internally as basis
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 and I
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 is
used by Python
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 continues
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
M.-A. Lemburg wrote:
* Unicode variant (UCS2, UCS4)
don't forget the Py_UNICODE is wchar_t subvariant.
/F
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
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 hard
[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
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 Lemburg
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 expose
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 == DO
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 condition # no
http://yro.slashdot.org/yro/05/09/28/1955256.shtml?tid=103tid=17tid=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
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 site. I
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,
I'd
[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! Inside an
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'?xml version=1.0?\nfran\xe7aisComment \xe7a va ? Tr\xe8s
bien ?/fran\xe7ais'
dom = xml.dom.minidom.parseString( x.encode( 'latin_1' ) )
print repr(
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,
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
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 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
threads
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
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
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
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 on
57 matches
Mail list logo
