On May 7, 2007, at 1:58 PM, Guido van Rossum wrote:
> As C doesn't have an atomic increment nor an atomic
> decrement-and-test, the INCREF and DECREF macros sprinkled throughout
> the code (many thousands of them) must be protected by some lock.
I've been intently ignoring the rest of the thread (
On 5/8/07, Thomas Heller wrote:
> Wouldn't multiple interpreters (assuming the problems with them would be
> fixed)
> in the same process give the same benefit? A separate GIL for each one?
hmm, i find this idea quite interesting really:
* builtin immutable objects such as None, small ints, no
On 08/05/2007 1.48, Andrew Koenig wrote:
> It has occurred to me that as Python stands today, an indent always begins
> with a colon. So in principle, we could define anything that looks like an
> indent but doesn't begin with a colon as a continuation.
I got a dejavu here :)
http://mail.pytho
On 07/05/2007 7.36, Josiah Carlson wrote:
> By going multi-process rather than multi-threaded, one generally removes
> shared memory from the equasion. Note that this has the same effect as
> using queues with threads, which is generally seen as the only way of
> making threads "easy". If one *n
On Wed, May 09, 2007, tomer filiba wrote:
>
> of course i'm not talking about adding that to py3k. it's too immature
> even for a pre-pep. but continuing to develop that idea more could
> be the means to removing the GIL, and finally having really parallel
> python scripts.
...which is why this di
> I got a dejavu here :)
> http://mail.python.org/pipermail/python-3000/2007-April/007045.html
>
> and Guido's answer:
> http://mail.python.org/pipermail/python-3000/2007-April/007063.html
Well yes, but if it's done at the lexical level, the INDENT and DEDENT
tokens don't exist.
___
binascii.b2a_qp() in the p3yk branch is broken. What I get is:
$ gdb ./python
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
James Y Knight <[EMAIL PROTECTED]> wrote:
> On May 7, 2007, at 1:58 PM, Guido van Rossum wrote:
> > As C doesn't have an atomic increment nor an atomic
> > decrement-and-test, the INCREF and DECREF macros sprinkled throughout
> > the code (many thousands of them) must be protected by some lock.
>
At 09:58 PM 5/8/2007 -0400, Chris Monson wrote:
>If we are looking at doing Design By Contract using @before and
>@after (preconditions and postconditions), shouldn't there be some
>way of getting at the return value in functions decorated with @after?
Actually, it isn't really design by contrac
At 09:57 PM 5/8/2007 -0600, Jeff Shell wrote:
>I must admit that I didn't read PEP 3124 in depth - most of it was
>fascinating, some of it went way over my head in complexity, and then
>suddenly I saw an Interface. It seemed quite out of place, actually,
Yep; it's really more like a "adapting abst
Fixed. The code was using strchr() instead of memchr(), which was
wrong anyway; but b"" is the only object (apparently) whose buffer
pointer is NULL when the size is 0.
Committed revision 55204.
Please backport (I wouldn't be surprised if this could be exploited).
On 5/9/07, Walter Dörwald <[EMA
On 5/1/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> Comments and questions appreciated, as it'll help drive better explanations
> of both the design and rationales. I'm usually not that good at guessing
> what other people will want to know (or are likely to misunderstand) until
> I get actual
On 5/9/07, BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
> I very much prefer the latter version. The reason is because the
> "locality of reference" is much worse in the overloaded version and
> because I have found it to be very hard to read and understand
> overloaded code in practice.
>
> Let's sa
On 4/30/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> PEP: 3124
> Title: Overloading, Generic Functions, Interfaces, and Adaptation
[snip]
> from overloading import overload
> from collections import Iterable
>
> def flatten(ob):
> """Flatten an object to its component ite
At 09:54 PM 5/9/2007 +0200, BJörn Lindqvist wrote:
>On 5/1/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > Comments and questions appreciated, as it'll help drive better explanations
> > of both the design and rationales. I'm usually not that good at guessing
> > what other people will want to k
Phillip J. Eby wrote:
> At 09:54 PM 5/9/2007 +0200, BJörn Lindqvist wrote:
>> With the non-overloaded version you also have the ability to insert
>> debug print statements to figure out what happens.
>
> Ahem.
>
> @before(do_stuff)
> def debug_it(ob: ClassC):
> import pdb
>
At 02:41 PM 5/9/2007 -0600, Steven Bethard wrote:
>On 4/30/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>>Proceeding to the "Next" Method
>>~~~
>[snip]
>>"Before" and "After" Methods
>>
>[snip]
>>"Around" Methods
>>
>[snip]
>>
At 07:09 AM 5/10/2007 +1000, Nick Coghlan wrote:
>Phillip J. Eby wrote:
> > At 09:54 PM 5/9/2007 +0200, BJörn Lindqvist wrote:
> >> With the non-overloaded version you also have the ability to insert
> >> debug print statements to figure out what happens.
> >
> > Ahem.
> >
> > @before(do_stuff
Phillip J. Eby wrote:
> If you don't count in-house "enterprise" operations and shops like
> Google, Yahoo, et al., the development of Zope is certainly one of
> the largest (if not the very largest) Python project. It's
> understandable that LBYL is desirable in that environment. On the
> ot
On 5/9/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 09:54 PM 5/9/2007 +0200, BJörn Lindqvist wrote:
> >What if they have defined a do_stuff that dispatch on ClassC that is a
> >subclass of ClassA? Good luck in figuring out what the code does.
> >With the non-overloaded version you also have
On 5/8/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/8/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > On 5/8/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > 1. develop working code under 2.6
> > > 2. make sure it is warning-free with the special -Wpy3k option
> > > 3. use 2to3 to co
James Y Knight wrote:
> This just isn't true. Python can do an atomic increment in a fast
> platform specific way.
The problem with this, from what I've heard, is that
atomic increment instructions tend to be on the order
of 100 times slower than normal memory accesses (I
guess because they hav
At 06:26 PM 5/9/2007 -0400, Jim Jewett wrote:
>On 5/9/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>>At 09:54 PM 5/9/2007 +0200, BJörn Lindqvist wrote:
>> >What if they have defined a do_stuff that dispatch on ClassC that is a
>> >subclass of ClassA? Good luck in figuring out what the code does.
>
Giovanni Bajo wrote:
> using multiple processes cause some
> headaches with frozen distributions (PyInstaller, py2exe, etc.), like those
> usually found on Windows, specifically because Windows does not have fork().
Isn't that just a problem with Windows generally? I don't
see what the method of
At 06:11 PM 5/9/2007 -0400, Benji York wrote:
>Phillip J. Eby wrote:
>>If you don't count in-house "enterprise" operations and shops like
>>Google, Yahoo, et al., the development of Zope is certainly one of
>>the largest (if not the very largest) Python project. It's
>>understandable that LBYL
Greg Ewing wrote:
> Giovanni Bajo wrote:
>> using multiple processes cause some
>> headaches with frozen distributions (PyInstaller, py2exe, etc.), like those
>> usually found on Windows, specifically because Windows does not have fork().
>
> Isn't that just a problem with Windows generally? I d
Phillip J. Eby wrote:
> For
> example, objects to be documented with pydoc currently have to
> reverse engineer a bunch of inspection code, while in a GF-based
> design they'd just add methods.
There's a problem with this that I haven't seen a good
answer to yet. To add a method to a generic fu
On 5/9/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 02:41 PM 5/9/2007 -0600, Steven Bethard wrote:
> >On 4/30/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> >>Proceeding to the "Next" Method
> >>~~~
> >[snip]
> >>"Before" and "After" Methods
> >>~~
Phillip J. Eby wrote:
> Which is an excellent demonstration, by the way, of another reason
> why before/after methods are useful. They're all *always* called
> before and after the primary methods, regardless of how many of them
> were registered.
But unless I'm mistaken, ClassC can still tak
Mike Klaas wrote:
> NtCreateProcess with SectionHandler=NULL does a fork()-like
> copy-on-write thing. But it is an internal kernel api.
I just did some googling on this, and it seems to be
described as "undocumented". Does this mean that it's
possible to call it from userland, just that it's no
Talin wrote:
> Thought experiment: Suppose you were writing and brand-new dynamic
> language today, designed to work efficiently on multi-processor systems.
> Forget all of Python's legacy implementation details such as GILs and
> refcounts and such. What would it look like, and how well would
On 5/9/07, Talin <[EMAIL PROTECTED]> wrote:
<>
> This much I agree: There's no point in talking about supporting multiple
> processors using threads as long as we're living in a refcounting world.
<>
But python isn't--CPython, though, certainly is. The CPython
interpreter has enormous stability,
Mike Klaas wrote:
> It would probably be more fruitful to start a
> new python interpreter project based on a different architecture.
But it's not even clear what that different architecture
should be...
--
Greg Ewing, Computer Science Dept, +--+
University of
Greg Ewing <[EMAIL PROTECTED]> wrote:
> Giovanni Bajo wrote:
> > using multiple processes cause some
> > headaches with frozen distributions (PyInstaller, py2exe, etc.), like those
> > usually found on Windows, specifically because Windows does not have fork().
>
> Isn't that just a problem wit
Greg Ewing wrote:
> Phillip J. Eby wrote:
>> For
>> example, objects to be documented with pydoc currently have to
>> reverse engineer a bunch of inspection code, while in a GF-based
>> design they'd just add methods.
>
> There's a problem with this that I haven't seen a good
> answer to yet. T
I'll just chime in tersely since this really seems like -ideas and not
-3000 territory
On 5/9/07, Talin <[EMAIL PROTECTED]> wrote:
> modern consoles such as PS/3 and Xbox do not, since they have no support for
> virtual memory at all.
Well, they have virtual memory as in virtual address spaces, b
Greg Ewing schrieb:
> James Y Knight wrote:
>
>> This just isn't true. Python can do an atomic increment in a fast
>> platform specific way.
>
> The problem with this, from what I've heard, is that
> atomic increment instructions tend to be on the order
> of 100 times slower than normal memory
37 matches
Mail list logo
