On Thu, 2006-03-30 at 13:09 -0500, Raymond Hettinger wrote:
> Please leave this one alone. I still need to work on this part of the API
> and
> do not currently have the spare clock cycles to do it right now. You don't
> HAVE
> to jam something in right away. Please let it continue to cook
>> The idea is not yet ready for prime-time. If I do it for one of the named
>> operations, I will do it for all (to keep the interface uniform).
> Which named operations are you thinking of?
s.union(t), s.intersection(t), s.difference(t), s.symmetric_difference(t),
s.update(t), s.intersection
On Wed, 2006-03-29 at 23:09 -0500, Raymond Hettinger wrote:
> Yes, _PySet_Next() is a good compromise for you and me -- it saves you from
> writing a hack and saves my API from including a bug factory. The only issue
> is
> that Martin thinks it to be a crummy idea. Personally, I have no prob
Raymond Hettinger wrote:
> Yes, _PySet_Next() is a good compromise for you and me -- it saves you from
> writing a hack and saves my API from including a bug factory. The only issue
> is
> that Martin thinks it to be a crummy idea.
If it makes everyone happy, I shouldn't be in the way. Of cour
[Raymond Hettinger]
> > Barry, go ahead with PySet_Clear().
[Barry]
Cool thanks. I think we've also compromised on _PySet_Next(), correct?
Yes, _PySet_Next() is a good compromise for you and me -- it saves you from
writing a hack and saves my API from including a bug factory. The only issue
i
On Mar 27, 2006, at 7:20 AM, Raymond Hettinger wrote:
> Why don't we expose _PySet_Next() for Barry and leave it out of the
> public API
> for everyone else.
There are precedents for adding some functionality to the C API but
not documenting it to ensure "non advanced users" don't get hurt -
Barry Warsaw wrote:
> On Wed, 2006-03-29 at 16:29 -0500, Raymond Hettinger wrote:
>
>>The story is different for PySet_Update(). Defining it now could get in the
>>way
>>of possible future development for the module (the function may end-up taking
>>a
>>variable length argument list instead o
On Wed, 2006-03-29 at 19:34 -0500, Barry Warsaw wrote:
> On Wed, 2006-03-29 at 16:29 -0500, Raymond Hettinger wrote:
>
> > The story is different for PySet_Update(). Defining it now could get in
> > the way
> > of possible future development for the module (the function may end-up
> > taking a
On Wed, 2006-03-29 at 16:29 -0500, Raymond Hettinger wrote:
> The story is different for PySet_Update(). Defining it now could get in the
> way
> of possible future development for the module (the function may end-up taking
> a
> variable length argument list instead of a single argument).
S
On Tue, 2006-03-28 at 22:20 -0800, Raymond Hettinger wrote:
> Barry, go ahead with PySet_Clear().
Cool thanks. I think we've also compromised on _PySet_Next(), correct?
I'll follow up on PySet_Update() in a moment.
-Barry
signature.asc
Description: This is a digitally signed message part
[Gareth McCaughan]
> For what it's worth[1], I think Raymond is absolutely on crack here.
Nope. No mind-altering drugs here. Based on real-word experience, I have
found
PySet_Next() to be a bug factory and do not want it included in the API.
The story is different for PySet_Update(). Definin
On Mar 29, 2006, at 1:38 PM, Martin v. Löwis wrote:
> Given that Barry insists so firmly that there is a need, and that
> this need arises from a significant code simplification that can
> be achieved through the API, the natural conclusion is to add
> the API. That, of course, assumes that you bel
Gareth McCaughan wrote:
> However: if Raymond, or anyone else, is offended, then I'm sorry.
> Now, what about the technical issues, as opposed to the way I
> happened to introduce my comments?
Proposing that a certain API in an open source project is introduced
for a single "customer" is indeed a
Terry Reedy wrote:
[me:]
> >> For what it's worth[1], I think Raymond is absolutely on crack here.
[Greg Ewing:]
> > +1 on a good concrete set API from me, too.
[Terry:]
> For what it's worth, I think Gareth's crack at Raymond is childish and out
> of place here.
Er, it wasn't a crack at Raymo
Barry, go ahead with PySet_Clear().
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Gareth McCaughan wrote:
>
>> For what it's worth[1], I think Raymond is absolutely on crack here.
>
> +1 on a good concrete set API from me, too.
For what it's worth, I think Gareth's crack at Raymond is childish and out
Gareth McCaughan wrote:
> For what it's worth[1], I think Raymond is absolutely on crack here.
+1 on a good concrete set API from me, too. Being such
similar types, sets should have about the same API richness
as dicts, IMO.
--
Greg
___
Python-Dev mai
Barry Warsaw wrote:
> "Perhaps the PySet API can raise an error if it's ever called on
> something that's not *exactly* a set? No subclassing allowed.
> Shouldn't affect you, and should be an effective deterrent against
> abuse of the kind that made the PyDict API an albatross."
And perhaps in Py
Excerpting...
On Tue, 2006-03-28 at 14:07 +, Gareth McCaughan wrote:
> * Simple API:
>
> API complexity is measured in brain cells, not in methods.
>
> * Ease of making mistakes:
>
> The Python API is absolutely stuffed with places where you can go wrong
> by forgetting about subtle refcou
On Mon, 2006-03-27 at 23:53 -0800, Raymond Hettinger wrote:
> While I don't favor the proposed API, I think is essential that
> you not be left hanging without good options.
Thank you. So where does this leave us?
BTW, Guido made a suggestion in private email (which he okayed to
mention publicl
On Tue, 2006-03-28 at 17:28 +1200, Greg Ewing wrote:
> Barry Warsaw wrote:
> > My PySet_Clear() raises a SystemError
> > and returns -1 when the object is a frozen set.
>
> Isn't SystemError a bit drastic? TypeError would be
> sufficient here, surely.
Possibly, but all the other PySet_*() functio
> We're clearly going in circles here, and it's obvious we're not going to
> agree.
>
> The fact that PySet_Next() can be used incorrectly is no reason not to
> include it.
[etc]
For what it's worth[1], I think Raymond is absolutely on crack here.
[1] Not necessarily very much. There is no
>> Thank would be nice. It gives me the ability to keep a clean, sane API
>> while
>> at
>> the same time making sure that my most important customer (Barry) gets his
>> needs
>> met.
> I'm having a hard time deciphering whether you're being condescending or
> trying to be funny. I'm going to
Greg Ewing wrote:
> Hmmm, the problem here, I think, is that tp_clear is
> really only designed for use by the garbage collector.
> Giving anything else access to it is probably wrong.
>
> Clearability is not a general feature in Python land --
> a few types have a clear() method, but this is an
>
Barry Warsaw wrote:
> My PySet_Clear() raises a SystemError
> and returns -1 when the object is a frozen set.
Isn't SystemError a bit drastic? TypeError would be
sufficient here, surely.
>
> If PyObject_Clear() is implemented something like
>
> int PyObject_Clear(PyObject *o)
> {
> return (o
On Mon, 2006-03-27 at 23:21 +0200, "Martin v. Löwis" wrote:
> Raymond Hettinger wrote:
> > Why don't we expose _PySet_Next() for Barry and leave it out of the public
> > API
> > for everyone else.
>
> That is stupid. If Barry wants a "private" PySet_Next function, he can
> just implement it hims
On Mon, 2006-03-27 at 10:20 -0500, Raymond Hettinger wrote:
> Why don't we expose _PySet_Next() for Barry and leave it out of the public
> API
> for everyone else.
Just so I understand exactly what you mean by "leave it out of the
public API", let me ask: are you saying you don't want to documen
On Sat, 2006-03-25 at 22:05 -0500, Raymond Hettinger wrote:
> Still, PyObject_Clear(s) would be better.
Although not ideal, in the interest of compromise, I could support this
option. There's a problem with this though: I don't think you want to
be able to clear a frozen set. My PySet_Clear()
Barry Warsaw wrote:
> We're clearly going in circles here, and it's obvious we're not going to
> agree.
Would it perhaps help if there were a better API for
using the iterator protocol from C code? Something
that's as easy to use as the proposed set iterating
API, but which uses the general ite
Raymond Hettinger wrote:
> Why don't we expose _PySet_Next() for Barry and leave it out of the public
> API
> for everyone else.
That is stupid. If Barry wants a "private" PySet_Next function, he can
just implement it himself, no need to include it in the release. It
should be included only if i
>> Why don't we expose _PySet_Next() for Barry and leave it out of the public
>> API
>> for everyone else.
[Alex]
> There are precedents for adding some functionality to the C API but not
> documenting it to ensure "non advanced users" don't get hurt -- that's how
> we
> added the ability t
Why don't we expose _PySet_Next() for Barry and leave it out of the public API
for everyone else.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman
On Sun, 2006-03-26 at 11:43 -0500, Raymond Hettinger wrote:
> It was a trick question. Everyone is supposed to be attracted to the _next
> version because it is shorter, faster, and takes less ref counting
> management.
> However, the _next version has a hard-to-find bug. The call to
> PyObj
[Alex]
> Sure, accidentally mutating underlying iterables is a subtle (but alas
> frequent) bug, but I don't see why it should be any harsher when the loop is
> using a hypothetical PySet_Next than when it is using PyIter_Next --
> whatever
> precautions the latter takes to detect the bug a
On Mar 26, 2006, at 8:43 AM, Raymond Hettinger wrote:
> [Aahz]
>> Speaking as a person who does relatively little C programming, I
>> don't
>> see much difference between them. The first example is more
>> Pythonic --
>> for Python. I agree with Barry that it's not much of a virtue for C
>>
[Aahz]
> Speaking as a person who does relatively little C programming, I don't
> see much difference between them. The first example is more Pythonic --
> for Python. I agree with Barry that it's not much of a virtue for C
> code.
It was a trick question. Everyone is supposed to be attracted t
On Sun, Mar 26, 2006, Raymond Hettinger wrote:
> [Alex]
>>
>> And I'm on the fence regarding the specific issue of PySet_Next.
>>
>> So, having carefully staked out a position smack in the middle, I
>> cheerfully now expect to be fired upon from both sides!-)
>
> Okay, here's the first cheap sho
[Alex]
> And I'm on the fence regarding the specific issue of PySet_Next.
>
> So, having carefully staked out a position smack in the middle, I
> cheerfully now expect to be fired upon from both sides!-)
Okay, here's the first cheap shot ;-) Which of the following pieces of code is
preferable?
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
[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
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
[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 kept intact and there is no confusion
> between
> PyNumber_InPlaceAd
[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?
> Would you argue that Python 3.0's C API be stripped of everything but
> the
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?
Would you argue that Python 3.0's C API be stripped of everything but
the abstract API and
[Raymond]
>> What are you proposing to add to the PySet API?
[Barry]
> PySet_Clear(), PySet_Next(), PySet_Update(), and PySet_AsList().
PySet_Clear()
-
Use PyObject_CallMethod(s, "clear", NULL).
Or if you need to save a millisecond on an O(n) operation, use
PyNumber_InPlaceSubtract(
On Sat, 2006-03-18 at 19:22 -0500, Raymond Hettinger wrote:
> > [Barry Warsaw]
> >> Oh, also, we have a couple of additions to the PySet C API.
> >> I'll work on putting together an SF patch for them over the weekend.
>
> What are you proposing to add to the PySet API?
PySet_Clear(), PySet_Next()
> [Barry Warsaw]
>> Oh, also, we have a couple of additions to the PySet C API.
>> I'll work on putting together an SF patch for them over the weekend.
What are you proposing to add to the PySet API?
I designed an API that was both minimal and complete. The idea was to provide
direct access to
49 matches
Mail list logo
