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 cr
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
[ 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
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 prob
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!
-
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 co
> 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
> int
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 w
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 do
[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.
Raymon
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 d
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 thre
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
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
On 9/29/05, Robey Pointer 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 for hold
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 inte
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 non-cont
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 p
> > 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 wi
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 do
[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 el
Le vendredi 30 septembre 2005 à 07:32 -0700, Simon Wittber a écrit :
> I use this approach extensively, using tasks which are defined using
> generators. The scheduler I developed for this can be viewed here:
>
> http://metaplay.dyndns.org:82/svn/nanothreads/nanothreads.py
FWIW, I've coded my ow
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
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, 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
>
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 pr
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 t
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.
>
Support for multiple interpreters already exists from the C API
(mod_python, Java Embedded Python a few other add-ons use them)
But:
- it's not possible to create new interpreter instances from within Python.
- there's no mechanism for passing information between interpreters.
- interaction wit
>> (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.
Skip
_
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! :).
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 langua
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
> > othe
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
> (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 explicit
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
Guido van Rossum wrote:
> Congratulations gracefully accepted.
Hurrah!
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.blogspot.com
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
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 smart in up updatecache function. When os.stat() on the f
39 matches
Mail list logo
