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 -1 if f 0 else +1)
Josiah Carlson wrote:
Further, even if it becomes a spec, it doesn't guarantee implementation
in Python editors (for which you are shooting for). Take a wander
through current implementations of code tags in various editors to get a
feel for what they support. I've read various posts about
Guido van Rossum wrote:
Congratulations gracefully accepted.
Hurrah!
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.blogspot.com
On Fri, Sep 30, 2005 at 09:17:39AM +0200, Thomas Heller wrote:
On several occasions I have seen tracebacks in my code pointing to PIL's
__init__.py file. That is strange, because I have installed PIL but it
is used nowhere.
[skip]
The bug is present in 2.3, 2.4, and current CVS.
I have
(C) That scheduler is non-preemptive. A single
greedy generator can starve all the others.
Instead of looking at this as a problem, you could look at it as a
feature. Since generators can't be switched at arbitrary places, the
programmer has to define his/her synchronization points
Oleg Broytmann [EMAIL PROTECTED] writes:
On Fri, Sep 30, 2005 at 09:17:39AM +0200, Thomas Heller wrote:
On several occasions I have seen tracebacks in my code pointing to PIL's
__init__.py file. That is strange, because I have installed PIL but it
is used nowhere.
[skip]
The bug is present
On 9/30/05, Jim Jewett [EMAIL PROTECTED] wrote:
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
On 9/30/05, Guido van Rossum [EMAIL PROTECTED] wrote:
Flames, pleas to reconsider, etc., to /dev/null.
No flames from here.
Congratulations gracefully accepted.
Consider them supplied. For both your patience, and for supplying the
decision we all desperately needed.
It's still my language!
On Thu, 2005-09-29 at 21:21, Guido van Rossum wrote:
Flames, pleas to reconsider, etc., to /dev/null.
Congratulations gracefully accepted.
It's still my language! :-)
Congratulations! May this be as successful a syntax addition as
decorators and print (of which I'm a fan too! :).
-Barry
(C) That scheduler is non-preemptive. A single greedy generator can
starve all the others.
Antoine Instead of looking at this as a problem, you could look at it
Antoine as a feature.
Apple looked at it as a feature for years. Not anymore. wink
Skip
Support for multiple interpreters already existsfrom the C API
(mod_python, Java Embedded Python a few other add-ons use them)
But:
- it's not possible to createnew interpreter instancesfrom within Python.
- there's no mechanism for passing information between interpreters.
-interaction
Le vendredi 30 septembre 2005 à 08:32 -0500, [EMAIL PROTECTED] a écrit :
(C) That scheduler is non-preemptive. A single greedy generator can
starve all the others.
Antoine Instead of looking at this as a problem, you could look at it
Antoine as a feature.
Apple
On 9/30/05, Nick Coghlan [EMAIL PROTECTED] wrote:
An approach to this area that would make sense to me is:
1. Defer PEP 350
2. Publish a simple Python module for finding and processing code tags in a
configurable fashion
3. Include a default configuration in the module that provides the
Barry Warsaw wrote:
On Thu, 2005-09-29 at 21:21, Guido van Rossum wrote:
Flames, pleas to reconsider, etc., to /dev/null.
Congratulations gracefully accepted.
It's still my language! :-)
Congratulations! May this be as successful a syntax addition as
decorators and print (of which
On 9/30/05, Thomas Heller [EMAIL PROTECTED] wrote:
On several occasions I have seen tracebacks in my code pointing to PIL's
__init__.py file. That is strange, because I have installed PIL but it
is used nowhere.
Finally I traced it down to a problem in the linecache code, which tries
to be
On 9/30/05, Antoine Pitrou [EMAIL PROTECTED] wrote:
(C) That scheduler is non-preemptive. A single
greedy generator can starve all the others.
Instead of looking at this as a problem, you could look at it as a
feature. Since generators can't be switched at arbitrary places, the
On 9/30/05, Antoine Pitrou [EMAIL PROTECTED] wrote:
Le vendredi 30 septembre 2005 à 08:32 -0500, [EMAIL PROTECTED] a écrit :
(C) That scheduler is non-preemptive. A single greedy generator can
starve all the others.
Antoine Instead of looking at this as a problem, you
[Guido]
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
...
The priorities will be such that you can write
...
x = A if C else B if D else E
I assume this groups as
A if C else (B if D else E)
Guido van Rossum [EMAIL PROTECTED] writes:
On 9/30/05, Thomas Heller [EMAIL PROTECTED] wrote:
On several occasions I have seen tracebacks in my code pointing to PIL's
__init__.py file. That is strange, because I have installed PIL but it
is used nowhere.
Finally I traced it down to a
I did this for my favorite proposal, and ended up with the list shown
further down below.
I think they all looks great!
The fact that so few were found in whole of the standard library does
put the use case into question, though, no? Though I am sure more could
be found with a more
Hi,
I've never heard
someone complain that the GIL is in the way for these types of apps.
I've never said so either.
I was just saying that it can be useful to mix cooperative threading and
preemptive threading in the same app, i.e. have different domains of
cooperative threading which are
Python doesn't worry about a precise boolean object, it
distinguishes between something and nothing.
Is there anything left? is a pretty good analogy for iterators.
It isn't always cheaply available, and having might
encourage poor style -- so iterators are going back
to the default for
On 9/30/05, Jeremy Maxfield [EMAIL PROTECTED] wrote:
Support for multiple interpreters already exists from the C API
(mod_python, Java Embedded Python a few other add-ons use them)
I'm aware of that (didn't I mention it in my message - sorry).
But:
- it's not possible to create new
On 9/29/05, Robey Pointer robey at lag.net 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
Guido:
Now you've pushed me over the edge. I've made up my mind
now, X if C else Y it will be. I hope to find time to
implement it in Python 2.5.
Steve Holden:
Not before time, either. If this ends the discussion then
I'll consider I've done everyone a favour. Sometimes no
decision is
On 9/30/05, Jim Jewett [EMAIL PROTECTED] wrote:
If I submit a documentation patch, should I say that
numbers, lists, strings, dictionaries, and tuples are
a special case, or should I just warn that some
container-like objects (including iterators) are always
True?
You seem to be going at
On Fri, 30 Sep 2005 17:26:27 +0200, Antoine Pitrou [EMAIL PROTECTED] wrote:
Hi,
I've never heard
someone complain that the GIL is in the way for these types of apps.
I've never said so either.
I was just saying that it can be useful to mix cooperative threading and
preemptive threading in the
Jim Jewett writes:
Python doesn't worry about a precise boolean object, it
distinguishes between something and nothing.
Is there anything left? is a pretty good analogy for iterators.
[...]
A Queue.Queue is always true. Should I submit a bug patch
I would have phrased this very
[Guido van Rossum]
__len__ is for sequences and mappings specifically -- everything that
supports __getitem__ should have __len__ and everything that has
__len__ should have __getitem__.
That's going a bit far. Unordered collections (like sets and bags) are
a good counter-example.
Raymond
Guido van Rossum wrote:
Containerish behavior isn't enough to warrant empty -- false; in
some sense every object is a container (at least every object with a
__dict__ attribute) and you sure don't want to map __len__ to
self.__dict__.__len__...
the ElementTree experience shows that doing
Hi Jp,
Le vendredi 30 septembre 2005 à 12:20 -0400, Jp Calderone a écrit :
Advocating might be putting it too strongly :) Experimenting with
describes the current state of things most accurately.
Ok :)
The problem it aims to solve is integration with cooperative threading
systems which
I was just saying that it can be useful to mix cooperative threading and
preemptive threading in the same app, i.e. have different domains of
cooperative threading which are preemptively scheduled by the OS. That
has nothing to do with the GIL, I think (but I don't know much in Python
On 9/30/05, Raymond Hettinger [EMAIL PROTECTED] wrote:
[Guido van Rossum]
__len__ is for sequences and mappings specifically -- everything that
supports __getitem__ should have __len__ and everything that has
__len__ should have __getitem__.
That's going a bit far. Unordered collections
On 9/29/05, Guido van Rossum [EMAIL PROTECTED] wrote:
[SNIP]
Flames, pleas to reconsider, etc., to /dev/null.
Congratulations gracefully accepted.
And gladly given! All proposals should be resolved this cleanly in the end.
It's still my language! :-)
Yes it is, thank goodness!
-Brett
On Fri, 2005-09-30 at 18:33 +0200, Antoine Pitrou wrote:
Hi Jp,
Le vendredi 30 septembre 2005 à 12:20 -0400, Jp Calderone a écrit :
Advocating might be putting it too strongly :) Experimenting with
describes the current state of things most accurately.
Ok :)
The problem it aims to
[ I don't post often, but hopefully the following is of interest in this
discussion ]
Bruce Eckel wrote:
Yes, defining an class as active would:
1) Install a worker thread and concurrent queue in each object of that
class.
2) Automatically turn method calls into tasks and enqueue them
3)
Guido van Rossum wrote:
On 9/30/05, Nick Coghlan [EMAIL PROTECTED] wrote:
An approach to this area that would make sense to me is:
1. Defer PEP 350
2. Publish a simple Python module for finding and processing code tags in a
configurable fashion
3. Include a default configuration in the module
On 9/30/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Further, I see some interesting possibilities for automation if such a library
exists. For example, a cron job that scans the checked in sources, and
automatically converts new TODO's to RFE's in the project tracker, and adds a
tracker
38 matches
Mail list logo
