On Fri, Aug 24, 2007, Greg Ewing wrote:
> Guido van Rossum wrote:
>>
>> cmp() is still alive and __cmp__ is used to overload it; on the one
>> hand I'd like to get rid of it but OTOH it's occasionally useful.
>
> Maybe you could keep cmp() but implement it in terms of, say, __lt__
> and __eq__?
N
I did some work at last year's Google sprint on removing the simple slicing
API (__getslice__, tp_as_sequence->sq_slice) in favour of the more flexible
sliceobject API (__getitem__ and tp_as_mapping->mp_subscript using slice
objects as index.) For some more detail, see the semi-PEP below. (I hesita
On 8/23/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Yes, I think this would be way cool! I believe there are already a few
> fixers that print messages about things they know are wrong but don't
> know how to fix, those could also be integrated (although arguably
> you'd want those messages t
Thomas Wouters wrote:
> 1) It (passively) promotes supporting only simple slicing,
> as observed by the builtin types only supporting extended
> slicing many years after extended slicing was introduced
Should that read "...only supporting simple slicing..."?
> The proposed solution, as implement
On 8/24/07, Robert Brewer <[EMAIL PROTECTED]> wrote:
> Thomas Wouters wrote:
> > The proposed solution, as implemented in the p3yk-noslice
> > SVN branch, gets rid of the simple slicing methods and
> > PyType entries. The simple C API (using ``Py_ssize_t``
> > for start and stop) remains, but c
On Thu, Aug 23, 2007 at 09:17:04PM -0700, Guido van Rossum wrote:
> On 8/23/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > Gregory P. Smith wrote:
> > > Wasn't a past mailing list thread claiming the bytes type was supposed
> > > to be great for IO? How's that possible unless we add a lock to the
>
On 8/24/07, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> If nobody cares, I will be checking these patches into the trunk this
> weekend (after updating them), and then update and check in the rest of the
> p3yk-noslice branch into the py3k branch.
In the trunk? I'm concerned that that might make i
On 8/23/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > BTW PyUnicode should *not* support the buffer API.
> On 8/23/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Why not? It should set readonly to 1, and format to "u" or "w".
[me again]
> Because the read() method of binary files (a
On 8/24/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On 8/24/07, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> > If nobody cares, I will be checking these patches into the trunk this
> > weekend (after updating them), and then update and check in the rest of
> the
> > p3yk-noslice branch into
Oh, good! Forget what I said about 2.6 then. :-)
On 8/24/07, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>
>
> On 8/24/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 8/24/07, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> > > If nobody cares, I will be checking these patches into the trunk this
On 8/24/07, Robert Brewer <[EMAIL PROTECTED]> wrote:
>
> Thomas Wouters wrote:
>
> > 1) It (passively) promotes supporting only simple slicing,
> > as observed by the builtin types only supporting extended
> > slicing many years after extended slicing was introduced
>
> Should that read "...only s
I started in looking at removing PyArg_Parse. The first module I tackled
was the time module. That was harder than I thought it would be
(PyArg_Parse is only called from one place), in large part I think because
it can take a number of different types of arguments. Is there some
recommended way
skip> I started in looking at removing PyArg_Parse.
Before I go any farther, perhaps I should ask: Is PyArg_Parse going away or
just its use as the argument parser for METH_OLDARGS functions?
Skip
___
Python-3000 mailing list
Python-3000@python.
I'm sending this to the py3k list to make sure the old patch is not used.
Keir
-- Forwarded message --
From: Keir Mierle <[EMAIL PROTECTED]>
Date: Aug 24, 2007 2:20 PM
Subject: [issue1015] [PATCH] Updated patch for rich dict view
(dict().keys()) comparisons
To: [EMAIL PROTECTED]
I think that's a question for Martin von Loewis. Are there any
existing uses (in the core) that are hard to replace with
PyArg_ParseTuple()?
On 8/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> skip> I started in looking at removing PyArg_Parse.
>
> Before I go any farther, perhaps I s
We ought to clean up the profiling modules. There was a long
discussion about this here:
http://mail.python.org/pipermail/python-dev/2005-November/058212.html
Much of the discussion revolved around whether to add lsprof in the
stdlib. That's been resolved. It was added. Now what do we do?
I
I'm still a happy user of profile.py, so I'm probably not the right
one to drive this discussion. :-)
On 8/24/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> We ought to clean up the profiling modules. There was a long
> discussion about this here:
>
> http://mail.python.org/pipermail/python-dev/20
Guido> Are there any existing uses (in the core) that are hard to
Guido> replace with PyArg_ParseTuple()?
There are lots of uses where the arguments aren't tuples. I was
particularly vexed by the time module because it was used to extract
arguments both from tuples and from time.struct_t
Neal> The hotshot doc states:
Neal> Note
Neal> The hotshot module focuses on minimizing the overhead while
Neal> profiling, at the expense of long data post-processing times. For
Neal> common usages it is recommended to use cProfile instead. hotshot
Neal> is not maintaine
On 8/24/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> I suggest merging profile and cProfile (which uses _lsprof) similar to
> how stringio and pickle are being merged.
cProfile and profile.py are on my merge to-do. I was supposed to merge
cProfile/profile.py as part of my GSoC, but stringio and p
On 8/24/07, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote:
> On 8/24/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> > I suggest merging profile and cProfile (which uses _lsprof) similar to
> > how stringio and pickle are being merged.
>
> cProfile and profile.py are on my merge to-do. I was suppose
Guido van Rossum wrote:
> there's collusion between the bytes and unicode
> types so that this works:
>
> b = b"abc"
> b[1:2] = "X"
Is this intentional? Doesn't it run counter to the idea
that text and bytes should be clearly separated?
> Unfortunately taking the buffer API away from unicode
On 8/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Guido> Are there any existing uses (in the core) that are hard to
> Guido> replace with PyArg_ParseTuple()?
>
> There are lots of uses where the arguments aren't tuples. I was
> particularly vexed by the time module because it wa
On 8/24/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > there's collusion between the bytes and unicode
> > types so that this works:
> >
> > b = b"abc"
> > b[1:2] = "X"
>
> Is this intentional? Doesn't it run counter to the idea
> that text and bytes should be clearly s
Guido van Rossum wrote:
> Then I don't think it's a priority to try to get rid of it, and maybe
> it should just stay.
Maybe it should be renamed to reflect the fact that
it's now general-purpose and no longer used at all
for argument parsing? Perhaps PyObject_Parse?
--
Greg
_
Per Guido, I've checked a slightly different version of this patch in to
the py3k branch as revision 57444. The primary difference is that I
modified sysmodule.c and unicodeobject.c to start implementing the
string.Formatter class.
Should I mark the original patch as closed in the tracker?
Er
On 8/24/07, Eric Smith <[EMAIL PROTECTED]> wrote:
> Per Guido, I've checked a slightly different version of this patch in to
> the py3k branch as revision 57444. The primary difference is that I
> modified sysmodule.c and unicodeobject.c to start implementing the
> string.Formatter class.
Great!
On 8/24/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> > Guido> Are there any existing uses (in the core) that are hard to
> > Guido> replace with PyArg_ParseTuple()?
> >
> > There are lots of uses where the arguments aren't
I see in PEP 358 (bytes) http://www.python.org/dev/peps/pep-0358/ that
marshalling bytes is an open issue and needs to be specified. I'm
converting code objects to use bytes for the bytecode and lnotab. Is
there anything special to be aware of here? It seems like it can be
treated like an non-in
On 8/24/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> I see in PEP 358 (bytes) http://www.python.org/dev/peps/pep-0358/ that
> marshalling bytes is an open issue and needs to be specified. I'm
> converting code objects to use bytes for the bytecode and lnotab. Is
> there anything special to be aw
> Then I don't think it's a priority to try to get rid of it, and maybe
> it should just stay.
I think it would be desirable to get rid of METH_OLDARGS. Ideally, this
should already be possible, as all modules should have been changed to
be explicit about their usage of METH_OLDARGS (rather than r
On 8/24/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> Adrian and I talked about this this morning, and he said he's going to
> go ahead with an implementation. The original warning messages were a
> good idea, but they tend to get lost when converting large projects.
(I assume this is the place t
Barry Warsaw writes:
> I've been spending hours of my own time on the email package for py3k
> this week and every time I think I'm nearing success I get defeated
> again.
I'm ankle deep in the Big Muddy (daughter tested positive for TB as
expected -- the Japanese innoculate all children a
33 matches
Mail list logo
