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
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 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
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
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
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,
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
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
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
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:
> 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
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
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
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: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.
>
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
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
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
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
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
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]
>>
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 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
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
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 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
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
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
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
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.
>
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.
> 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.
___
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
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 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 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 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 (
37 matches
Mail list logo
