Attached is my revised PEP for the buffer protocol after incorporating
suggestions from Greg Ewing. It is as simple as I can make it and
still share what I think needs to be sharable. Suggestions are
welcome. I will provide and maintain code to implement the PEP when
the basic idea of t
"Travis E. Oliphant" <[EMAIL PROTECTED]> wrote:
> abstractly as if it were. I believe, the PIL is where the idea of
> multiple buffer segments in the original buffer interface came
> from, I believe.
Remove the last "I believe" in that sentence and remove the commas. ;)
> The buf
On 3/19/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I've added two new fixers to 2to3 this weekend, plus significant new
> functionality for a third:
>
> * fix_next handles the it.next() -> next(it) transition for PEP 3114.
> * fix_nonzero converts __nonzero__ to __bool__ methods, as
Josiah Carlson wrote:
> "Travis E. Oliphant" <[EMAIL PROTECTED]> wrote:
>> abstractly as if it were. I believe, the PIL is where the idea of
>> multiple buffer segments in the original buffer interface came
>> from, I believe.
>
> Remove the last "I believe" in that sentence and remove
Nick Coghlan wrote:
> I think the point is for there to be something in the standard library
> or Python core that makes it easy for a consumer to *copy* the data to a
> contiguous memory segment in the event the consumer can't directly
> handle non-contiguous data
It would be even more useful
Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > "Travis E. Oliphant" <[EMAIL PROTECTED]> wrote:
> >> The buffer interface should allow discontiguous memory areas to
> >> share standard striding information. However, consumers that do
> >> not want to deal with stri
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> Nick Coghlan wrote:
>
> > I think the point is for there to be something in the standard library
> > or Python core that makes it easy for a consumer to *copy* the data to a
> > contiguous memory segment in the event the consumer can't directly
> > ha
I just discovered that the p3yk/ branch can't do a docs build because
almost none of the code in Doc/tools/ is valid Python 3 [1]. How hard
would it be to set up something akin to http://docs.python.org/dev/
for p3yk (ie, regular, automated builds), if only to catch problems
like this sooner?
Coll
On 3/20/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> I just discovered that the p3yk/ branch can't do a docs build because
> almost none of the code in Doc/tools/ is valid Python 3 [1]. How hard
> would it be to set up something akin to http://docs.python.org/dev/
> for p3yk (ie, regular, automat
Quoting from the commit message for r51533, which removed the default ordering:
"""
A general problem with getting lots of these tests to pass is
the reality that for object types that have a natural total ordering,
implementing __cmp__ is much more convenient than implementing
__eq__, __ne__, __l
I haven't taken any action, and it looks like __cmp__ isn't being
called. I'd rather not add it back; if you want it back, could you at
least write up a brief PEP? A patch would also help; I recall that it
was quite a relief being able to cut it out, so I expect that patching
it back in would be qu
"Collin Winter" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Quoting from the commit message for r51533, which removed the default
ordering:
|
| What's the status on this? FWIW, I would like to see __cmp__ stay as a
| fallback measure if __eq__, __ne__, __lt__, etc aren't define
But can this work? It might end up calling cmp() on two incomparable
objects. For __lt__ etc. that might be the right answer, but for
__eq__ it is *not* -- the default __eq__ and __ne__ *must* compare
object identity.
(What is this __cmp you refer to? A typo for __cmp__ or for cmp?)
--Guido
On 3
On 3/20/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> Quoting from the commit message for r51533, which removed the default
> ordering:
>
> """
> A general problem with getting lots of these tests to pass is
> the reality that for object types that have a natural total ordering,
> implementing __
How would that produce the desired behavior that == and != are defined
on all objects, but <, <=, >= and > are not? We're quickly approaching
python-ideas land... :)
On 3/20/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 3/20/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> > Quoting from the co
On 3/20/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I haven't taken any action, and it looks like __cmp__ isn't being
> called. I'd rather not add it back; if you want it back, could you at
> least write up a brief PEP? A patch would also help; I recall that it
> was quite a relief being able
http://docs.python.org/dev/3.x/
will be updated every hour.
http://docs.python.org/dev/3.x/results/
contains the results of the last build.
n
--
On 3/20/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> I just discovered that the p3yk/ branch can't do a docs build because
> almost none of the cod
On 3/20/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> http://docs.python.org/dev/3.x/
>
> will be updated every hour.
>
> http://docs.python.org/dev/3.x/results/
>
> contains the results of the last build.
Woohoo! Thanks, Neal!
___
Python-3000 mailing li
On 3/20/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 3/20/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > I haven't taken any action, and it looks like __cmp__ isn't being
> > called. I'd rather not add it back; if you want it back, could you at
> > least write up a brief PEP? A patch woul
On 3/20/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> I've used a __key__() method quite successfully in my own code. Maybe
> we should provide a mixin like::
>
> class KeyedComparisonMixin(object):
> def __eq__(self, other):
> return self.__key__() == other.__key__()
[sn
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| But can this work? It might end up calling cmp() on two incomparable
| objects. For __lt__ etc. that might be the right answer, but for
| __eq__ it is *not* -- the default __eq__ and __ne__ *must* compare
| object id
regrtest.py -R 4:3: # on 64-bit, but that might only affect the xpickle error
test_grammar leaked [14, 14, 14] references
test_doctest leaked [84, 84, 84] references
test_ctypes leaked [13, 13, 13] references
test_descrtut leaked [417, 417, 417] references
test_generators leaked [227, 227, 227] r
I'm pretty sure I introduced leaks with the new metaclass code; it was
a bit of a rush job and there's plenty of new C code. I need a hint on
how to reproduce this myself for a single test...
On 3/20/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> regrtest.py -R 4:3: # on 64-bit, but that might onl
That was mostly the first line of my message, although it was a bit terse. :-)
It's just a cmd line option to regrtest.py -R 4:3:
Everything else is the same.
The way I run it for test_grammar:
./python -E -tt ./Lib/test/regrtest.py -R 4:3: test_grammar
You can also pass "-R ::" instead of "-R
24 matches
Mail list logo
