Question about consistency in python language

[Kay Schluehr]

Just because you aren't aware of something doesn't stop it being true.
The argument must be iterable, and there's a specific protocol for that.
Ah, so you *were* aware of it.

I already responded to it two days ago in the reply to Terry. No need
to rehash that.

The advantage being ... ? Perhaps you have just discovered a really
interesting hammer, and are seeing this problem as a nail?

I also responded to traits as nice-to-have but not essential. And
please don't aggressively consider me as childish as you might be
yourself.

Adding a __traits__ attribute should enable the user adding methods to
builtins in a safe manner. This has the advantage that one can apply
methods to string or integer literals or even replace methods without
touching the C sources. A very typical use case is integer
representation. In 95% of all my business applications I don't have
much use for decimal integer representation but want a hex rep in
different variants:

15

02 BC

I know I can write wrapper classes, because I do this all the time, but
that's not the point: Python is essentially not about boiler-plate. And
no, I also don't want to fight for each method and keyword with Guido.

That would indeed be a naïve implementation.

And that's the real implementation:

static PyObject *
builtin_sorted(PyObject *self, PyObject *args, PyObject *kwds)
{
PyObject *newlist, *v, *seq, *compare=NULL, *keyfunc=NULL, *newargs;
PyObject *callable;
static char *kwlist[] = {"iterable", "cmp", "key", "reverse", 0};
long reverse;

if (args != NULL) {
if (!PyArg_ParseTupleAndKeywords(args, kwds, "O|OOi:sorted",
kwlist, &seq, &compare, &keyfunc, &reverse))
return NULL;
}

newlist = PySequence_List(seq);
if (newlist == NULL)
return NULL;

callable = PyObject_GetAttrString(newlist, "sort");
if (callable == NULL) {
Py_DECREF(newlist);
return NULL;
}

newargs = PyTuple_GetSlice(args, 1, 4);
if (newargs == NULL) {
Py_DECREF(newlist);
Py_DECREF(callable);
return NULL;
}

v = PyObject_Call(callable, newargs, kwds);
Py_DECREF(newargs);
Py_DECREF(callable);
if (v == NULL) {
Py_DECREF(newlist);
return NULL;
}
Py_DECREF(v);
return newlist;
}


The crucial steps are the conversion from args to seq, the conversion
from seq to newlist and finally calling PyObject_Call(callable, ...)
where callable stores the sort method of newlist. By the way I don't
see much use in implementing this trivial wrapper function in C except
for the joy of refcounting

And now we take a look on how the PyPythonistas implemented sorted():

def sorted(lst, cmp=None, key=None, reverse=None):
"sorted(iterable, cmp=None, key=None, reverse=False) --> new sorted
list"
sorted_lst = list(lst)
sorted_lst.sort(cmp, key, reverse)
return sorted_lst

Surprise, surprise!

The implementation is, of
course, an implementation detail ;-) In this case it requires that
sort() then provides all the magic - the need for magic doesn't go away!

Has anyone denied the necessaty of sort()?

Kay

 

[Robert Kern]

James wrote:

[James Stroud wrote:]

I have seen the same warnning above significantly several times.
Is this problem originally came from the similarities between 'l' and
'1'
or from bad looking news-browser?
Forgive me if it is out of your interests.

In many, many fonts 'l' and '1' look close enough to be easily mistaken
for one another, especially for people whose vision isn't perfect. The
problem exists in the fonts people view and edit code with, not just
newsreaders.

--
Robert Kern
(e-mail address removed)

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

 

[Terry Reedy]

In many, many fonts 'l' and '1' look close enough to be easily mistaken
for one another

In the default font used by Outlook Express, displayed on my 1078x786
screen, the only difference I can see, using a magnifying glass on
side-by-side characters (l1 = el-onel), is that 'el' is one pixel taller
than the 'one'. The serifs appear the same, down to the anti-alias gray
pixels. (To my surprise, this makes 'lbdk' a pixel taller than uppercase
chars!) Now I know ;-). But 1 isolated from l is still difficult to
distinguish.

Terry J. Reedy