Mailman 3 April 2007 - Python-Dev

Python-Dev Summary Draft (April 1-15, 2007)
by Calvin Spealman April 24, 2007

April 24, 2007

There were a good number of skipped threads, but I've been out of the loop with a lot of busy things keeping me away from such things. Now that I'm getting back into it, I'll keep up with things again. So, let me know if any of the skipped threads should be brought in. Corrections and comments welcome as always. ============= Announcements ============= ========= Summaries ========= --------------- About SSL tests --------------- An open bug about missing SSL tests (#451607) was brought up … [View More]

4 5

Tweaking the stdlib test infrastructure
by Collin Winter April 24, 2007

April 24, 2007

Fast and simple: I want all stdlib test cases to stop subclassing unittest.TestCase and start subclassing test_support.TestCase. Why: With a single parent class common to the entire stdlib, adding new functionality/testing instruments to *every single test at once* becomes trivial. One example would be to move "regrtest -R"'s focus from module-level refleaks to test case-level refleaks (that is, looped execution of individual test cases, rather than test modules). I intend to implement this … [View More]

6 7

Re: [Python-Dev] Clarifications for import PEPs (302 and 328)
by Phillip J. Eby April 24, 2007

April 24, 2007

At 04:23 PM 4/23/2007 -0700, Brett Cannon wrote: >On 4/23/07, Phillip J. Eby <pje(a)telecommunity.com> wrote: > > At 03:16 PM 4/23/2007 -0700, Brett Cannon wrote: > > >The PEP does not explicitly state how to signal that a loader cannot > > >load a module it is asked to. This could happen if someone called a > > >loader without consulting its respective importer. I would want to > > >add something like: > > >""" > > >If the … [View More]loader is unable to load the specified module and a specific > > >exception is not raised in determining this, ImportError is raised. > > >This may occur if a loader is called without first consulting an > > >importer as to if the loader can load the specified module but the > > >loader is aware of the fact it cannot fulfill the request made. > > >""" > > > > Okay, now I understand what you're trying to say, but I still don't > > understand what the purpose is. I mean, what else would you do except > > raise an error? I.e., isn't the actual contract "load the specified module > > or raise an exception of some kind"? > >Not if you read the PEP. It doesn't explicitly say what should happen. > >I want to standardize on raising ImportError. The PEP itself has two >ways of signaling an error; find_module() returns None instead of >raising an error to signal it can't do something while path hooks >raise ImportError. I just want to be as explicit as possible. Ok, so this should at least lose the passive voice ("ImportError is raised") -- it should say that it's the loader's job to raise ImportError. Otherwise, it's not actually removing any ambiguity. I also don't find the "This may occur" sentence to be helpful; it seems we should just say, "load_module() must return a loaded module or raise an error, preferably an ImportError unless an existing exception is being propagated." Meanwhile, if you also mean to say that load_module() is explicitly allowed to fail with an ImportError when it's asked for any module other than the one it was obtained for (via find_module()), then let's say that, too. Notice, by the way, that this is a stronger condition than the one you proposed, yet it doesn't imply that there is or should be an ongoing relationship between the loader and the importer. It also doesn't imply that perhaps it's okay for a loader to not succeed in reloading the *same* module! (i.e., as I understand it, a module can currently invoke __loader__.load_module(__name__) as a rough synonym for reload().) [View Less]

2 1

new metaclass error condition checks
by Jean-Paul Calderone April 24, 2007

April 24, 2007

I just noticed r53997 (from some unit tests it broke), which disallowed things like this: class X(object): def __repr__(self): return "blah" class Y(X, type): pass class Z: __metaclass__ = Y Making X classic eliminates the TypeError, and is probably an acceptable fix in a lot of cases (at least as long as classic classes are available). I wonder if the ability to override type special methods like this was considered when the change was made, though? Jean-Paul

3 2

Re: [Python-Dev] Clarifications for import PEPs (302 and 328)
by Phillip J. Eby April 24, 2007

April 24, 2007

