Re: [Python-3000] Set literals - another try

Collin Winter wrote: > On 8/8/06, Josiah Carlson <[EMAIL PROTECTED]> wrote: >> I personally don't see much of a use for set literals, considering that >> there is a non-ambiguous spelling of it currently; set(...), whose only >> cost above and beyond that of a set literal is a global name lookup.

Re: [Python-3000] threading, part 2

Jim Jewett wrote: > On 8/8/06, tomer filiba <[EMAIL PROTECTED]> wrote: >> my previous suggestion asked for is a means to raise exceptions in the >> context of *other* threads. > > ... > >> * breaking the thread's state -- that's not really an issue. i'm not talking >> about *forcefully* killing t

Re: [Python-3000] Cross-interpreter FFI for Python 3000?

Phillip J. Eby wrote: > (This is all IMO, of course, but I find it hard to imagine how anything > else could succeed.) Having just made the point in another thread that it is possible to use ctypes to access the CPython API functions like PyThreadState_SetAsyncExc that have been designated "ext

Re: [Python-3000] Set literals - another try

On 8/9/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > A different way to enable that would be to include a set of non-keyword names > (a subset of the default builtin namespace) in the language definition that > the compiler is explicitly permitted to treat as constants if they are not > otherwise d

Re: [Python-3000] Set literals - another try

On 8/8/06, Talin <[EMAIL PROTECTED]> wrote: > Part 1: The concrete proposal part. > > I noticed that a lot of folks seemed to like the idea of making the > empty set resemble the greek letter Phi, using a combination of > parentheses and the vertical bar or forward slash character. > > So lets expa

Re: [Python-3000] Set literals - another try

> On 8/9/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > > A different way to enable that would be to include a set of non-keyword > > names > > (a subset of the default builtin namespace) in the language definition that > > the compiler is explicitly permitted to treat as constants if they are not

Re: [Python-3000] Set literals - another try

On 8/8/06, Collin Winter <[EMAIL PROTECTED]> wrote: > I thought one of the main arguments in favor of set literals is that a > literal form would allow the compiler to perform optimisations that > the set(...) spelling doesn't allow. Let me clear up this misunderstanding. Optimizations have nothin

Re: [Python-3000] threading, part 2

On 8/9/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > That check is already there: > > int PyThreadState_SetAsyncExc( long id, PyObject *exc) > Asynchronously raise an exception in a thread. The id argument is the > thread id of the target thread; exc is the exception object to be raised. This

Re: [Python-3000] threading, part 2

[Nick Coghlan] >> That check is already there: >> >> int PyThreadState_SetAsyncExc( long id, PyObject *exc) >> Asynchronously raise an exception in a thread. The id argument is the >> thread id of the target thread; exc is the exception object to be raised. This >> function does not steal any

Re: [Python-3000] threading, part 2

On 8/9/06, Tim Peters <[EMAIL PROTECTED]> wrote: > [Nick Coghlan] > >> That check is already there: > >> > >> int PyThreadState_SetAsyncExc( long id, PyObject *exc) > >> Asynchronously raise an exception in a thread. The id argument is the > >> thread id of the target thread; exc is the excep

Re: [Python-3000] threading, part 2

"Guido van Rossum" <[EMAIL PROTECTED]> writes: >> for the same reason one should always incref B before decrefing A in >> >> A = B >> >> ... > > That reason that A and B might already be the same object, right? Or B might be a subobject of A, not referenced elsewhere. -- __("< Ma

[Python-3000] Python/C++ question

A while back someone proposed switching to C++ as the implementation language for CPython, and the response was that this would make ABI compatibility too difficult, since the different C++ compilers don't have a common way to represent things like vtables and such. However, I was thinking - if

Re: [Python-3000] Python/C++ question

On 8/9/06, Talin <[EMAIL PROTECTED]> wrote: > A while back someone proposed switching to C++ as the implementation > language for CPython, and the response was that this would make ABI > compatibility too difficult, since the different C++ compilers don't > have a common way to represent things lik

[Python-3000] Draft pre-PEP: function annotations

After letting the discussions from the Spring stew in my head for a few months, here's my first draft of the proto-PEP for function annotations. This is intended to lay out in a single document the basic ideas for function annotations, to get community feedback on the fundamentals before proceeding

Re: [Python-3000] Draft pre-PEP: function annotations

Collin Winter wrote: >There is no worry that these libraries will assign semantics at >random, or that a variety of libraries will appear, each with varying >semantics and interpretations of what, say, a tuple of strings >means. The difficulty inherent in writing annotation interpre

Re: [Python-3000] Draft pre-PEP: function annotations

On 8/9/06, Talin <[EMAIL PROTECTED]> wrote: > Collin Winter wrote: > >There is no worry that these libraries will assign semantics at > >random, or that a variety of libraries will appear, each with varying > >semantics and interpretations of what, say, a tuple of strings > >means.

Re: [Python-3000] threading, part 2

[back and forth on PyThreadState_SetAsyncExc()] [Tim] >> Guido, do you have any idea now what the "number greater than one" >> business is about? >> ... >> My impression has been that it would be an internal logic error if we >> ever saw this count exceed 1. [Guido] > Right, I think that's it. I

Re: [Python-3000] Draft pre-PEP: function annotations

Collin Winter wrote: >one library might use string-based annotations to provide >improved help messages, like so: > > def compile(source: "something compilable", > filename: "where the compilable thing comes from", > mode: "is this a single st

Re: [Python-3000] Draft pre-PEP: function annotations

Collin Winter wrote: > On 8/9/06, Talin <[EMAIL PROTECTED]> wrote: > >>Collin Winter wrote: >> >>> The difficulty inherent in writing annotation interpreting >>> libraries will keep their number low and their authorship in the >>> hands of people who, frankly, know what they're doing. >> >>I

Re: [Python-3000] Draft pre-PEP: function annotations

On 8/9/06, Greg Ewing <[EMAIL PROTECTED]> wrote: > Collin Winter wrote: > >one library might use string-based annotations to provide > >improved help messages, like so: > > > > def compile(source: "something compilable", > > filename: "where the compilable thing

Re: [Python-3000] threading, part 2

On 8/9/06, Tim Peters <[EMAIL PROTECTED]> wrote: > [back and forth on PyThreadState_SetAsyncExc()] > > [Tim] > >> Guido, do you have any idea now what the "number greater than one" > >> business is about? > >> ... > >> My impression has been that it would be an internal logic error if we > >> ever

[Python-3000] Ctypes as cross-interpreter C calling interface

Thanks for everyone who contributed. It seems that the emerging consensus (bar a security question from Guido) is that ctypes it the way forward for calling C code in Python 3000. I'd like to clarify what this might mean: 1. Is ctypes and pure python fast enough for most real-world extension module

Re: [Python-3000] threading, part 2

Guido van Rossum wrote: > Fine with me then. In 2.5? 2.6? Or py3k? (This is the py3k list.) FWIW, we'll ship 2.5 on the OLPC (laptop.org) machines, and it looks like we'll need this. It'd be useful to have it directly in CPython, so people running our software outside the laptops don't have to fus

Re: [Python-3000] Draft pre-PEP: function annotations

At 14:47 8/10/2006 +1200, Greg Ewing <[EMAIL PROTECTED]> wrote: >And what are you supposed to do if you want to write >a function that has improved help messages *and* >type checking? Create a type annotation object that wraps multiple objects -- or better yet, use a list or tuple of annotations.