Re: [Python-Dev] [Python-checkins] r66863 - python/trunk/Modules/posixmodule.c
> > Correct. But they might well be broken, no? > > I would hope some effort is made that they not be. If they generate a > positive, I would expect that the contributor would try to fix that > before committing, no? If they discover that it's "false", they fix > or remove the test; otherwise they document it. That assumes they know. We had recently a number of test cases that fixed security problems, and the tests would only run correctly on 32-bit systems. On 64-bit systems, they would consume all memory, and either bring the machine down, or complete eventually with a failure (because the expected out-of-memory situation did not arise). The author of the code was unaware of its dependency on the architecture, and the test would run fine on his machine. Likewise, we had test failures that only failed if a certain locale was not available on a system, or had locale definitions that were different from the ones on Linux. There is a lot of potential for tests to only fail on systems which we don't have access to. > Whether that is an acceptable solution to the "latent bug" problem is > a different question. I'd rather know that Python has unexpected > behavior, and have a sample program (== test) to demonstrate it, than > not. YMMV. And it does indeed for many people. We get a significant number of reports from people who find that the test suite fails, and then are unable to draw any conclusions from that other than Python is apparently broken, and that they therefore shouldn't use it - even if the test that fails is in a module that they likely never use. Regards, Martin ___ 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] www.python.org/doc and docs.python.org hotfixed
> For the search engine issue, is there any way we can tell robots to > ignore the rewrite rules so they see the broken links? (although even > that may not be ideal, since what we really want is to tell the robot > the link is broken, and provide the new alternative) I may be missing something obvious, but isn't this the exact intent of HTTP response code 301 Moved Permanently http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.2 -jJ ___ 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] [Python-checkins] r66863 - python/trunk/Modules/posixmodule.c
On Fri, Oct 10, 2008 at 08:44:38AM +0200, "Martin v. Löwis" wrote: > So 2.6.0 will contain a lot of tests that have never been tested in > a wide variety of systems. Some are incorrect, and get fixed in 2.6.1, > and stay fixed afterwards. This is completely different from somebody > introducing a new test in 2.6.4. It means that there are more failures > in a maintenance release, not less as in the first case. Indeed. Looking at the commit logs, I had to split out all the test-only commits into a separate list, and tests often took several attempts to get working on all platforms. I think backporting should be prioritized into 1) bug fixes, 2) documentation improvements, 3) tests. For 2.5.3, we should just ignore 2) and 3); documentation patches will require rewriting from reST into LaTeX, which is too much effort for the return, and tests are even less useful to the end users, being primarily useful for Python's developers. (2.5.3 reminder: there are lists of commits in sandbox/py2.5.3 to be considered. I've seen no reactions on python-dev or modifications to those files, so I don't think anyone else is looking at them. Is everyone waiting for the weekend, maybe?) --amk ___ 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] syntax change justification
Nick Coghlan's explanation of what justifies a syntax change (most of message http://mail.python.org/pipermail/python-dev/2008-October/082831.html ) should probably be added to the standard docs/FAQs somewhere. At the moment, I'm not sure exactly where, though. At the moment, the Developer FAQ (http://www.python.org/dev/faq/) is mostly about using specific tools (rather than design philosophy), and Nick's explanation may be too detailed for the current Explanations section of www.python.org/dev/ Possibly as a Meta-PEP? -jJ ___ 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] Summary of Python tracker Issues
ACTIVITY SUMMARY (10/03/08 - 10/10/08) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2105 open (+49) / 13818 closed (+21) / 15923 total (+70) Open issues with patches: 690 Average duration of open issues: 707 days. Median duration of open issues: 1884 days. Open Issues Breakdown open 2089 (+49) pending16 ( +0) Issues Created Or Reopened (73) ___ zlib.crc32() and adler32() return value 10/06/08 http://bugs.python.org/issue1202reopened facundobatista 64bit, easy Fix test_cProfile10/06/08 http://bugs.python.org/issue2744reopened benjamin.peterson "make check" suggest a testing target under GNU coding standards 10/03/08 CLOSED http://bugs.python.org/issue3758reopened brett.cannon patch 08 value popups an stdin error, no date handle allowed 10/03/08 CLOSED http://bugs.python.org/issue4031created pgimelli disutils cannot recognize ".dll.a" as library on cygwin 10/03/08 http://bugs.python.org/issue4032created ocean-city python search path - .pth recursion 10/03/08 http://bugs.python.org/issue4033created jolleyjoe traceback attribute error10/03/08 http://bugs.python.org/issue4034created ghazel patch, needs review Support bytes for os.exec*() 10/03/08 http://bugs.python.org/issue4035created haypo patch, patch Support bytes for subprocess.Popen() 10/03/08 http://bugs.python.org/issue4036created haypo patch, patch doctest.py should include method descriptors when looking inside 10/04/08 http://bugs.python.org/issue4037created daaku py3k error in distutils file_copy exception handlers 10/04/08 CLOSED http://bugs.python.org/issue4038created mhammond patch, patch Add __enter__ and __exit__ methods to StringIO/cStringIO classes 10/04/08 CLOSED http://bugs.python.org/issue4039created peppergrower ignored exceptions in generators (regression?) 10/04/08 http://bugs.python.org/issue4040created benjamin.peterson reference to rexec in __import__ 10/04/08 CLOSED http://bugs.python.org/issue4041created wplappert IDLE won't start in 2.6 final. A known fix was overlooked? 10/04/08 CLOSED http://bugs.python.org/issue4042created rbtyod Warnings in IDLE raise TypeError (such as attempting to import d 10/04/08 http://bugs.python.org/issue4043created craigh test_output_textcalendar fails on non-englisch locale10/05/08 http://bugs.python.org/issue4044created oefe test_mboxmmdf_to_maildir fails on non-englisch locale10/05/08 http://bugs.python.org/issue4045created oefe test_formatdate_usegmt fails on non-englisch locale 10/05/08 http://bugs.python.org/issue4046created oefe test_run_abort triggers CrashReporter on MacOS
[Python-Dev] backporting tests [was: [Python-checkins] r66863 - python/trunk/Modules/posixmodule.c]
In http://mail.python.org/pipermail/python-dev/2008-October/082994.html Martin v. Löwis wrote: > So 2.6.0 will contain a lot of tests that have never been tested in > a wide variety of systems. Some are incorrect, and get fixed in 2.6.1, > and stay fixed afterwards. This is completely different from somebody > introducing a new test in 2.6.4. It means that there are more failures > in a maintenance release, not less as in the first case. If 2.6.1 has some (possibly accidental, but exposed to the users) behavior that is not a clear bug, it should be kept through 2.6.x. You may well want to change it in 2.7, but not in 2.6.4. Adding a test to 2.6.2 ensures that the behavior will not silently disappear because of an unrelated bugfix in 2.6.3. -jJ ___ 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] Documentation idea
On Thu, Oct 9, 2008 at 8:37 PM, <[EMAIL PROTECTED]> wrote:
>
> On 9 Oct, 11:12 pm, [EMAIL PROTECTED] wrote:
>>
>> Background
>> --
>> In the itertools module docs, I included pure python equivalents for each
>> of the C functions. Necessarily, some of those equivalents are only
>> approximate but they seem to have greatly enhanced the docs.
>
> Why not go the other direction?
>
> Ostensibly the reason for writing a module like 'itertools' in C is purely
> for performance. There's nothing that I'm aware of in that module which
> couldn't be in Python.
>
> Similarly, cStringIO, cPickle, etc. Everywhere these diverge, it is (if not
> a flat-out bug) not optimal. External projects are encouraged by a wealth
> of documentation to solve performance problems in a similar way: implement
> in Python, once you've got the interface right, optimize into C.
>
> So rather than have a C implementation, which points to Python, why not have
> a Python implementation that points at C? 'itertools' (and similar) can
> actually be Python modules, and use a decorator, let's call it "C", to do
> this:
>
> @C("_c_itertools.count")
> class count(object):
> """
> This is the documentation for both the C version of itertools.count
> and the Python version - since they should be the same, right?
> """
>
And that decorator is generic enough to work for both classes and functions.
> In Python itself, the Python module would mostly be for documentation, and
> therefore solve the problem that Raymond is talking about, but it could also
> be a handy fallback for sanity checking, testing, and use in other Python
> runtimes (ironpython, jython, pypy).
Which is why I would love to make this almost a policy for new modules
that do not have any C dependency.
> Many third-party projects already use
> ad-hoc mechanisms for doing this same thing, but an officially-supported way
> of saying "this works, but the optimized version is over here" would be a
> very useful convention.
>
> In those modules which absolutely require some C stuff to work, the python
> module could still serve as documentation.
>
Add to this some function to help test both the pure Python and C
implementation, like ``py_version, c_version =
import_versions('itertools', '_c_itertools')``, so you can run the
test suite against both versions, and you then have pretty much
everything covered for writing the code in Python to start and
optimizing as needed in C.
-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] syntax change justification
On Fri, Oct 10, 2008 at 8:51 AM, Jim Jewett <[EMAIL PROTECTED]> wrote: > Nick Coghlan's explanation of what justifies a syntax change (most of message > http://mail.python.org/pipermail/python-dev/2008-October/082831.html ) > should probably be added to the standard docs/FAQs somewhere. > > At the moment, I'm not sure exactly where, though. At the moment, the > Developer FAQ (http://www.python.org/dev/faq/) is mostly about using > specific tools (rather than design philosophy), and Nick's explanation > may be too detailed for the current Explanations section of > www.python.org/dev/ > > Possibly as a Meta-PEP? > What we need (and hope through some miracle to have the time for) a doc that explains the steps needed to report a bug/submit a patch (basically the issue lifecycle) and how to propose a new language feature. That would clean up the dev FAQ into basically being a svn FAQ, and then give us docs to point people to when they ask how they can contribute. -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] Documentation idea
[EMAIL PROTECTED] wrote:
On 9 Oct, 11:12 pm, [EMAIL PROTECTED] wrote:
Background
--
In the itertools module docs, I included pure python equivalents for
each of the C functions. Necessarily, some of those equivalents are
only approximate but they seem to have greatly enhanced the docs.
Why not go the other direction?
Ostensibly the reason for writing a module like 'itertools' in C is
purely for performance. There's nothing that I'm aware of in that
module which couldn't be in Python.
Similarly, cStringIO, cPickle, etc. Everywhere these diverge, it is (if
not a flat-out bug) not optimal. External projects are encouraged by a
wealth of documentation to solve performance problems in a similar way:
implement in Python, once you've got the interface right, optimize into C.
So rather than have a C implementation, which points to Python, why not
have a Python implementation that points at C? 'itertools' (and
similar) can actually be Python modules, and use a decorator, let's call
it "C", to do this:
@C("_c_itertools.count")
class count(object):
"""
This is the documentation for both the C version of itertools.count
and the Python version - since they should be the same, right?
"""
The ancient string module did something like this, except that the
rebinding of function names was done at the end by 'from _string import
*' where _string had C versions of some but not all of the functions in
string. (And the list of replacements could vary by version and
platform and compiler switches.) This was great for documenting the
string module. It was some of the first Python code I studied after the
tutorial.
The problem with that and the above (with modification, see below) is
the creation and discarding of unused function objects and the time
required to do so.
The advantage of the decorator version is that the compiler or module
loader could be special cased to recognize the 'C' decorator and try it
first *before* using the Python version, which would serve as a backup.
There could be a standard version in builtins that people could
replace to implement non-standard loading on a particular system. To
cater to other implementations, the name could be something other than
'C', or we could define 'C' to be the initial of "Code" (in the
implementation language). Either way, other implementation could start
with a do-nothing "C" decorator and run the file as is, then gradually
replace with lower-level code.
Terry Jan Reedy
___
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] syntax change justification
Jim Jewett wrote: Nick Coghlan's explanation of what justifies a syntax change (most of message http://mail.python.org/pipermail/python-dev/2008-October/082831.html ) should probably be added to the standard docs/FAQs somewhere. I agree that this was a helpful explanation. A link to the original would be easy to add now. ___ 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] Documentation idea
On Fri, Oct 10, 2008 at 1:45 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>>
>> On 9 Oct, 11:12 pm, [EMAIL PROTECTED] wrote:
>>>
>>> Background
>>> --
>>> In the itertools module docs, I included pure python equivalents for each
>>> of the C functions. Necessarily, some of those equivalents are only
>>> approximate but they seem to have greatly enhanced the docs.
>>
>> Why not go the other direction?
>>
>> Ostensibly the reason for writing a module like 'itertools' in C is purely
>> for performance. There's nothing that I'm aware of in that module which
>> couldn't be in Python.
>>
>> Similarly, cStringIO, cPickle, etc. Everywhere these diverge, it is (if
>> not a flat-out bug) not optimal. External projects are encouraged by a
>> wealth of documentation to solve performance problems in a similar way:
>> implement in Python, once you've got the interface right, optimize into C.
>>
>> So rather than have a C implementation, which points to Python, why not
>> have a Python implementation that points at C? 'itertools' (and similar)
>> can actually be Python modules, and use a decorator, let's call it "C", to
>> do this:
>>
>> @C("_c_itertools.count")
>> class count(object):
>> """
>> This is the documentation for both the C version of itertools.count
>> and the Python version - since they should be the same, right?
>> """
>
> The ancient string module did something like this, except that the rebinding
> of function names was done at the end by 'from _string import *' where
> _string had C versions of some but not all of the functions in string. (And
> the list of replacements could vary by version and platform and compiler
> switches.) This was great for documenting the string module. It was some
> of the first Python code I studied after the tutorial.
>
> The problem with that and the above (with modification, see below) is the
> creation and discarding of unused function objects and the time required to
> do so.
>
> The advantage of the decorator version is that the compiler or module loader
> could be special cased to recognize the 'C' decorator and try it first
> *before* using the Python version, which would serve as a backup. There
> could be a standard version in builtins that people could replace to
> implement non-standard loading on a particular system. To cater to other
> implementations, the name could be something other than 'C', or we could
> define 'C' to be the initial of "Code" (in the implementation language).
> Either way, other implementation could start with a do-nothing "C"
> decorator and run the file as is, then gradually replace with lower-level
> code.
>
The decorator doesn't have to require any special casing at all
(changing the parameters to keep the code short)::
def C(module_name, want):
def choose_version(ob):
try:
module = __import__(module_name, fromlist=[want])
return getattr(module, want)
except (ImportError, AttributeError):
return ob
return choose_version
The cost is purely during importation of the module and does nothing
fancy at all and relies on stuff already available in all Python VMs.
-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] [Python-checkins] r66863 - python/trunk/Modules/posixmodule.c
It seems to me that Skip was asking whether the "memory leak" impacted the 2.6 branch, and the answer should have been "No": the change that introduced the memory leak had just been committed 10 minutes before. You are probably right (although it's not quite clear from Skip's question). Umm, sorry for misunderstandings. I thought he indicated the set of two patches. - Because of this misunderstanding, the changes to this GetCurrentDirectoryW were backported to the release2.6 branch, despite the fact that it's not a regression from a previous version, the NEWS entry explicitly expresses doubts about the correction (which I happen to share), there is no unit test and no item in the issue tracker. I think it is fine that this fix was backported (assuming, without review, that the fix is actually correct). It is a bugfix, and it shouldn't realistically break existing applications. IOW, PEP 6 was followed (except that there is no Patch Czar). Thanks, I'm a bit relaxed. :-) - The backport to release26-maint http://svn.python.org/view?rev=66865&view=rev also merged other changes (new unrelated unit tests). IMO unrelated changes should be committed separately: different commit messages help to understand the motivation of each backport. Yes, that is unfortunate. I'm skeptical that new tests actually need backporting at all. Python doesn't really get better by new tests being added to an old branch. Near-term, it might get worse because the new tests might cause false positives, making users worried for no reason. OK, I'll do separate commit for release26-maint even via svnmerge.py (I did same way as in py3k) But I'm bit confused. This is difficult problem for me, so I 'll commit to only trunk until some consensus will be established. ___ 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] syntax change justification
Terry Reedy wrote: > Jim Jewett wrote: >> Nick Coghlan's explanation of what justifies a syntax change (most of >> message >> http://mail.python.org/pipermail/python-dev/2008-October/082831.html ) >> should probably be added to the standard docs/FAQs somewhere. > > I agree that this was a helpful explanation. A link to the original > would be easy to add now. A link from either the dev FAQ (like the one to Raymond's School of Hard Knocks) or from PEP 1 (PEP Purpose and Guidelines) might work, but I will leave it to others to decide whether it is worth linking to or not :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] Documentation idea
Brett Cannon wrote: On Fri, Oct 10, 2008 at 1:45 PM, Terry Reedy <[EMAIL PROTECTED]> wrote: The advantage of the decorator version is that the compiler or module loader could be special cased to recognize the 'C' decorator and try it first *before* using the Python version, which would serve as a backup. There could be a standard version in builtins that people could replace to implement non-standard loading on a particular system. To cater to other implementations, the name could be something other than 'C', or we could define 'C' to be the initial of "Code" (in the implementation language). Either way, other implementation could start with a do-nothing "C" decorator and run the file as is, then gradually replace with lower-level code. The decorator doesn't have to require any special casing at all (changing the parameters to keep the code short):: def C(module_name, want): def choose_version(ob): try: module = __import__(module_name, fromlist=[want]) return getattr(module, want) except (ImportError, AttributeError): return ob return choose_version The cost is purely during importation of the module and does nothing fancy at all and relies on stuff already available in all Python VMs. If I understand correctly, this decorator would only be applied *after* the useless Python level function object was created. I was proposing bypassing that step when not necessary, and I believe special casing *would* be required for that. ___ 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] Documentation idea
On Fri, Oct 10, 2008 at 9:46 PM, Terry Reedy <[EMAIL PROTECTED]> wrote: > Brett Cannon wrote: >> >> On Fri, Oct 10, 2008 at 1:45 PM, Terry Reedy <[EMAIL PROTECTED]> wrote: > >>> The advantage of the decorator version is that the compiler or module >>> loader >>> could be special cased to recognize the 'C' decorator and try it first >>> *before* using the Python version, which would serve as a backup. There >>> could be a standard version in builtins that people could replace to >>> implement non-standard loading on a particular system. To cater to other >>> implementations, the name could be something other than 'C', or we could >>> define 'C' to be the initial of "Code" (in the implementation language). >>> Either way, other implementation could start with a do-nothing "C" >>> decorator and run the file as is, then gradually replace with lower-level >>> code. >>> >> >> The decorator doesn't have to require any special casing at all >> (changing the parameters to keep the code short):: >> >> def C(module_name, want): >> def choose_version(ob): >> try: >> module = __import__(module_name, fromlist=[want]) >> return getattr(module, want) >> except (ImportError, AttributeError): >>return ob >> return choose_version >> >> The cost is purely during importation of the module and does nothing >> fancy at all and relies on stuff already available in all Python VMs. > > If I understand correctly, this decorator would only be applied *after* the > useless Python level function object was created. Yes. > I was proposing bypassing > that step when not necessary, and I believe special casing *would* be > required for that. Yes, that would. -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