At 03:16 PM 4/23/2007 -0700, Brett Cannon wrote: >The PEP does not explicitly state how to signal that a loader cannot >load a module it is asked to. This could happen if someone called a >loader without consulting its respective importer. I would want to >add something like: >""" >If the loader is unable to load the specified module and a specific >exception is not raised in determining this, ImportError is raised. >This may occur if a loader is called without first … [View More]

3 2

Patch to skip positional arguments with partials
by Calvin Spealman April 24, 2007

April 24, 2007

I posted about this on python-ideas, and didn't get any objections about the idea itself, so I took the opportunity to dive into the C API and get my hands dirty. I posted the idea and patch as a report on SF (1706256). For anyone interested at least to look over, I'm also just including the small patch at the end of this email. Everything is passing for me with these changes, except the inability to subclass the partial type. I've found the current end of my abilities in understanding how I … [View More]broke that, so I'd appreciate any reaction to the situation. Index: Modules/_functoolsmodule.c =================================================================== --- Modules/_functoolsmodule.c (revision 54922) +++ Modules/_functoolsmodule.c (working copy) @@ -21,6 +21,7 @@ } partialobject; static PyTypeObject partial_type; +static PyObject *partial_skip; static PyObject * partial_new(PyTypeObject *type, PyObject *args, PyObject *kw) @@ -89,6 +90,10 @@ { PyObject *ret; PyObject *argappl = NULL, *kwappl = NULL; + PyObject *ptoargscopy, *arg; + Py_ssize_t skip_index = 0; + Py_ssize_t pull_index = 0; + Py_ssize_t i; assert (PyCallable_Check(pto->fn)); assert (PyTuple_Check(pto->args)); @@ -101,7 +106,25 @@ argappl = pto->args; Py_INCREF(pto->args); } else { - argappl = PySequence_Concat(pto->args, args); + + // For each partial_skip in the pto args, replace it with a new arg + ptoargscopy = PyTuple_New(PyTuple_GET_SIZE(pto->args)); + for (i = 0; i<PyTuple_GET_SIZE(pto->args); ++i) { + arg = PyTuple_GetItem(pto->args, i); + Py_XINCREF(arg); + PyTuple_SetItem(ptoargscopy, i, arg); + if (arg == NULL) { + break; + } else if (arg == partial_skip) { + arg = PyTuple_GetItem(args, pull_index); + Py_XINCREF(arg); + PyTuple_SetItem(ptoargscopy, i, arg); + pull_index += 1; + } + } + + arg = PyTuple_GetSlice(args, pull_index, PySequence_Length(args)); + argappl = PySequence_Concat(ptoargscopy, arg); if (argappl == NULL) return NULL; } @@ -142,7 +165,8 @@ PyDoc_STRVAR(partial_doc, "partial(func, *args, **keywords) - new function with partial application\n\ - of the given arguments and keywords.\n"); + of the given arguments and keywords. Pass partial.skip to any positional\n\ + argument to be bound to later."); #define OFF(x) offsetof(partialobject, x) static PyMemberDef partial_memberlist[] = { @@ -255,7 +280,7 @@ init_functools(void) { int i; - PyObject *m; + PyObject *m, *builtins, *skip, *object; char *name; PyTypeObject *typelist[] = { &partial_type, @@ -274,4 +299,16 @@ Py_INCREF(typelist[i]); PyModule_AddObject(m, name+1, (PyObject *)typelist[i]); } + + builtins = PyImport_ImportModule("__builtin__"); + object = PyObject_GetAttrString(builtins, "object"); + Py_DECREF(builtins); + skip = PyObject_CallObject(object, NULL, NULL); + Py_DECREF(object); + + partial_type.tp_dict = PyDict_New(); + PyDict_SetItemString(partial_type.tp_dict, "skip", skip); + partial_skip = skip; + + // skip is not decref'ed because a reference is always held by the static pointer. } -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/ [View Less]

1 0

Re: [Python-Dev] Clarifications for import PEPs (302 and 328)
by Phillip J. Eby April 23, 2007

April 23, 2007

At 02:01 PM 4/23/2007 -0700, Brett Cannon wrote: >For PEP 302, a loader should raise ImportError if load_module fails >w/o an explicit exception being raised. I'm not sure I understand this; could you point to the relevant part of the PEP and what you would be adding? Thanks. (The rest of your comments sounded fine, btw.)

2 1

Clarifications for import PEPs (302 and 328)
by Brett Cannon April 23, 2007

April 23, 2007

After my import rewrite, I discovered some things that were left out of both PEP 302 (import hooks) and PEP 328 (absolute/relative imports). I wanted to run them by everyone before I made the subsequent changes to the PEPs. For PEP 302, a loader should raise ImportError if load_module fails w/o an explicit exception being raised. Also, __name__ needs to be set along with __file__ (if applicable as 'sys' does not define __file__) before the execution of code proceeds. For PEP 328, None … [View More]

1 0

styleguide inconsistency
by Darren Dale April 23, 2007

April 23, 2007

I was recently searching for some guidance on how to name packages and modules, and discovered an inconsistency in the style guides published at www.python.org. http://www.python.org/doc/essays/styleguide.html says "Module names can be either MixedCase or lowercase." That page also refers to PEP 8 at http://www.python.org/dev/peps/pep-0008/, which says "Modules should have short, all-lowercase names. ... Python packages should also have short, all-lowercase names ...". Some discussion on dev.… [View More]

4 3

Patch reviews and request
by Jason Orendorff April 23, 2007

April 23, 2007

OK, here's the patch I'd like to direct attention to: http://python.org/sf/1704134 [ 1704134 ] minidom Level 1 DOM compliance This is only the first step toward DOM Level 1 compliance. It fixes the stuff that's easy to fix. Here are the patch reviews. I put more detailed comments in the SF tracker. http://python.org/sf/1704547 [ 1704547 ] Use MoveFileEx() to implement os.rename() on windows -1. This changes the documented behavior of a commonly used function. http://python.org/sf/… [View More]

1 0