On Mar 25, 2006, at 9:57 PM, Aahz wrote:
> I'd really like to see someone else who understands the issues (i.e.
> using the Python C-API) weigh in. Both Barry and Raymond are clever
> programmers who generally understand what's Pythonic, and I find
> myself
> agreeing with whoever posted last.
I'd really like to see someone else who understands the issues (i.e.
using the Python C-API) weigh in. Both Barry and Raymond are clever
programmers who generally understand what's Pythonic, and I find myself
agreeing with whoever posted last. ;-) Having another perspective
would probably shed s
When Python's small-object memory allocator was introduced, some
horrid hacks came with it to map PyMem_{Del, DEL} and PyMem_{Free,
FREE} to PyObject_{Free, FREE}. This was to cater to less than a
handful of extension modules found at the time that obtained memory
for an object via PyObject_{New,
[Barry]
> Maybe it will help you to understand why I want a richer concrete API.
> I work on an app that is deeply integrated with Python. It's hard to
> say whether we embed or extend -- it's a lot of both. We use Python
> data structures such as lists, dicts, and sets in many places as our
> fu
Guido van Rossum wrote:
> On 3/25/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> The kind of code I'm talking about would be an *existing* Python 2.4
>> generator
>> that happens to do something like:
>>
>>def gen(tasks):
>>"""yield the results of a bunch of task functions"""
>>
On Mar 25, 2006, at 8:13 PM, Greg Ewing wrote:
> There seems to be a need for better diagnostics
> when pickle encounters something that can't be
> pickled.
>
> Recently when attempting to pickle a rather
> large and complicated data structure, I got
> the following incomprehensible message:
>
>
There seems to be a need for better diagnostics
when pickle encounters something that can't be
pickled.
Recently when attempting to pickle a rather
large and complicated data structure, I got
the following incomprehensible message:
cPickle.PicklingError: args[0]
from __newobj__ args has t
On Tue, 2006-03-21 at 22:01 -0500, Raymond Hettinger wrote:
> [Me]
> > There is a semantic difference between
> > code like s+=t and s.update(t). The former only works when t is a set
> > and the latter works for any iterable. When the C code corresponds to
> > the Python code, that knowledge is
On Tue, 2006-03-21 at 21:31 -0500, Raymond Hettinger wrote:
> [Barry]
> > Is it your intent to push for more use of the abstract API instead of
> > the concrete APIs for all of Python's C data structures? Current API
> > aside, are you advocating this approach for all new built-in types?
> > Woul
On 3/25/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> The kind of code I'm talking about would be an *existing* Python 2.4 generator
> that happens to do something like:
>
>def gen(tasks):
>"""yield the results of a bunch of task functions"""
>for task in tasks:
>try
>> I can't see all that much use for GeneratorExit in code that needs to
>> be compatible with 2.4, since the rest of the machinery that makes
>> exception handling around yield feasible doesn't exist.
>
> I agree entirely - my goal is to make sure it stays that way.
>
> The kind of code I'm talkin
Guido van Rossum wrote:
> On 3/25/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> OTOH, if GeneratorExit inherits from Exception (as in current SVN), then two
>> things will be needed to make the generator work correctly:
>>
>> 1. add a preceding exception clause to fix Python 2.5 behaviour:
>>e
On 3/25/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> The last comment I heard from Guido on this topic was that he was still
> thinking about it.
Not exactly. I'm delegating the thinking mostly to others.
> However, I now have an additional data point - if GeneratorExit inherits
> directly from
Nick Coghlan wrote:
> Should GeneratorExit inherit from Exception or BaseException?
>
> Currently, a generator that catches Exception and continues on to yield
> another value can't be closed properly (you get a runtime error pointing out
> that the generator ignored GeneratorExit).
>
> The onl
14 matches
Mail list logo
