[Python-Dev] Patch reviews and request
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/1678345 [ 1678345 ] A fix for the bug #1528074 [warning: quite slow] This can be rejected. http://python.org/sf/1673007 [ 1673007 ] urllib2 requests history + HEAD support urllib2.urlopen() object seems like the wrong place for history to be attached. These objects are pretty ephemeral, in my code anyway. Patch is extremely rough. -1. http://python.org/sf/1665292 [ 1665292 ] Datetime enhancements The patch here adds __int__ and __float__ to datetime.timedelta. I'm -1 on that. It also implements > < == comparison between timedelta objects and numbers, which is right out--they don't have compatible hash codes. http://python.org/sf/1652328 [ 1652328 ] stream writing support in wave.py This can be rejected. (Update: After my comments on this one, Neal closed it.) The following patches look good, but I didn't attempt to run them. I just read the source code. http://python.org/sf/1669481 [ 1669481 ] subprocess: Support close_fds on Win32 Looks good, and a definite +1. http://python.org/sf/1704621 [ 1704621 ] interpreter crash when multiplying large lists Yep, it crashes. Patch looks good. +1. http://python.org/sf/1692664 [ 1692664 ] warnings.py gets filename wrong for eval/exec Nice to have. +1. http://python.org/sf/1676135 [ 1676135 ] Remove trailing slash from --prefix Also nice to have. +0. -j ___ 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
[Python-Dev] styleguide inconsistency
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.lang.python has so far turned up the following points of view: 1) There isn't technically a contradiction because "can be" is not the same as "should be". However, since this is a style guide and not a syntax guide, I still think the documents are contradictory. 2) There isn't any confusion because the styleguide refers to the PEPs, so they have priority. However, styleguide.html does not explain that the PEPs are more up-to-date. We shouldn't expect someone to go to the PEPs after finding an answer to their question in the styleguide. Perhaps one of these documents could be revised to make the situation more clear? Thanks, Darren Dale ___ 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
Re: [Python-Dev] styleguide inconsistency
On 4/23/07, Darren Dale <[EMAIL PROTECTED]> wrote: > 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.lang.python has so far turned up the following points > of view: > > 1) There isn't technically a contradiction because "can be" is not the same > as "should be". > > However, since this is a style guide and not a syntax guide, I still think the > documents are contradictory. > > 2) There isn't any confusion because the styleguide refers to the PEPs, so > they have priority. > Yes, the PEPs take priority. > However, styleguide.html does not explain that the PEPs are more up-to-date. The PEPs are more up-to-date. > We shouldn't expect someone to go to the PEPs after finding an answer to > their question in the styleguide. > > Perhaps one of these documents could be revised to make the situation more > clear? I personally think the style guide should just go and/or redirect to PEP 8. I didn't even know it existed until this email. And I only know of people updated PEP 8. -Brett ___ 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
Re: [Python-Dev] styleguide inconsistency
On Mon, Apr 23, 2007 at 09:25:48AM -0700, Brett Cannon wrote: > I personally think the style guide should just go and/or redirect to > PEP 8. I didn't even know it existed until this email. And I only > know of people updated PEP 8. The top of the style guide basically does that: This style guide has been converted to several PEPs (Python Enhancement Proposals): PEP 8 for the main text, PEP 257 for docstring conventions. See the PEP index. Perhaps that warning could be strengthened to suggest that the style guide is outdated and (apparently) unfinished? Beyond that, I don't see any contradiction here, and I don't see any reason to spend time updating the style guide. Dustin ___ 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
Re: [Python-Dev] styleguide inconsistency
Someone should just take down that styleguide, or *replace* it with a link (and only a link) to PEP 8. I can't do that myself, it's in the hands of the webmasters. On 4/23/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On Mon, Apr 23, 2007 at 09:25:48AM -0700, Brett Cannon wrote: > > I personally think the style guide should just go and/or redirect to > > PEP 8. I didn't even know it existed until this email. And I only > > know of people updated PEP 8. > > The top of the style guide basically does that: > > This style guide has been converted to several PEPs (Python > Enhancement Proposals): PEP 8 for the main text, PEP 257 for docstring > conventions. See the PEP index. > > Perhaps that warning could be strengthened to suggest that the style > guide is outdated and (apparently) unfinished? Beyond that, I don't see > any contradiction here, and I don't see any reason to spend time > updating the style guide. > > Dustin > ___ > 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/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
[Python-Dev] Clarifications for import PEPs (302 and 328)
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 redirection (if 'pkg.string' is set to None the import machinery is supposed to automatically return the 'string' module) should be removed when absolute/relative imports become the default. The redirection was a hack to optimize for import's old semantics of trying a relative import first and then an absolute import. The new semantics do away with the fallback and thus this mechanism is worthless. -Brett ___ 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
Re: [Python-Dev] Clarifications for import PEPs (302 and 328)
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.) ___ 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
Re: [Python-Dev] Clarifications for import PEPs (302 and 328)
On 4/23/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > 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 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 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. """ > (The rest of your comments sounded fine, btw.) Great! -Brett ___ 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
Re: [Python-Dev] Clarifications for import PEPs (302 and 328)
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 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"? I mean, how about something like: "If for any reason the loader can't load the requested module, it must raise an exception (such as an ImportError), or allow an existing exception to propagate out of the load_module() call." ___ 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
Re: [Python-Dev] Clarifications for import PEPs (302 and 328)
On 4/23/07, Phillip J. Eby <[EMAIL PROTECTED]> 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 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. -Brett ___ 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
[Python-Dev] Tweaking the stdlib test infrastructure
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 new refleak checking soon, if this base change goes ahead. How: At first, test_support.TestCase could be as simple as "TestCase = unittest.TestCase". Once we want to extend the test harness's capabilities, we change it to "class TestCase(unittest.TestCase): blah blah blah". All code under Lib/test/ is changed to subclass the proper class. test_support.run_unittest() can be modified to make sure that incoming classes inherit as they're supposed to. But that sounds like a lot of work: yes, but that's what we have regexes for. Most of this work can be done with a few global search-and-replace operations. So: any objections to making this change? Collin Winter ___ 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
Re: [Python-Dev] Clarifications for import PEPs (302 and 328)
At 04:23 PM 4/23/2007 -0700, Brett Cannon wrote:
>On 4/23/07, Phillip J. Eby <[EMAIL PROTECTED]> 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 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().)
___
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
Re: [Python-Dev] Tweaking the stdlib test infrastructure
On 4/23/07, Collin Winter <[EMAIL PROTECTED]> wrote: > Fast and simple: I want all stdlib test cases to stop subclassing > unittest.TestCase and start subclassing test_support.TestCase. Go for it! n ___ 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
[Python-Dev] Attachment Policy?
Hi List, i want to post a little bit of something I've been working on. Before I post it, i want to know if I'm allowed to post it as an attachment. Coming up, some work on ASTVisitor in the compiler module. Cheers, Yaakov ___ 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
Re: [Python-Dev] Tweaking the stdlib test infrastructure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 23, 2007, at 8:39 PM, Collin Winter wrote: > Fast and simple: I want all stdlib test cases to stop subclassing > unittest.TestCase and start subclassing test_support.TestCase. > > So: any objections to making this change? Please use the absolute package name test.test_support.TestCase. Remember that some of the code in the stdlib is released externally to Python (e.g. the email package), so their test suites have to be runnable in that deployment mode. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRi16v3EjvBPtnXfVAQKS4wQAiAaoIrhLhnnKxsrJL8RHZzPB9J3u98LJ EWZD7h9z0rXBEElOSDCQqZ3zlSVJNO5PGcogXPivrKE3Hg5t/pK88FCAMFNjv8iY sLK2fwpMlsGLLnIfGRbSOTxVvyEmuUEPQ5CuLUniPEMocE42bUi+7hpp5pLc2PDA U7dzYzGwBxA= =g+lH -END PGP SIGNATURE- ___ 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
[Python-Dev] Patch to skip positional arguments with partials
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 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; iargs); ++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/
___
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
Re: [Python-Dev] Attachment Policy?
On 4/23/07, Yaakov Nemoy <[EMAIL PROTECTED]> wrote: > Hi List, > > i want to post a little bit of something I've been working on. Before > I post it, i want to know if I'm allowed to post it as an attachment. > Coming up, some work on ASTVisitor in the compiler module. Hi Yaakov. If you'd like to post patches, the appropriate place to do that is here: http://sourceforge.net/tracker/?atid=305470&group_id=5470&func=browse This way everyone can look at it, comment, and we don't lose track of your patch. Cheers, n ___ 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
Re: [Python-Dev] Attachment Policy?
On 4/24/07, Neal Norwitz <[EMAIL PROTECTED]> wrote: > On 4/23/07, Yaakov Nemoy <[EMAIL PROTECTED]> wrote: > > Hi List, > > > > i want to post a little bit of something I've been working on. Before > > I post it, i want to know if I'm allowed to post it as an attachment. > > Coming up, some work on ASTVisitor in the compiler module. > > Hi Yaakov. > > If you'd like to post patches, the appropriate place to do that is here: > > http://sourceforge.net/tracker/?atid=305470&group_id=5470&func=browse > > This way everyone can look at it, comment, and we don't lose track of > your patch. Done. :) http://sourceforge.net/tracker/index.php?func=detail&aid=1706323&group_id=5470&atid=305470 ___ 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
