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 problem
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),
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 and
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
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 Raymond, it
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
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
[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().
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
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).
So
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 of a single
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 --
[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
is
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 course,
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 none
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_*() functions call
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
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 refcounting
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 Py3k
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
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
of place
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
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:
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 to raise
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 it is
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
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:
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
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
ad
[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 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 shot ;-) Which
[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 to
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
code.
It
[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 and
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 kept
[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
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
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.
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
[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
[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
[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(s,s)
42 matches
Mail list logo
