Re: [Python-Dev] pep8 reasoning
2014-04-25 18:10 GMT+02:00 Nick Coghlan : > > And if you're going to publish a tool to enforce your *personal* style > guide and include your own custom rules that the "this is OK" examples > in PEP 8 fail to satisfy, don't call it "pep8". Especially don't do > that if you're then going to ignore a core developer that calls you on > misappropriating python-dev's authority :( > > Regards, > Nick. > > P.S. https://github.com/jcrocholl/pep8/issues/256 > I am the current maintainer of this 'pep8' tool which was mentionned in a previous message. The tool was first published in 2006 by its original author. I take the feedbacks of the users in consideration, as much as I can. When something is unambiguously identified as a bug, I try to merge a patch in a timely manner. If it is an enhancement or a change of behavior, it is not in the priority list, of course. Two cases where signaled in the issue #256 last month, where the tool is arguably not compliant with some of the current conventions of the PEP. I've highlighted the reasons behind these checkers in the issue tracker directly. I disagree that they are in direct opposition with the PEP 8 coding conventions, though. The first concern is about 4 spaces indentation for continuation lines. For this point, the text of the PEP says "Use 4 spaces per indentation level", which lets room for interpretation (like some other parts of the PEP). However I changed some stuff in v1.5 to better isolate this case, so the user can add E121 safely to the ignore list: https://github.com/jcrocholl/pep8/blob/master/CHANGES.txt#L96-L105 The second concern is about compound statements, which are "generally discouraged" in the words of the PEP. Technically, there's no obvious way to implement "generally discouraged" in code. The compromise is to disable the check E701 and "use your own judgment" instead, if you feel it does not match you project's style guide. By the way, the example reported in #256 was only added last year to the PEP: def f(x): return 2*x And if we look closer to the PEP 8 history for the last two years (since March 2012), there were lots of changes and I've already updated the tool to catch up with some of them. However the tool has a large base of users, and I try to preserve some stability instead of removing features every time someone has an objection. In such case, what I recommend to the users is to configure the tool to ignore the checks which conflict with their own habits or conventions. I wrote some words in the documentation, one year ago, to explain what is the purpose of the tool and its limitations. There's no claim of any endorsement implicit or explicit by the PSF, the PSU or any other python developer :-) http://pep8.readthedocs.org/en/latest/intro.html#disclaimer I'm sorry if you felt that my previous answer was an offense to some python-dev authority, this is not intentional. Kind regards, -- Florent ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
2014-04-26 0:46 GMT+02:00 Nick Coghlan : > Florent is claiming the endorsement of the PEP 8 authors > and the consensus of python-dev for the tool's default behaviour > (as noted above, this makes it personal for me, as I am a > co-author of PEP 8). You're a co-author of PEP 8 since less than a year. I'm the maintainer of the pep8 tool since 2010. You should probably read the LICENSE file which is shipped with the pep8 too, and the disclaimer that I've posted previously. Never I engage the responsibility of the authors of the PEP 8 document, and I don't give any guarantee of being a *strict* PEP 8 compliance tool. However, you should notice that your ticket in the tracker is opened for 2 months only, and I did not flagged it as being resolved. As I've stated in my previous mail, I give priority to bugs over other requests. And even if you think it is a critical bug for yourself, it did not appear like that for the thousands of people which used the library for the last few years. But if you read the documentation carefully, you can see that I've already excluded some checks from the default behavior in the previous releases, when there was an argument which was backed by the PEP 8 itself: "In the default configuration, the checks E123, E133, E226, E241 and E242 are ignored because they are not rules unanimously accepted, and PEP 8 does not enforce them." http://pep8.readthedocs.org/en/latest/intro.html#error-codes The question stay opened for issue #256 and codes E121 and E701. As I said before, they are not against PEP 8, they interpret some words. If you're nitpicking, you can probably reject half the checks of the pep8 tool with similar allegations. > I *want* to be able to recommend this tool universally. But at the moment, > I cannot, as its name is a lie: it enforces rules I don't personally agree > with. Maybe I prefer you don't recommend it in the PEP 8 documentation if it means I'll be tied to your "personal preferences" and that I'll be forced to patch it every now and then when you change a line, or a punctuation in a PEP 8 example. At the end, I find you're a bit rude when you come to this project which is not endorsed by the PSF or any Python-Dev related entity and you say "this project is wrong, because the developer did not obey to me when I order to remove that feature". You're more sympathetic and less in a hurry when it comes to some languishing bug on b.p.o :-) If you're so impatient, let's fork it and put in in cpython/Tools/ I would not fight against it. Sincerely, -- Florent ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
2014-04-26 1:46 GMT+02:00 Guido van Rossum : > I think the tool's name is unfortunate. The first time I heard about it I > was having an in-person discussion with a developer who (I thought) said > that "PEP 8" was okay with his code (which I knew couldn't be the case) but > in fact he meant to say that (some configuration of) "pep8" didn't mind it. > This took some time to sort out and it would have avoided if the tool had > had a better name. > > That said I think it's a great tool. Thank you, Actually I did not choose the name. I just took over the project 4 years ago by accident because I had some pull requests languishing and the author of the project was no longer interested in it. I agree that the name is a source of confusion in some cases. I've mitigated some conflicts with PEP 8 by incitating contributors to write "flake8" extensions instead of pushing more features into "pep8" itself, and also I tried to define a default configuration which is "good enough" to support the PEP 8 recommendations. -- Florent ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pep8 reasoning
2014-04-27 21:34 GMT+02:00 Chris Barker : > > wow! just looked at that part of the PEP again, and that is a LOT of > options. Is it impossible to come to any consensus on this? And as it > happens, my favorite is not in there, though as far as I can tell not > forbidden: > > foo = long_function_name(var_one, >var_two, >var_three, >var_four) > > > Anyway -- is there a point in trying to standardize this a bit more in PEP8, > or has that battle long since been fought and conceded ? > FWIW, the tool pep8 has introduced continuation line indentation checks in 2012, based on the PEP 8 recommendations which were active at this date, and doing few extrapolations on cases which were not directly covered by the document (pep8.py v1.2, issue #64). Then we had a lot of iterations with the users of the library, and we've added more flexibility to cover the various styles which were in the spirit of PEP 8, and which give some added value for code readability. The end result of this work can be seen in the test suite : * more than 300 lines of rejected indentations: https://github.com/jcrocholl/pep8/blob/master/testsuite/E12.py * and more than 600 lines of acceptable cases: https://github.com/jcrocholl/pep8/blob/master/testsuite/E12not.py I don't think that the PEP 8 document should go in so much details, though. However these examples might help to have pragmatic discussions about which rules we want to recommend. Do not hesitate to give feedback here, or on the issue tracker. There's also a code-quality mailing-list which covers a little more than pep8.py: https://mail.python.org/mailman/listinfo/code-quality -- Florent ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] stat module in C -- what to do with stat.py?
we already have "_pyio.py", we could have "_pystat.py". my 2c -- Florent Xicluna 2013/6/20 Christian Heimes : > Hello, > > I have re-implemented the entire stat module in C. [1] It's a necessary > step to fix portability issues. For most constants POSIX standards > dictate only the name of the constant and its meaning but not its value. > Only the values of permission bits (0644 == rw-r--r--) have fixed values. > > For example S_IFDIR is usually 0o4 but it might be 0o2 on some > platforms. Common file types seem to have the same value on all > important platforms. It's the only reason we were able to get away with > stat.py. But uncommon file types like door, event port and whiteout > don't have sensible default values. The C implementation is able to pick > up the platform's values easily. > > What shall I do about stat.py? statmodule.c implements all features of > stat.py so there is no point in using it in CPython. It's one Python > file less to load on every startup. However it might still be useful to > alternative implementations of Python such as Jython or PyPy. > > 1) keep the file stat.py but let it be shadowed by the builtin stat > module. Antoine loathes my hack... > 2) rename stat.py to _stat.py > 3) remove stat.py > > Opinions? > > Christian > > [1] http://bugs.python.org/issue11016 > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/florent.xicluna%40gmail.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3
2012/2/8 Nick Coghlan > On Wed, Feb 8, 2012 at 10:04 PM, Antoine Pitrou > wrote:> > > It's not frozen, it's actually maintained. > > Indeed, it sounds like the most appropriate course (if we don't hear > otherwise from Fredrik) may be to just update PEP 360 to acknowledge > current reality (i.e. the most current release of ElementTree is > actually the one maintained by Florent in the stdlib). > Actually, it was part of my learning curve to the development of Python, as you can see on the thread of the issue http://bugs.python.org/issue6472 . I spent some time between December 2009 and March 2010 to merge the "experimental" 1.3 in the standard library, both for 2.7 and 3.2. Upstream, there were 2 different test suites for the Python and the C implementation, but I merged them in a single test suite, and I've patched the C accelerator to conform to the same behaviour as the Python reference module. With the knowledge I acquired, I chased some other bugs related to ElementTree at the same time. With the feedback and some support coming from Antoine, Fredrik and Stefan we shaped a decent ElementTree 1.3 for the standard library. I am not aware of any effort to maintain the ElementTree package outside of the standard library since I did this merge. So, in the current state, we could consider the standard library package as the most up to date and stable version of ElementTree. I concur with Eli proposal to set the C accelerator as default : the test suite ensures that both implementations behave the same. I cannot commit myself for the long-term maintenance of ElementTree in the standard library, both because I don't have a strong interest in XML parsing, and because I have many other projects which keep me away from core python development for long period of times. However, I think it is a good thing if all the packages which are part of the standard library follow the same rules. We should try to find an agreement with Fredrik, explicit or implicit, which delegates the evolution and the maintenance of ElementTree to the Python community. IIRC, we have other examples in the standard library where the community support helped a lot to refresh a package where the original maintainer did not have enough time to pursue its work. I'll note that this change isn't *quite* as simple as Eli's > description earlier in the thread may suggest, though - the test suite > also needs to be updated to ensure that the Python version is still > fully exercised without the C acceleration applied. And such an an > alteration would definitely be an explicit fork, even though the user > facing API doesn't change - we're changing the structure of the code > in a way that means some upstream deltas (if they happen to occur) may > not apply cleanly. > > The test suite is a "de facto" fork of the upstream test suites, since upstream test suites do not guarantee the same behaviour between cElementTree and ElementTree. -- Florent Xicluna ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3
2012/2/10 Eli Bendersky > > > > Thanks for the input, Florent. So, to paraphrase, there already are > code changes in the stdlib version of ET/cET which are not upstream. > You made it explicit about the tests, so the question is only left for > the modules themselves. Is that right? > The port of ElementTree to Python 3000 was done in the standard library only. The work was done back in 2006, 2007 and 2008. There was never a public version of ElementTree for Python 3 outside of the standard library. It is already a significant change from the upstream branch (many changes in the C extension code). Then when I enforced the same test suite for both implementation, I have fixed many things in the C extension module too. To my knowledge, these fixes were not included upstream. Since two years, there was regular maintenance of the package in the standard library, but none of the patch were integrated upstream. I hope it answers the question, -- Florent Xicluna ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3
2012/2/10 Nick Coghlan : > > Most orphan modules in the stdlib aren't like that - yes, their APIs > stagnate (because nobody feels they have the authority and/or > expertise to make potentially controversial decisions), but for many > of them, that's not a particularly bad thing. You're right, and sometimes a contributor steps in and propose a PEP to move things forward for a so-called orphan module. If I'm not wrong, it was the case for StringIO, pickle, distutils, wsgiref and optparse even if each of these packages has its own story. -- Florent Xicluna ___ Python-Dev mailing list [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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
[email protected]
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
[email protected]
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 [email protected] 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
[email protected]
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
[email protected]
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 [email protected] 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 [email protected] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[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 [email protected] 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
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] C bindings calling tmpfile() blocks interrupt signal
I discovered an issue on Mac OS X that seems to relate to signal
handling. I have a C binding in which I call the standard tmpfile()
function. After calling it, I can't break Python anymore with CTRL-C.
Investigating the Darwin source code for tmpfile() (and FreeBSD, they
are the same) , I found that the function is mucking with the signals:
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdio/tmpfile.c?rev=1.9&content-type=text/x-cvsweb-markup
Is this considered a Python issue, or an OS issue? I ran a simple test
against the interrupt signal, which didn't show any wrong behavior:
static void intcatcher(int sig) {
printf("Interrupt catched\n");
exit(1);
}
int main(int argc, char **argv) {
signal(SIGINT, intcatcher);
printf("Press CTRL-C to interrupt...\n");
tmpfile();
while (1)
;
return 0;
}
But with my threaded Python code, SIGINT doesn't work anymore after my
binding has called tmpfile().
Florent
--
Florent Pillet http://www.florentpillet.com
Freelance software developer/consultant - Palm OS & Mac OS X
ICQ: 117292463Skype: callto://florent.pillet
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C bindings calling tmpfile() blocks interrupt signal
On 07/07/05, Michael Hudson <[EMAIL PROTECTED]> wrote: >> > > But with my threaded Python code, SIGINT doesn't work anymore after my > > binding has called tmpfile(). > > Oh, threads. > > Which version of Python are you using? 2.3.5, the one that ships with Mac OS X 10.4. I have a 2.4.x install somewhere, I'll give it a go. But you're right, it's probably because of threads. Now I'm trying to determine whether this is a Python bug or a Mac OS X bug... Florent -- Florent Pillet http://www.florentpillet.com Freelance software developer/consultant - Palm OS & Mac OS X ICQ: 117292463Skype: callto://florent.pillet ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
