Hi,
Collin Winter wrote:
> def compile(source: "something compilable",
> filename: "where the compilable thing comes from",
> mode: "is this a single statement or a suite?"):
> ...
>
> def sum(*vargs: Number) -> Number:
>
Paul Prescod wrote:
> 2. If not, will Python 3000's build or runtime system use some kind of
> optimization technique such as static compilation ( e.g. extcompiler[1])
> or JIT compilation to allow parts of its library (especially new parts)
> to be written using ctypes instead of C?
What's the
I've never seen bugs determined by operations such as:
"foobar" * -1
and to be honest I've never seen code like that because the semantics
is somewhat senseless to me but I think the behavior of the expression
evaluation of "Sequence * negative integer" should be changed from:
>>> "foobar" * -1
Ivan Krstic wrote:
> 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
Lawrence Oluyede wrote:
> I've never seen bugs determined by operations such as:
>
> "foobar" * -1
>
> and to be honest I've never seen code like that because the semantics
> is somewhat senseless to me but I think the behavior of the expression
> evaluation of "Sequence * negative integer" shoul
> The "negative coerced to 0" behaviour is to make it easy to do things like
> padding a sequence to a minimum length:
>
>seq = seq + pad * (min_length- len(seq))
>
> Without the current behaviour, all such operations would need to be rewritten
> as:
>
>seq = seq + pad * max((min_length- l
Stefan Behnel wrote:
> Collin Winter wrote:
>> def compile(source: "something compilable",
>> filename: "where the compilable thing comes from",
>> mode: "is this a single statement or a suite?"):
>> ...
>>
>> def sum(*vargs: Num
Lawrence Oluyede wrote:
> seq * -5
> and to be honest I've never seen code like that because the semantics
> is somewhat senseless to me
To be honest, I would almost expect the negative to mean "count from
the end", so that it also reversed the sequence. It doesn't, but ...
it does make for a ha
Jim Jewett wrote:
> I would write it as
>
> # Create a record-size pad outside the loop
> pad = " "*length
> ...
>seq = (seq+pad)[:length]
I'd generally do padding to a fixed length that way as well, but any code
relying on the current 'clip to 0' behaviour would break if this changed.
With
On Thu, 10 Aug 2006 10:13:14 -0400
Jim Jewett <[EMAIL PROTECTED]> wrote:
#> >seq = seq + pad * (min_length- len(seq))
#>
#> Typically, if I need to pad a sequence to a minimum length, I really
#> need it to be a specific length. Having it already be too long is
#> likely to cause problems la
I worry that this may be too ambitious to add to the already
significant load for the Py3k project. You've seen my timeline --
alpha in early 07, final a year later.
Don't get me wrong! I think that completely changing the FFI paradigm
(as opposed to evolutionary changes to the existing C API, whi
I haven't changed my mind. Do you really want to add atrocities such
as having both .. and ... in the language where one includes the end
point and the other excludes it? How would a casual user remember
which is which?
--Guido
On 8/8/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> Talin <[EMAI
On 8/4/06, Ron Adam <[EMAIL PROTECTED]> wrote:
> But that doesn't explain why int, long, and float, don't have other
> non-magic methods.
>
> I'm not attempting taking sides for or against either way, I just want
> to understand the reasons as it seems like by knowing that, the correct
> way to do
[Tim]
> Me too, although it won't stay that simple, and I'm clear as mud on
> how implementations other than CPython could implement this.
[Guido]
> Another good reason to keep it accessible from the C API only. Now I'm
> -0 on adding it. I suggest that if someone really wants this
> accessible fr
[back and forth on PyThreadState_SetAsyncExc(), and
the 2-year old discussion in
http://www.python.org/sf/1069160
]
[Tim]
>> [still-current deadlock & refcount issues not fixed at the time]
[Guido]
> So why didn't we check that in?
The shallow answer is that you closed the report without chec
(Adding python-3000 back to the CC: list.)
On 8/10/06, Paul Prescod <[EMAIL PROTECTED]> wrote:
> The only reason to tie it to Py3K is because Py3K is breaking APIs anyhow.
> It will be in the overlap period between Py3K and Py2x that the need for an
> abstraction will be most acute. Otherwise exte
On 8/10/06, tomer filiba <[EMAIL PROTECTED]> wrote:
> [Tim]
> > Me too, although it won't stay that simple, and I'm clear as mud on
> > how implementations other than CPython could implement this.
>
> [Guido]
> > Another good reason to keep it accessible from the C API only. Now I'm
> > -0 on addin
Sorry for the cc mistake.I don't know enough about ctypes, but assuming I have a reason to
write an extension in C (e.g. Tkinter, which uses the Tcl/Tk API), howto I use ctypes to call things like PyDict_GetItem() orPyErr_SetString()?There are two answers to your question. The simplest is that if y
And if you're curious about how to use ctypes without all of the helper functions set up for you, then I guess it is easiest to poke around the documentation for code samples.>>> printf.argtypes = [c_char_p, c_char_p, c_int, c_double]
>>> printf("String '%s', Int %d, Double %f\n", "Hi", 10, 2.2)Str
On 8/10/06, Paul Prescod <[EMAIL PROTECTED]> wrote:
> > I don't know enough about ctypes, but assuming I have a reason to
> > write an extension in C (e.g. Tkinter, which uses the Tcl/Tk API), how
> > to I use ctypes to call things like PyDict_GetItem() or
> > PyErr_SetString()?
>
> There are two a
Paul Prescod wrote:
> 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:
What's the state of play concerning ctypes support
on non-x86 platforms?
Until ct
Yes, I also wonder about how non-CPython implementations would handle
this but I'd just like to say that this feature, making a thread raise
a specific exception from another thread asynchronously is a very
useful feature.
We have a subsystem that schedules requests that are dispatched in a
thread
Another thought about ctypes: What if you want to pass
a Python function into C as a callback? Does ctypes
have a way of handling that?
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiem! |
Christ
Collin Winter wrote:
> The idea is that each developer can pick the notation/semantics that's
> most natural to them. I'll go even further: say one library offers a
> semantics you find handy for task A, while another library's ideas
> about type annotations are best suited for task B. Without a si
Nick Coghlan wrote:
> Given the time frame, I think you might be stuck with using ctypes to
> get at the functionality for Python 2.5.
That's probably no worse a way to do it than calling an underscored
CPython function; I keep forgetting we're getting out-of-the-box ctypes
goodness in 2.5.
--
Greg Ewing schrieb:
> Another thought about ctypes: What if you want to pass
> a Python function into C as a callback? Does ctypes
> have a way of handling that?
>
Sure. The tutorial has an example that calls qsort with a Python
comparison function:
http://docs.python.org/dev/lib/ctypes-callback
26 matches
Mail list logo
