Re: [Python-Dev] Windows buildbots MSVC RTL popups
With the help of bbreport, I collected these informations: - 3 tests are freezing randomly : test_bz2, test_codecs and test_tarfile - it happens on XP-4 and Windows7 builders (branches 2.7 and 3.1 only, trunk is not affected) - it seems to happen since revisions 84345 and 84346 which fixed issue # 1868 my .2 cents, -- Florent Xicluna 2010/8/30 David Bolen : > Since the recent history of my two Windows buildbots has turned ugly, > I figured I'd mention that they both (XP and Windows 7) have started > generating quite a few GUI C++ RTL runtime pop-up assertions, which > has been throwing a wrench into things until they get manually > cleared. I first noticed them Sunday night but they were probably > there 24-48 hours at that point. These are R6034 "An application has > made an attempt to load the C runtime library incorrectly" > > I glanced through recent commits and I don't think I see anything > obviously related but was wondering if anyone who might have been > committing changes in the past few days might have an thought? The > source filename is truncated in the dialog (what genius at MS thought > that would be the one field worth truncating?!) so I am not absolutely > sure if they are limited to a specific branch or not. > > I've thrown on an autoit script to try to automatically acknowledge > these dialogs so hopefully the affected test runs will just fail > rather than timing out and blocking later runs. > > -- David ___ 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] Summary of Python tracker Issues
And Now For Something Completely Different... http://code.google.com/p/bbreport/wiki/PythonBuildbotReport The buildbot failures and tracker issues are listed in 3 tables: - *New failures* : failures which are not associated with an issue in the tracker - *Known issues* : failures which are (probably) linked with an existing issue (the association [failure] <--> [issue] is based on regexp rules) - *No recent failure* : these issues are no longer reported on recent builds. Either the problem is fixed, or the failure is elusive. The page is hosted on Google Code. Victor hosts a cron job which recalculates and upload the JSON data. Currently, the report is uploaded every hour. Regards, -- Florent Xicluna 2010/8/20 Python tracker > > ACTIVITY SUMMARY (2010-08-13 - 2010-08-20) > Python tracker at http://bugs.python.org/ > > To view or respond to any of the issues listed below, click on the issue. > Do NOT respond to this message. > > Issues stats: > open 2624 (+44) > closed 18808 (+80) > total 21432 (+63) > > Open issues with patches: 1110 > > > Issues opened (44) > == > > #9189: Improve CFLAGS handling > http://bugs.python.org/issue9189 reopened by skrah > > #9445: Fix undefined symbol errors on VS8.0 build > http://bugs.python.org/issue9445 reopened by amaury.forgeotdarc > > #9591: kqueue not reporting EOF under certain circumstances > http://bugs.python.org/issue9591 opened by Volodymyr.Kostyrko > > #9592: Limitations in objects returned by multiprocessing Pool > http://bugs.python.org/issue9592 opened by macfreek > > #9594: typo on Mac/Makefile.in? s/pythonw/python/ > http://bugs.python.org/issue9594 opened by srid > > #9597: mac: Install 2to3 in /usr/local/bin > http://bugs.python.org/issue9597 opened by srid > > #9598: untabify.py fails on files that contain non-ascii characters > http://bugs.python.org/issue9598 opened by belopolsky > > #9601: ftplib should accept 250 on MKD > http://bugs.python.org/issue9601 opened by alphablue52 > > #9602: PyObject_AsCharBuffer() should only accept read-only objects > http://bugs.python.org/issue9602 opened by haypo > > #9607: Test file 'test_keyword.py' submission for use with keyword.py > http://bugs.python.org/issue9607 opened by gregmalcolm > > #9608: Re-phrase best way of using exceptions in doanddont.rst > http://bugs.python.org/issue9608 opened by flub > > #9609: make cProfile multi-stack aware > http://bugs.python.org/issue9609 opened by krisvale > > #9610: buildbot: uncaptured python exception (smtpd), but no failure > http://bugs.python.org/issue9610 opened by flox > > #9611: FileIO not 64-bit safe under Windows > http://bugs.python.org/issue9611 opened by pitrou > > #9613: Python considers pid longs under 64-bit Windows > http://bugs.python.org/issue9613 opened by pitrou > > #9614: _pickle is not entirely 64-bit safe > http://bugs.python.org/issue9614 opened by pitrou > > #9617: Buffered IO shouldn't ignore incoming signals during a partial > http://bugs.python.org/issue9617 opened by pitrou > > #9618: IDLE shell ignores all but first statement > http://bugs.python.org/issue9618 opened by cben > > #9620: Python 2.7 IDLE fails on OS X 10.6 > http://bugs.python.org/issue9620 opened by bpumali > > #9621: Graphviz output for 2to3 fixer patterns > http://bugs.python.org/issue9621 opened by gmattbond > > #9622: Allow to set profile/trace function globally > http://bugs.python.org/issue9622 opened by krisvale > > #9624: 2755 > http://bugs.python.org/issue9624 opened by Kartton > > #9625: argparse: Problem with defaults for variable nargs > http://bugs.python.org/issue9625 opened by thesociable > > #9628: runtests.sh -x doesn't work with more than two args (sed error > http://bugs.python.org/issue9628 opened by dmalcolm > > #9630: Reencode filenames when setting the filesystem encoding > http://bugs.python.org/issue9630 opened by haypo > > #9631: Python 2.7 installation issue for Linux gcc-4.1.0-3 (Fedora Co > http://bugs.python.org/issue9631 opened by spprakash > > #9632: Remove sys.setfilesystemencoding() > http://bugs.python.org/issue9632 opened by haypo > > #9633: pdb go stack up/down > http://bugs.python.org/issue9633 opened by Markus.Pröller > > #9634: Add timeout parameter to Queue.join() > http://bugs.python.org/issue9634 opened by kdlucas > > #9635: Add Py_BREAKPOINT and sys.breakpoint hooks > http://bugs.python.org/issue9635 opened by dmalcolm > > #9637: docs do not say that urllib uses HTTP_PROXY > http://bugs.python.org/issue9637 opened by kirikaza > > #9640: Improved doctest REPORT_*DIFFs with ELLIPSIS and/or NORMA
[Python-Dev] bbreport users - please upgrade
Hello, Recently I fixed parsing issues for failures like "hung for 30 minutes", where the last test was no longer detected, since r83543 (the regrtest progress bar, issue #8560). You need to update the script to see the change: http://code.google.com/p/bbreport/ Limitations: - the cache will not be updated, but future builds should be parsed correctly. - there's no documentation yet (except ./bbreport.py --help) -- Florent Xicluna ___ 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] Tracker status
There's no new issue posted this morning. I tried to post an issue, and an error occurred on submit. So... -- Florent 2010/8/3 Fred Drake > On Tue, Aug 3, 2010 at 1:01 AM, Ray Allen wrote: > > Is the tracker OK now? > > It's working for me. > > > -Fred > > -- > Fred L. Drake, Jr. > "A storm broke loose in my mind." --Albert Einstein > ___ > ___ 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] Fixing the GIL (with a BFS scheduler)
2010/5/16 Nir Aides > > *What can be done with it?* > > Here are some options: > 1) Abandon it - no one is interested, yawn. > 2) Take ideas and workarounds from its code and apply to other patches. > 3) Include it in the interpreter as an auxiliary (turn on with a runtime > switch) scheduler. > 4) Adopt it as the Python scheduler. > > > *Opinion?* > > I would like to have the possibility to "./configure --without-broken-GIL" or "./configure --with-bfs-scheduler" in Python 2.7 like we "./configure --with-computed-gotos" in 3.2. It will let the opportunity for the experienced user (or the distribution packager) to enable the threading optimizations on its platform, while it preserves the current behaviour by default. It will give more chance that people test this experimental configure option and report any issue they find, so it can be fixed and improved in the next bugfix version (2.7.1). Since the 2.7 branch will have long term support, it makes sense to support multi-core platforms. And more users of the fixed GIL means more bugfixes (even for 3.x branch). -- Florent ___ 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] bbreport
> Does it really need trunk? I've been running it under 2.6 without > problems, but I probably haven't explored all the options fully. > Now it works on 2.6 (or 2.5+pysqlite). Regards, -- Florent ___ 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] skip all TestCase methods if resource is not available
2010/4/1 anatoly techtonik: > On Thu, Apr 1, 2010 at 8:02 PM, Florent Xicluna wrote: (...) >> >> Put it in unittest.TestCase.setUp() method. It should be enough. > > It fails with error instead if skip, as it should according to > http://docs.python.org/library/unittest.html#unittest.TestCase.setUp > > "...any exception raised by this method will be considered an error > rather than a test failure..." > -- > anatoly t. > There's a special case for the "SkipTest" exception in 2.7 (even if it is not documented). try: self.setUp() except SkipTest as e: self._addSkip(result, str(e)) except Exception: result.addError(self, sys.exc_info()) But for 2.6, you're right: try: self.setUp() except: result.addError(self, self._exc_info()) -- Florent ___ 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] skip all TestCase methods if resource is not available
2010/4/1 anatoly techtonik:
> Currently it is possible to mark individual test methods with:
>test_support.requires('network')
>
> However, sometimes it is necessary to skip the whole TestCase if
> 'network' resource is not available counting the number of skipped
> tests at the same time. Are there any standard means to do this?
Put it in unittest.TestCase.setUp() method. It should be enough.
--
Florent
___
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] Add -3 and -Wd to the buildbots
2010/3/31 Brett Cannon: > On Wed, Mar 31, 2010 at 07:58, Ezio Melotti wrote: >> Hi, >> now that the py3k warnings are fixed (see >> http://bugs.python.org/issue7092) we should run the tests on the trunk >> buildbots with the -3 flags, in order to check if new warnings are >> introduced and possibly to uncover other ones. >> It might be a good idea to add the -Wd flag too, both on trunk and py3k. > > +1 from me. I agree, it could help to catch unexpected warnings or bugs earlier in the process. -- Florent ___ 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] Deprecation warnings in Python 2.7
2010/3/3 Florent Xicluna :
>
>>>> u'\xff' == bytearray('\xff') # It should raise an error because of '-bb'
> __main__:1: BytesWarning: Comparison between bytearray and string
> False
>>>> u'\xff' == '\xff'
> __main__:1: UnicodeWarning: Unicode equal comparison failed to convert
> both arguments to Unicode - interpreting them as being unequal
> False
I see that the BytesWarning (and -b option) is a 3.x feature.
I don't see the reason to keep it in 2.x, though
On the other side, UnicodeWarning is unused in 3.x, why we keep it
around? We may phase it out in 3.2?
--
Florent
___
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] Deprecation warnings in Python 2.7
2010/3/3 Raymond Hettinger :
>
> -1 for several reasons.
> 1) We've advertised -3 as part of TheOneTrueWay(tm). It's a core part of
> our transition story, so we should keep that as clean/consistent as
> possible. Deprecating the -3 switch seems like shooting ourselves in the
> foot.
Instead of deprecating the -3 switch, we can change it to a useful
alias (see below).
> 2) There is some chance that there will be a 2.8, so it isn't helpful to
> burn down our bridges.
> ISTM, nothing is currently broken and in need of "fixing" in 2.7.
> I don't see any advantage to conflating py3k warnings with other
> deprecations.
>
IMHO, the current deprecation and warning mechanism is not far from a
Rube Goldberg machine.
There's many options available, and it's not obvious both for the core
developer and for the end user.
On the python interpreter side, you have many options for the careful developer:
-Wdefault: display all warnings
-3:display all warnings except ImportWarning and
PendingDeprecationWarning
-Qwarn does nothing if -Wd is omitted, else warn about 2/1 or 2L/1
-Qwarnall does nothing if -Wd is omitted, else warn about 2.0/1 or 2j/1
-b/-bb (undocumented), warns about u'' == bytearray('')
-t/-tt warns about tab inconsistencies
Why -Qwarn needs -Wd to show its warnings?
And you should know that -3 implies -Qwarn, but it still mask
PendingDeprecationWarnings.
So you will not see the PendingDeprecationWarning issued by
cgi.parse_qs or shutil module (for example).
At the same time, you could notice that the mhlib module yields a
non-py3k DeprecationWarning about its removal in 3.0.
And now you want to compare unicode with bytes (ok, it's a very bad
idea, but it may happen when you sort dictionary keys, for example):
~ $ ./python
>>> u'\xff' == bytearray('\xff')# No warning?
False
>>> u'\xff' == '\xff'
__main__:1: UnicodeWarning: Unicode equal comparison failed to convert
both arguments to Unicode - interpreting them as being unequal
False
~ $ ./python -Wd -bb
>>> u'\xff' == bytearray('\xff')# It should raise an error because of '-bb'
__main__:1: BytesWarning: Comparison between bytearray and string
False
>>> u'\xff' == '\xff'
__main__:1: UnicodeWarning: Unicode equal comparison failed to convert
both arguments to Unicode - interpreting them as being unequal
False
Yeah, it may be confusing... "Comparison between bytearray and string"
is not really the correct message in 2.7. And why to keep these 2
warnings categories which are not used anywhere else in Python source
code? The behavior should be consistent between these 2 warnings, and
they may share the same category. Why we don't use a RuntimeWarning
here?
I still support the simplification of the warnings mechanism:
* -Qwarn/-Qwarnall should imply
-Wdefault -Wignore::ImportWarning -Wignore::PendingDeprecationWarning
(same as current -3 behavior)
* BytesWarning should be replaced by UnicodeWarning or RuntimeWarning
(and -b deprecated)
* -Wdefault should show all warnings (including py3k warnings)
* -3 should show the PendingDeprecationWarning in addition to its
current behavior.
(i.e. an alias for -Wdefault -Wignore::ImportWarning)
--
Florent
___
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] Deprecation warnings in Python 2.7
2010/3/3 Florent Xicluna wrote: > > I will post a list of the DeprecationWarnings in the python trunk, in a > followup message, for a review, and to help the discussion. > Here is the list of the "Classic" DeprecationWarnings: http://paste.pocoo.org/show/184931/ And the list of the "Py3k" DeprecationWarnings and SyntaxWarnings: http://paste.pocoo.org/show/184932/ I expect most of the things in the first list to be removed in 2.7 instead of being only deprecated. Then what is the best approach: 1) to separate better the Py3k warnings giving them a specific subclass Py3kDeprecationWarnings 2) to merge both lists because we consider deprecation related to 3.1 (and newer) ? 3) to keep things unchanged? -- Florent ___ 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] Deprecation warnings in Python 2.7
Hello, I would like to open a discussion on the meaning of deprecation warnings in 2.7. I assume, but I may be wrong, that 2.7 will be the last version in the 2.x branch. With this assumption, we should not find many things deprecated in 2.7 final. On the other hand, the list of py3k deprecation warnings is increasing a lot. And more users will probably start to move from 2.7 to the 3.1 release. While working on ticket #7092 and #7849, we started to discuss some proposals to simplify the deprecation warnings for 2.7. We discussed these 2 proposals: 1) in 2.6 there's no distinction between py3k and normal deprecations: they share the same category, DeprecationWarning. The "-3" switch enables the py3k DeprecationWarning and SyntaxWarning. Do we need to introduce a subclass Py3kDeprecationWarning in 2.7? It will make it easier to separate both kinds of deprecations (2.x and 3.x), and to filter them. 2) a different idea is to deprecate the "-3" switch and consider all py3k deprecations as normal deprecations. They will be hidden by default thanks to #7309. Since there's no future for the 2.x branch, it seems normal to consider the migration from 2.7 to 3.1 and show these warnings when the developer uses "-Wd" switch. What do you expect as DeprecationWarning in 2.7? I will post a list of the DeprecationWarnings in the python trunk, in a followup message, for a review, and to help the discussion. Best regards, -- Florent Xicluna ___ 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] Update xml.etree.ElementTree for Python 2.7 and 3.2
2010/2/28 Stefan Behnel > I would actually encourage Florent to do the opposite: act now and prepare > a patch against the latest official ET 1.2 and cET releases (or their SVN > version respectively) that integrates everything that is considered safe, > i.e. everything that makes cET compatible with ET and everything that seems > clearly stable in ET 1.3 and does not break compatibility for existing code > that uses ET 1.2. If you send that to Fredrik, I expect little opposition > to making that the base for a 1.2.8 release, which can then be folded back > into the stdlib. > > I exchanged some e-mails with Fredrik last week. Not sure if it will be 1.2.8 or 1.3, but now he is positive on the goals of the patch. I've commited all the changes and external fixes to a branch of the Mercurial repo owned by Fredrik. I'm expecting an answer soon. Branch based on the official etree repository (Mercurial): http://bitbucket.org/flox/et-2009-provolone/ Patch based on this branch: http://codereview.appspot.com/207048 (patch set 7 almost identical to the tip of the Mercurial repo) -- Florent ___ 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] contributor to committer
Hello, > > +1 > Thanks all, for your warm welcome. > > The usual caveats apply though: > - don't get carried away with the privileges > - even core devs still put patches on the tracker sometimes > - if in doubt, ask for advice on python-dev (or IRC) > - make sure to subscribe to python-checkins Usually I tend to be cautious. -- Florent ___ 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] contributor to committer
Hello, I am a semi-regular contributor for Python: I have contributed many patches since end of last year, some of them were reviewed by Antoine. Lately, he suggested that I should apply for commit rights. Some of the accepted patches: - Fix refleaks in py3k branch (#5596) - Extend stringlib fastsearch for various methods of bytes, bytearray and unicode objects (#7462 and #7622) - Various documentation patches, including FAQ Recently, I worked with Ezio to fix some tests and to silence py3k warnings in the test suite (#7092). And I am in touch with Fredrik to release ElementTree 1.3 and port it to Python 2.7 (#6472). As a final note, I would like to highlight a small script in the same spirit as Pyflakes: pep8.py I've contributed few patches for the version 0.5, released a week ago: http://pypi.python.org/pypi/pep8/ -- Florent Xicluna ___ 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] 'languishing' status for the tracker
R. David Murray bitdance.com> writes: > > I believe Brett mentioned the 'languishing' status for the tracker in > passing in his notes from the language summit. > I see a bunch of existing "Status / Resolution" choices. "open" / "later" "open" / "postponed" "open" / "remind" I did not find any documentation about them in both places: * http://wiki.python.org/moin/TrackerDocs/ "Tracker documentation" * http://www.python.org/dev/workflow/ "Issue workflow" Maybe these 2 documentation entry points could be merged and improved, first. They are not available on the same menu, and there's no cross-link between them: * "Issue workflow" from http://www.python.org/dev/ * "Tracker documentation" from http://bugs.python.org/ -- Florent Xicluna ___ 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] Update xml.etree.ElementTree for Python 2.7 and 3.2
Martin v. Löwis v.loewis.de> writes: > > > If the goals of Python ElementTree and Fredrik ElementTree diverge I don't > > see a problem with an amicable fork. > > I see one: Fredrik will not consider such a fork amicable. Of course, if > you could make him state in public that he is fine with a procedure that > you propose, go ahead. He had stated in public that he is fine with the > procedure I'm defending right now, that's why I'm defending it: no > substantial changes without his explicit approval (breakage due to > language changes is about the only exception - not even bug fixes are > allowed). Actually this should not be a fork of the upstream library. The goal is to improve stability and predictability of the ElementTree implementations in the stdlib, and to fix some bugs. I thought that it is better to backport the fixes from upstream than to fix each bug separately in the stdlib. I try to get some clear assessment from Fredrik. If it is accepted, I will probably cut some parts which are in the upstream library, but which are not in the API 1.2. If it is not accepted, it is bad news for the "xml.etree" users... It is qualified as a "best effort" to get something better for ET. Nothing else. -- Florent “Nobody expects the Spanish Inquisition!” ___ 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] Update xml.etree.ElementTree for Python 2.7 and 3.2
Stefan Behnel behnel.de> writes: > > Florent Xicluna, 18.02.2010 10:21: > > For this purpose, I grew the test suite from 300 lines to 1800 lines, > > using both the tests from upstream and the tests proposed by Neil Muller > > on issue #6232. > > Just a comment on this. While the new tests may work with ElementTree as > is, there are a couple of problem with them. They become apparent when > running the test suite against lxml.etree. > The test suite in the stdlib targets the "xml.etree" implementations only. > None of theses features is really required to hold for anything but the > current as-is implementation. > I agree. > So my impression is that many of the tests try to provide guarantees where > they cannot or should not exist, and even where the output is clearly > non-conforming with respect to standards. I don't think it makes sense to > put these into a regression test suite. > The test suite in the stdlib should try to cover every piece of code, even implementation details and edge cases. It guarantees that the implementation details do not change between minor releases. And it helps identify regression or evolution of the behavior when the library is updated. However we may identify better each category of tests: - tests for the ElementTree API 1.2, which should pass with lxml.etree, too. - tests of implementation details, which are not part of the specification. Additionally, these tests ensure that the C implementation can be used as a drop-in replacement of the Python implementation. It is a request expressed by many users of the "xml.etree" package. > That said, I should add that lxml's test suite includes about 250 unit > tests that work with (and adapt to) lxml.etree, ElementTree and > cElementTree, in Py2.3+ and Py3.x, and with ET 1.2 and ET 1.3. Although > certainly not a copy&run replacement, those should be much better suited to > accompany the existing stdlib tests. > Interesting. I may add these tests to the test_suite, if they are not completely redundant. -- Florent Xicluna ___ 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] deprecated stuff in standard library
Eric Smith trueblade.com> writes: > > This is because no one has gotten around to it. Create a bug report for > it, and preferably attach a patch with tests. > > Eric. > Actually, it gives py3k warning about "mhlib" + 2 others warnings: ./python/release26-maint/ $ ./python -Wd -3 -c "import mhlib" -c:1: DeprecationWarning: the mhlib module has been removed in Python 3.0; use the mailbox module instead ./python/release26-maint/Lib/mhlib.py:82: DeprecationWarning: in 3.x, mimetools has been removed in favor of the email package import mimetools ./python/release26-maint/Lib/mhlib.py:83: DeprecationWarning: the multifile module has been deprecated since Python 2.5 import multifile ___ 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] Update xml.etree.ElementTree for Python 2.7 and 3.2
Hello, On November 2006 and September 2007 Fredrik proposed to update "xml.etree" in Python 2.6 with the upcoming version 1.3. Now we are three years later, and the version shipped with 2.7alpha3 is 1.2.6. http://bugs.python.org/issue1602189#msg54944 http://bugs.python.org/issue1143 This would not be an issue, without the numerous bug reports accumulating on bugs.python.org. Most of these reports are waiting for the 1.3 release. Three months ago I worked on some of these issues, and after fixing them separately, I proposed a patch which merges the latest 1.3 snapshot (released in 2007) within the standard library. The aim is to provide a bug-free version of ElementTree/cElementTree in the standard library. For this purpose, I grew the test suite from 300 lines to 1800 lines, using both the tests from upstream and the tests proposed by Neil Muller on issue #6232. To ensure consistency, now the test_suite for the C implementation is the same as the Python implementation. http://bugs.python.org/issue6472 We are still interested with the upcoming release of ElementTree, but we should adopt a pragmatic approach: the xml.etree.ElementTree needs to be fixed for all Python users, even if 1.3 is not ready before 2.7beta. This is the only purpose of the patch. The patch sticks as much as possible to the upstream library. Initially I kept all the new features of the 1.3 branch in the patch. It should ease the integration of 1.3 final when it is released. With the last comment from Fredrik, I think to be more conservative: I plan to split out the experimental C API from the package. It is not required for the bug-fix release, and there's some risk of incompatibility with the final design of the API, which is still secret. As a side-effect, the patch will add some features and methods from the 1.3 branch (some of them where requested in the bug tracker): - ET.fromstringlist(), ET.tostringlist() - Element.extend(), Element.iter(), Element.itertext() - new selector engine - extended slicing However the highlighted features of this patch are: - to fix many bugs which were postponed because of 1.3 release - to ensure consistency between C and Python implementations (with tests) - to provide a better test coverage The patch is uploaded on Rietveld for review. The 3.x version of the patch will be updated after 2.x is merged in trunk. The patch covers documentation, too. http://codereview.appspot.com/207048/show It's time to comment and review. The proposed plan is to merge the patch in trunk before 2.7 alpha4. Best regards, -- Florent Xicluna ___ 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
