Tim Peters schrieb:
> [Josiah Carlson]
>> ...
>> Python 2.3.5 (#62, Feb 8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)] on
>> win32
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> import ctypes
>> >>> import threading
>> >>> import time
>> >>> def foo():
>> ...
After thinking about it some more, IMO for most purposes ctypes is
really quite sub-optimal. I think it would make more sense to work on
Parrot support for Python. Sure, in the short term ctypes is more
practical than Parrot -- in its most recent incarnation, the latter
doesn't even list Python as
On Mon, 14 Aug 2006 08:31:31 -0700, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>After thinking about it some more, IMO for most purposes ctypes is
>really quite sub-optimal. I think it would make more sense to work on
>Parrot support for Python. Sure, in the short term ctypes is more
>practical t
No. Why would it be a joke? Because it's a Perl thing? Because it
doesn't acknowledge Python's obvious supremacy in the universe of
languages? Because it admits that other projects sometimes have good
ideas? Because it's a good idea to have to write separate wrappers
around every useful library for
On Mon, 14 Aug 2006 09:09:49 -0700, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>On 8/14/06, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
>>On Mon, 14 Aug 2006 08:31:31 -0700, Guido van Rossum <[EMAIL PROTECTED]>
>>wrote:
>> >After thinking about it some more, IMO for most purposes ctypes is
>>
Not remembering the PEP in detail, I agree with Jim's resolution of all these.
I guess the right rule is that all positional arguments come first
(first the regular ones, then * or *args). Then come the keyword
arguments, again, first the regular ones (name=value), then **kwds.
I believe the PEP
On 8/14/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I believe the PEP doesn't address the opposite use case: positional
> arguments that should *not* be specified as keyword arguments. For
> example, I might want to write
>
> def foo(a, b): ...
>
> but I don't want callers to be able to cal
On 8/14/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 8/14/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > I believe the PEP doesn't address the opposite use case: positional
> > arguments that should *not* be specified as keyword arguments. For
> > example, I might want to write
> >
> >
On 8/14/06, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> On Mon, 14 Aug 2006 09:09:49 -0700, Guido van Rossum <[EMAIL PROTECTED]>
> wrote:
> >On 8/14/06, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> >>This is a joke, right?
> >Because it's a good idea to have to write separate wrappers
> >
On 8/13/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Talin wrote:
> > Guido van Rossum wrote:
> >> On 8/9/06, Talin <[EMAIL PROTECTED]> wrote:
> >> For the majority of Python developers it's probably the other way
> >> around. It's been 15 years since I wrote C++, and unlike C, that
> >> language
On 8/11/06, tomer filiba <[EMAIL PROTECTED]> wrote:
> i mailed this to several people separately, but then i thought it could
> benefit the entire group:
>
> http://sebulba.wikispaces.com/recipe+thread2
>
> it's an implementation of the proposed " thread.raise_exc", through an
> extension
> to the
I guess I don't see ctypes and Parrot solving the same problem at all. My idea with ctypes was the opposite of choosing a new runtime. It was to help various runtimes (PyPy, Jython, IronPython, CPython 2.5, CPython 3.0, Parrot, ...) to compete on their own merits (primarily performance and interope
On 8/13/06, Paul Prescod <[EMAIL PROTECTED]> wrote:
> My proposed text for the PEP is as follows:
Mostly good. A few remaining comments...
Should annotation objects with defined semantics have some standard
way to indicate this? (By analogy, new exceptions *should* inherit
from Exception; shoul
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
>
> On 8/11/06, tomer filiba <[EMAIL PROTECTED]> wrote:
> > i mailed this to several people separately, but then i thought it could
> > benefit the entire group:
> >
> > http://sebulba.wikispaces.com/recipe+thread2
> >
> > it's an implementation of th
Guido van Rossum wrote:
> On 8/11/06, tomer filiba <[EMAIL PROTECTED]> wrote:
>> i mailed this to several people separately, but then i thought it could
>> benefit the entire group:
>>
>> http://sebulba.wikispaces.com/recipe+thread2
>>
>> it's an implementation of the proposed " thread.raise_exc",
Guido van Rossum wrote:
> On 8/13/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
>> Talin wrote:
>> > Guido van Rossum wrote:
>> >> On 8/9/06, Talin <[EMAIL PROTECTED]> wrote:
>> >> For the majority of Python developers it's probably the other way
>> >> around. It's been 15 years since I wrote C++, an
[tomer filiba]
>> i mailed this to several people separately, but then i thought it could
>> benefit the entire group:
>>
>> http://sebulba.wikispaces.com/recipe+thread2
>>
>> it's an implementation of the proposed " thread.raise_exc",
>> ...
[Guido]
> Cool. Question: what's the problem with raisi
On 8/13/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> However, it's only a problem if you insist on writing brain-damaged
> code. If you want interoperability here, you must write tell-don't-ask
> code. ... is it really the case that
> so many people don't know what tell-don't-ask code is or w
On Mon, 14 Aug 2006 11:08:56 -0700, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>On 8/14/06, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
>>On Mon, 14 Aug 2006 09:09:49 -0700, Guido van Rossum <[EMAIL PROTECTED]>
>>wrote:
>I also consider .NET's CLR a success, based on the testimony of Jim
>Hugu
On 8/13/06, Paul Prescod <[EMAIL PROTECTED]> wrote:
> "In order for processors of function annotations to work interoperably, they
> must use a common interpretation of objects used as annotations on a
> particular function. For example, one might interpret string annotations as
> docstrings. Anoth
On 8/14/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
The major difference between all these examples and ctypes is thatctypes has no way of introspecting the wrapped library; you have torepeat everything you know about the API in your calls to ctypes (andas was just shown in another thread about
On 8/14/06, Collin Winter <[EMAIL PROTECTED]> wrote:
The way I read this, it forces (more or less) eachannotation-consuming library to invent new ways to spell Python'sbuilt-in types.I think that this is related to your other question. What if an annotation consuming library wanted to use Python's
On 8/14/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 8/14/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > I believe the PEP doesn't address the opposite use case: positional
> > arguments that should *not* be specified as keyword arguments.
...
> It would be really nice in the example ab
On 8/14/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/14/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > On 8/14/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > I believe the PEP doesn't address the opposite use case: positional
> > > arguments that should *not* be specified as key
On 8/14/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
Should annotation objects with defined semantics have some standardway to indicate this? (By analogy, new exceptions *should* inheritfrom Exception; should annotation objects inherit from an Annotationclass, at least as a mixin?)
All annotation obj
On 8/14/06, Paul Prescod <[EMAIL PROTECTED]> wrote:
> There are three issues: first, we need to RESERVE the types for
> standardization by Guido and crew.
You're just pushing the decision off to someone else. Regardless of
who makes it, decisions involving the built-in types are going to make
some
On 8/14/06, Collin Winter <[EMAIL PROTECTED]> wrote:
On 8/14/06, Paul Prescod <[EMAIL PROTECTED]> wrote:> There are three issues: first, we need to RESERVE the types for> standardization by Guido and crew.You're just pushing the decision off to someone else. Regardless of
who makes it, decisions in
On 8/14/06, Paul Prescod <[EMAIL PROTECTED]> wrote:
> On 8/14/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > On 8/14/06, Paul Prescod <[EMAIL PROTECTED]> wrote:
> > > Second, we can decide to do the standardization at any point.
> >
> > Um, "at any point"? You mean it's conceivable that this
> >
On 8/14/06, Paul Prescod <[EMAIL PROTECTED]> wrote:
> Third, we absolutely need a standard for
> multiple independent annotations on a parameter. Using lists is a
> no-brainer. So let's do that.
The problem with using lists is that its impossible for non-decorator
annotation consumers to know whic
On 8/14/06, Paul Prescod <[EMAIL PROTECTED]> wrote:
> > > "This implies that the interpretation of built-in types would be
> controlled
> > > by Python's developers and documented in Python's documentation.
> > It also implies that the interpretation of annotations made with a
> > built-in type s
On 8/14/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 8/14/06, Paul Prescod <[EMAIL PROTECTED]> wrote:
> The problem with using lists is that its impossible for non-decorator
> annotation consumers to know which element "belongs" to them.
The ones whose type they own -- which is why I see at
On 8/14/06, Collin Winter <[EMAIL PROTECTED]> wrote:
Because not having standardised meanings at the same time as thefeature becomes available says to developers, "don't use the built-intypes in your annotations because we might give them a meaninglater...or maybe we won't...but in the meantime, yo
On 8/14/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 8/14/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> > The problem with using lists is that its impossible for non-decorator
> > annotation consumers to know which element "belongs" to them.
>
> The ones whose type they own -- which is why I see
On 8/14/06, Collin Winter <[EMAIL PROTECTED]> wrote:
What would the rule be about top-level types? Would you have to use alist, or could a set or dict be used?I argue to restrict to a list for the following reasons:1. Better to just pick something for visual consistency (someone said they liked tup
On 8/14/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 8/14/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > On 8/14/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > I believe the PEP doesn't address the opposite use case: positional
> > > arguments that should *not* be specified as keyword a
At 1:51 PM 8/14/2006 -0700, "Paul Prescod" <[EMAIL PROTECTED]> wrote:
>On 8/14/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > The definition of a type as an annotation should probably be either
> > defined or explicitly undefined. Earlier discussions talked about
> > things like
> >
> > def f (
On 8/14/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 8/13/06, Paul Prescod <[EMAIL PROTECTED]> wrote:
> > "In order for processors of function annotations to work interoperably, they
> > must use a common interpretation of objects used as annotations on a
> > particular function. For example,
Phillip J. Eby wrote:
> It can't be a "separate program altogether", since to get at the
> annotations, the program must import the module that contains them.
Why? I can imagine something like a documentation
generator or static type checker that just parses the
source, being careful not to exe
Phillip J. Eby wrote:
> The examples there are very short
> and simple; in fact the complete Message implementation, including
> imports and overload declarations is only *6 lines long*.
>
> So, my only guess is that the people who looked at that skimmed right
> past it, looking for something
Guido van Rossum wrote:
> On 8/14/06, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
>> On Mon, 14 Aug 2006 09:09:49 -0700, Guido van Rossum <[EMAIL PROTECTED]>
>> wrote:
>>> On 8/14/06, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
This is a joke, right?
>>> Because it's a good idea to have
At 01:13 PM 8/15/2006 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
>
>>It can't be a "separate program altogether", since to get at the
>>annotations, the program must import the module that contains them.
>
>Why? I can imagine something like a documentation
>generator or static type checker t
At 01:19 PM 8/15/2006 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
>
> > The examples there are very short
>>and simple; in fact the complete Message implementation, including
>>imports and overload declarations is only *6 lines long*.
>>So, my only guess is that the people who looked at that s
[Tim Peters]
>> ...
>> When the ctypes docs talk about passing and returning integers, they
>> never explain what "integers" /means/, but it seems the docs
>> implicitly have a 32-bit-only view of the world here. In reality
>> "integer" seems to mean the native C `int` type.
[Thomas Heller]
> 'ct
Guido van Rossum wrote:
>> It would be really nice in the example above to mark ``self`` in
>> ``__call__`` as a positional only argument.
>
> But this is a rather unusual use case isn't it? It's due to the bound
> methods machinery. Do you have other use cases? I would assume that
> normally such
Georg Brandl wrote:
> Guido van Rossum wrote:
>> Implementation Language
>> ==
>>
>> Python 3000 will be implemented in C, and the implementation will be
>> derived as an evolution of the Python 2 code base. This reflects my
>> views (which I share with Joel Spolsky) on the dangers
"Georg Brandl" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Guido van Rossum wrote:
>> Implementation Language
>> ==
>>
>> Python 3000 will be implemented in C, and the implementation will be
>> derived as an evolution of the Python 2 code base. This reflects my
>
On Aug 14, 2006, at 10:01 PM, Nick Coghlan wrote:
> Guido van Rossum wrote:
>> Methinks that as long as PyIntObject uses long (see intobject.h)
>> there's no point in changing this to long.
>
> Those fields are going to have to change to Py_Object* eventually
> if xrange() is going to become th
Alexander Belopolsky wrote:
>
> On Aug 14, 2006, at 10:01 PM, Nick Coghlan wrote:
>
>> Guido van Rossum wrote:
>>> Methinks that as long as PyIntObject uses long (see intobject.h)
>>> there's no point in changing this to long.
>>
>> Those fields are going to have to change to Py_Object* eventuall
Phillip J. Eby wrote:
> How is such a thing going to know what doc("foo") means at the time the
> code is run? What about closures, dynamic imports, etc.?
Annotations intended for such external processors would
have to be designed not to rely on anything dynamic,
i.e. be purely declarative.
Ma
+1
On 8/14/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "Georg Brandl" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > Guido van Rossum wrote:
> >> Implementation Language
> >> ==
> >>
> >> Python 3000 will be implemented in C, and the implementation will be
> >
On 8/14/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> However, I'm also wondering if we need an actual syntax, or if a simple
> convention would do the trick: start the names of positional-only arguments
> with an underscore.
Hm... and perhaps we could forbid keyword arguments starting with an
und
Perhaps this thread can be moved back to python-dev? I'm not sure how
relevant a discussion of the ambiguities in ctypes' docs are for Py3k.
On 8/14/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Tim Peters]
> >> ...
> >> When the ctypes docs talk about passing and returning integers, they
> >> neve
On 8/14/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 1:51 PM 8/14/2006 -0700, "Paul Prescod" <[EMAIL PROTECTED]> wrote:
> >On 8/14/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > > The definition of a type as an annotation should probably be either
> > > defined or explicitly undefined. Earlie
[Steven Bethard]
> It would be really nice in the example above to mark ``self`` in
> ``__call__`` as a positional only argument.
[Nick Coghlan]
> However, I'm also wondering if we need an actual syntax, or if a simple
> convention would do the trick: start the names of positional-only arguments
>
On Mon, Aug 14, 2006, Guido van Rossum wrote:
> On 8/14/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>>
>> However, I'm also wondering if we need an actual syntax, or if a simple
>> convention would do the trick: start the names of positional-only arguments
>> with an underscore.
>
> Hm... and perh
On Aug 14, 2006, at 10:34 PM, Nick Coghlan wrote:
> Alexander Belopolsky wrote:
[snip]
>> Would it make sense to unify rangeobject with PySliceObject?
>
> Not really. The memory layouts may end up being the same in Py3k,
> but they're still different types. The major differences between
> the
Aahz <[EMAIL PROTECTED]> wrote:
>
> On Mon, Aug 14, 2006, Guido van Rossum wrote:
> > On 8/14/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> >>
> >> However, I'm also wondering if we need an actual syntax, or if a simple
> >> convention would do the trick: start the names of positional-only argume
Steven Bethard wrote:
> [Steven Bethard]
>> It would be really nice in the example above to mark ``self`` in
>> ``__call__`` as a positional only argument.
>
> [Nick Coghlan]
>> However, I'm also wondering if we need an actual syntax, or if a simple
>> convention would do the trick: start the name
58 matches
Mail list logo
