Nick Coghlan wrote:
> Phillip J. Eby wrote:
>> Nick Coghlan wrote:
>
[...]
>
>> Last, but far from least, as far as I can tell you can implement all of
>> these semantics using PEP 342 as it sits. That is, it's very simple to
>> make decorators or classes that add those semantics. I don't see
Patch / Bug Summary
___
Patches : 341 open ( +4) / 2953 closed ( +6) / 3294 total (+10)
Bugs: 884 open (-28) / 5321 closed (+43) / 6205 total (+15)
RFE : 196 open ( +1) / 187 closed ( +0) / 383 total ( +1)
New / Reopened Patches
__
Make fcnt
Guido van Rossum wrote:
> I will, if you tell me your sourceforge username.
Sorry, forgot about that little detail ;)
Anyway, its ncoghlan, same as the gmail account.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
--
At 07:17 PM 10/7/2005 -0600, Adam Olsen wrote:
>On 10/7/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 06:12 PM 10/7/2005 -0600, Adam Olsen wrote:
> > >Turns out it's quite easy and it doesn't harm performance of existing
> > >code or require modification (but a recompile is necessary). The
Michael Sparks <[EMAIL PROTECTED]> wrote:
> [ Possibly overlengthy reply. However given a multiple sets of cans of
> worms... ]
> On Friday 07 October 2005 07:25, Josiah Carlson wrote:
> > One thing I notice is absent from the Kamaelia page is benchmarks.
>
> That's largely for one simple reaso
On Oct 3, 2005, at 1:53 AM, Piet Delport wrote:
> For generators written in this style, "yield" means "suspend
> execution of the
> current call until the requested result/resource can be provided", and
> "return" regains its full conventional meaning of "terminate the
> current call
> with a g
Adam Olsen <[EMAIL PROTECTED]> wrote:
> I need to stress that *only* the new, immutable and "thread-safe
> mark-and-sweep" types would be affected by these changes. Everything
> else would continue to exist as it did before, and the benchmark
> exists to show they can coexist without killing perf
Phillip J. Eby wrote:
> At 09:50 PM 10/7/2005 +1000, Nick Coghlan wrote:
>
>> Notice how a non-coroutine callable can be yielded, and it will still
>> work
>> happily with the scheduler, because the desire to continue execution is
>> indicated by the ContinueIteration exception, rather than by th
On 10/7/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 06:12 PM 10/7/2005 -0600, Adam Olsen wrote:
> >Okay, basic principal first. You start with a sandboxed thread that
> >has access to nothing. No modules, no builtins, *nothing*. This
> >means it can run without the GIL but it can't do any
Phillip J. Eby wrote:
> Oh, and don't forget - newstyle classes keep weak references to all their
> subclasses, which means for example that every time you subclass 'dict',
> you're modifying the "immutable" 'dict' class. So, unless you recreate all
> the classes in each sandbox, you're back to
At 06:12 PM 10/7/2005 -0600, Adam Olsen wrote:
>Okay, basic principal first. You start with a sandboxed thread that
>has access to nothing. No modules, no builtins, *nothing*. This
>means it can run without the GIL but it can't do any work.
It sure can't. You need at least the threadstate and
Okay, basic principal first. You start with a sandboxed thread that
has access to nothing. No modules, no builtins, *nothing*. This
means it can run without the GIL but it can't do any work. To make it
do something useful we need to give it two things: first, immutable
types that can be safely
Fredrik Lundh wrote:
> Nick Coghlan wrote:
>>However, requiring a decorator to get a slot to work right looks pretty ugly
>>to me, too.
>
>
> the whole concept might be perfectly fine on the "this construct corre-
> sponds to this code" level, but if you immediately end up with things that
> are
Bruce Eckel wrote:
> I always have a problem with this. After many years of studying
> concurrency on-and-off, I continue to believe that threading is very
> difficult (indeed, the more I study it, the more difficult I
> understand it to be). And I admit this. The comments I sometimes get
> back ar
Martin,
These two cases generate different bytecode.
def foo(): # foo.func_code.co_flags == 0x43
print x# LOAD_FAST 0
x = 3
class Foo: # .co_flags == 0x40
print x# LOAD_NAME 'x'
x = 3
In functions, local variables are just numbered slots.
On Thursday 06 October 2005 21:06, Bruce Eckel wrote:
> So yes indeed, this is quite high on my list to research. Looks like
> people there have been doing some interesting work.
>
> Right now I'm just trying to cast a net, so that people can put in
> ideas, for when the Java book is done and I can
On Friday 07 October 2005 23:26, Bruce Eckel wrote:
> I think the ease of use issue opens up far greater possibilities if you
> include multiprocessing
...
> That's what I'm looking for.
In which case that's an area we need to push our work into sooner rather
than later. After all, the PS3 and
> //Theoretically// I suspect that the system /could/ perform as well as
> traditional approaches to dealing with concurrent problems single threaded
> (and multi-thread/process).
I also think it's important to factor in the possibility of
multiprocessors. If Kamaelia (for example) has a very safe
Antoine Pitrou wrote:
>>I'd be happy to explain how
>>ZODB solves those problems, if you're interested.
>
>
> Well, yes, I'm interested :)
> (I don't anything about Zope internals though, and I've never even used
> it)
Ok. Quoting your list:
> To apply the same thing to Python you would at l
> Well, I think you just described ZODB. ;-)
*gasp*
> I'd be happy to explain how
> ZODB solves those problems, if you're interested.
Well, yes, I'm interested :)
(I don't anything about Zope internals though, and I've never even used
it)
___
Pyth
Shane Hathaway wrote:
> Antoine Pitrou wrote:
>
>>A relational database has a very strict and regular data model. Also, it
>>has transactions. This makes it easy to precisely define concurrency at
>>the engine level.
>>
>>To apply the same thing to Python you would at least need :
>> 1. a way to
[ Possibly overlengthy reply. However given a multiple sets of cans of
worms... ]
On Friday 07 October 2005 07:25, Josiah Carlson wrote:
> One thing I notice is absent from the Kamaelia page is benchmarks.
That's largely for one simple reason: we haven't done any yet.
At least not anything I'd
Antoine Pitrou wrote:
> A relational database has a very strict and regular data model. Also, it
> has transactions. This makes it easy to precisely define concurrency at
> the engine level.
>
> To apply the same thing to Python you would at least need :
> 1. a way to define a subset of the curr
On Fri, Oct 07, 2005 at 12:15:04PM -0700, Martin Maly wrote:
> Hello Python-Dev,
>
> My name is Martin Maly and I am a developer at Microsoft, working on the
> IronPython project with Jim Hugunin. I am spending lot of time making
> IronPython compatible with Python to the extent possible.
>
> I
Martin Maly wrote:
> Hello Python-Dev,
>
> My name is Martin Maly and I am a developer at Microsoft, working on the
> IronPython project with Jim Hugunin. I am spending lot of time making
> IronPython compatible with Python to the extent possible.
>
> I came across a case which I am not sure if
At 12:15 PM 10/7/2005 -0700, Martin Maly wrote:
>Based on the binding rules described in the Python documentation, I
>would expect the code to throw because binding created on the line (1)
>is local to the class block and all the other __doc__ uses should
>reference that binding. Apparently, it is
Martin Maly wrote:
> I came across a case which I am not sure if by design or a bug in Python
> (Python 2.4.1 (#65, Mar 30 2005, 09:13:57)). Consider following Python
> module:
>
> # module begin
> "module doc"
>
> class c:
> print __doc__
> __doc__ = "class doc" (1)
> print __doc__
>
Hello Python-Dev,
My name is Martin Maly and I am a developer at Microsoft, working on the
IronPython project with Jim Hugunin. I am spending lot of time making
IronPython compatible with Python to the extent possible.
I came across a case which I am not sure if by design or a bug in Python
(Pyt
Hi,
(my 2 cents, probably not very constructive)
> Recently, I've been simulating high concurrency on a PostgreSQL
> database, and I've discovered that the way you reason about row and
> table locks is very similar to the way you reason about locking among
> threads. The big difference is th
On Fri, 2005-10-07 at 14:42, Shane Hathaway wrote:
> What's insanely difficult is really locking, and locking is driven by
> concurrency in general, not just threads. It's hard to reason about
> locks.
I think that's a very interesting observation! I have not built a
tremendous number of co
Bruce Eckel wrote:
> But. I do happen to have contact with a lot of people who are at the
> forefront of the threading world, and *none* of them (many of whom
> have written the concurrency libraries for Java 5, for example) ever
> imply that threading is easy. In fact, they generally go out of the
At 10:47 AM 10/7/2005 -0600, Bruce Eckel wrote:
>Also, look at the work that Scott Meyers, Andrei Alexandrescu, et al
>did on the "Double Checked Locking" idiom, showing that it was broken
>under threading. That was by no means "trivial and obvious" during all
>the years that people thought that it
> Someone should really write up a PEP -- this was just discussed a week
> or two ago.
Heh.. I should follow the list more closely.
> I personally think this is adequately handled by writing:
>
> (first, second), rest = something[:2], something[2:]
That's an alternative indeed. But the the pr
At 09:50 PM 10/7/2005 +1000, Nick Coghlan wrote:
>Notice how a non-coroutine callable can be yielded, and it will still work
>happily with the scheduler, because the desire to continue execution is
>indicated by the ContinueIteration exception, rather than by the type of the
>returned value.
Whaaa
On Fri, Oct 07, 2005, Bruce Eckel wrote:
>
> I always have a problem with this. After many years of studying
> concurrency on-and-off, I continue to believe that threading is very
> difficult (indeed, the more I study it, the more difficult I
> understand it to be). And I admit this. The comments I
On 10/7/05, Gustavo Niemeyer <[EMAIL PROTECTED]> wrote:
> Not sure if this has been proposed before, but one thing
> I occasionally miss regarding tuple unpack is being able
> to do:
>
> first, second, *rest = something
>
> Also in for loops:
>
> for first, second, *rest in iterator:
> pa
On 10/6/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 07:34 PM 10/6/2005 -0700, Guido van Rossum wrote:
> >How does this sound to the non-AST-branch developers who have to
> >suffer the inevitable post-merge instability? I think it's now or
> >never -- waiting longer isn't going to make this t
Not sure if this has been proposed before, but one thing
I occasionally miss regarding tuple unpack is being able
to do:
first, second, *rest = something
Also in for loops:
for first, second, *rest in iterator:
pass
This seems to match the current meaning for starred
variables in othe
Early in this thread there was a comment to the effect that "if you
don't know how to use threads, don't use them," which I pointedly
avoided responding to because it seemed to me to simply be
inflammatory. But Ian Bicking just posted a weblog entry:
http://blog.ianbicking.org/concurrency-and-proce
Nick Coghlan wrote:
> That's not what the decorator is for - it's there to turn the generator used
> to implement the __with__ method into a context manager, rather than saying
> anything about decimal.Context as a whole.
possibly, but using a decorated __with__ method doesn't make much
sense if
I will, if you tell me your sourceforge username.
On 10/7/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Could one of the Sourceforge powers-that-be grant me check in access so I can
> update PEP 343 directly?
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
__
Nick Coghlan wrote:
> Eric Nieuwland wrote:
>> What happens to
>>
>> with 40*13+2 as X:
>> print X
>
> It would fail with a TypeError because the relevant slot in the type
> object
> was NULL - the TypeError checks aren't shown for simplicity's sake.
>
> This behaviour isn't really any
Could one of the Sourceforge powers-that-be grant me check in access so I can
update PEP 343 directly?
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.blogspot.
Michael Hudson wrote:
>
> You don't want to check if it's a generator, you want to check if it's
> a function whose func_code has the relavent bit set.
>
Fair point :)
> Seems a bit magical to me, but haven't thought about it hard.
Same here - I'm just starting to think that the alternative is
Anders J. Munch wrote:
> Note that __with__ and __enter__ could be combined into one with no
> loss of functionality:
>
> abc,VAR = (EXPR).__with__()
They can't be combined, because they're invoked on different objects. It would
be like trying to combine __iter__() and next() into the sa
Eric Nieuwland wrote:
> What happens to
>
> with 40*13+2 as X:
> print X
It would fail with a TypeError because the relevant slot in the type object
was NULL - the TypeError checks aren't shown for simplicity's sake.
This behaviour isn't really any different from the existing PEP 34
Nick Coghlan wrote:
> 1. Amend the statement specification such that:
>
>with EXPR as VAR:
>BLOCK
>
> is translated as:
>
>abc = (EXPR).__with__()
>exc = (None, None, None)
>VAR = abc.__enter__()
>try:
>try:
>BLOCK
>
Nick Coghlan did a +1 job to write:
> 1. Amend the statement specification such that:
>
>with EXPR as VAR:
>BLOCK
>
> is translated as:
>
>abc = (EXPR).__with__()
>exc = (None, None, None)
>VAR = abc.__enter__()
>try:
>try:
>
Nick Coghlan <[EMAIL PROTECTED]> writes:
> What if we simply special-cased the __with__ slot in type(), such that if it
> is populated with a generator object, that object is automatically wrapped
> using the @contextmanager decorator? (Jason actually suggested this idea
> previously)
You don
Nick Coghlan wrote:
> It ends up looking like this:
>
> def __call__(self, value=None):
> """ Call a generator as a coroutine
>
> Returns the first argument supplied to StopIteration or
> None if no argument was supplied.
> Raises Conti
Fredrik Lundh wrote:
> Nick Coghlan wrote:
>
>
>>9. Here's a proposed native context manager for decimal.Context:
>>
>># This would be a new decimal.Context method
>>@contextmanager
>>def __with__(self):
>
>
> wouldn't it be better if the ContextWrapper class (or som
I'm lifting Jason's PEP 342 suggestions out of the recent PEP 343 thread, in
case some of the folks interested in coroutines stopped following that
discussion.
Jason suggested two convenience methods, .start() and .finish().
start() simply asserted that the generator hadn't been started yet, an
Nick Coghlan wrote:
> 9. Here's a proposed native context manager for decimal.Context:
>
> # This would be a new decimal.Context method
> @contextmanager
> def __with__(self):
wouldn't it be better if the ContextWrapper class (or some variation thereof)
could
be used
Based on Jason's comments regarding decimal.Context, and to explicitly cover
the terminology agreed on during the documentation discussion back in July,
I'm proposing a number of changes to PEP 343. I'll be updating the checked in
PEP assuming there aren't any objections in the next week or so (
says
If type indicates that the object participates in the cyclic garbage
detector, it is added to the detector's set of observed objects.
Is this really correct? I thought you need to invoke PyObject_GC_TRACK
explicitly?
Regards,
Martin
___
Python-D
55 matches
Mail list logo
