Re: [Python-Dev] pep8 reasoning
On 25/04/2014 03:00, Chris Angelico wrote: On Fri, Apr 25, 2014 at 11:40 AM, Allen Li wrote: 2) If you're starting a new project, follow PEP8 (or the standards for the language you're using) to preserve CONSISTENCY. Don't forget that PEP 8 is not the standard for the Python language, only the Python stdlib. I'm not sure I agree with that. PEP 8 *is* the standard for the language, in that there isn't anything else. Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ 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
On 25/04/2014 04:03, Barry Warsaw wrote: On Apr 25, 2014, at 12:00 PM, Chris Angelico wrote: Don't forget that PEP 8 is not the standard for the Python language, only the Python stdlib. Particularly, there's no strong reason to follow some of its lesser advices (eg spaces rather than tabs, the exact maximum line length) for new projects; I'd say it depends. If the code is going to be shared with people outside of your organization (e.g. open source libraries), then there's a strong motivation to be consistent throughout the community, which means PEP 8. Right, so for me this means even in a private code base, there are big benefits to using PEP 8; everything looks the same, whether it's a third party library, python core or your own code... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ 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
On 25/04/2014 13:09, Chris Withers wrote: > On 25/04/2014 04:03, Barry Warsaw wrote: >> On Apr 25, 2014, at 12:00 PM, Chris Angelico wrote: >> >>> Don't forget that PEP 8 is not the standard for the Python language, >>> only the Python stdlib. Particularly, there's no strong reason to >>> follow some of its lesser advices (eg spaces rather than tabs, the >>> exact maximum line length) for new projects; >> >> I'd say it depends. If the code is going to be shared with people >> outside of >> your organization (e.g. open source libraries), then there's a strong >> motivation to be consistent throughout the community, which means PEP 8. > > Right, so for me this means even in a private code base, there are big > benefits to using PEP 8; everything looks the same, whether it's a third > party library, python core or your own code... I essentially had this conversation via my blog a couple of years ago: http://ramblings.timgolden.me.uk/2012/03/27/pep8-or-not/ http://ramblings.timgolden.me.uk/2012/03/29/more-on-pep8/ http://ramblings.timgolden.me.uk/2012/04/09/pep8-it-is-then/ and was quite surprised at the strength of feeling evoked. As you can even tell from the titles of the posts, I ended up by accepting that, even though I'm at liberty to apply my own format to my own code, it would be more of a community-friendly idea to use [near-enough] PEP8 regardless. As you can also see from the comments throughout, YMMV. :) TJG ___ 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
On Fri, Apr 25, 2014 at 1:28 PM, Guido van Rossum wrote: > On Apr 24, 2014 7:01 PM, "Chris Angelico" wrote: >> >> On Fri, Apr 25, 2014 at 11:40 AM, Allen Li wrote: >> > 2) If you're starting a new project, follow PEP8 (or the standards for >> >the language you're using) to preserve CONSISTENCY. >> >> Don't forget that PEP 8 is not the standard for the Python language, >> only the Python stdlib. > > That is not true. It is mandatory for the stdlib, for other projects it is > optional, but still recommend. Hmm. There've been a good few conversations on python-list where people have been reminded that PEP 8 is *not* all that important for other projects (beyond that it's an already-written style guide - when you're starting a C project you can argue style guides for weeks, but when you start a Python project you can just say "PEP 8" and skip the bikeshedding), which I took to mean that it's on par with any other style guide; but looking at it the other way, it can be seen as a strong recommendation. I'm just not sure about the word "standard" there - to me a standard is something that you MUST follow, like RFCs for internet protocols. But that's just a matter of terminology, I guess. ChrisA ___ 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
Chris Withers writes: > On 25/04/2014 04:03, Barry Warsaw wrote: > > I'd say it depends. If the code is going to be shared with > > people outside of your organization (e.g. open source libraries), > > then there's a strong motivation to be consistent throughout the > > community, which means PEP 8. > > Right, so for me this means even in a private code base, there are big > benefits to using PEP 8; everything looks the same, whether it's a third > party library, python core or your own code... Indeed. But channeling the FLUFL here, I would say that in your situation where people have already developed a large code base that apparently isn't shared much (if at all) outside the organization, they've already paid the price of nonconformity for the existing code base. If there's a formal standard, and you don't expect the "insiders only" policy to change soon (assuming it actually exists), I don't see why you would push for a change to PEP 8 at all. If you *don't* have a formal standard and existing code is a mixture of styles, I'd be very tempted to say "PEP 8 for new modules" (even if some of the mix is consistent -- for example all the ex-C++ programmers like CamelCase). Ditto if you're going to be developing modules to publish as OSS. And from *outside* of your organization, it's a no-brainer. PEP 8 is what Python itself and most 3rd party OSS modules use. Getting your people to use PEP 8 will make it a lot easier for them to learn to read Python core and stdlib code, and once they start reading --- why, the obvious next step is *contributing*. Yay! ;-) ___ 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
On Apr 25, 2014, at 11:06 PM, Stephen J. Turnbull wrote: >And from *outside* of your organization, it's a no-brainer. PEP 8 is >what Python itself and most 3rd party OSS modules use. Getting your >people to use PEP 8 will make it a lot easier for them to learn to >read Python core and stdlib code, and once they start reading --- why, >the obvious next step is *contributing*. Yay! ;-) And if you do deviate from PEP 8, I think it's quite helpful to publish a style guide outlining the deviations. It helps others contribute to your project. Of course, the first line of that style guide should be: `PEP 8`_ is the basis for this style guide so its recommendations should be followed except for the differences outlined here. :) cheers, -Barry signature.asc Description: PGP signature ___ 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
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2014-04-18 - 2014-04-25) 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 counts and deltas: open4600 (+21) closed 28521 (+28) total 33121 (+49) Open issues with patches: 2126 Issues opened (41) == #21301: pathlib missing Path.expandvars(env=os.environ) http://bugs.python.org/issue21301 opened by Alain.Mellan #21302: time.sleep (floatsleep()) should use clock_nanosleep() on Linu http://bugs.python.org/issue21302 opened by shankarunni #21304: PEP 466: Backport hashlib.pbkdf2_hmac to Python 2.7 http://bugs.python.org/issue21304 opened by alex #21305: PEP 466: update os.urandom http://bugs.python.org/issue21305 opened by ncoghlan #21306: PEP 466: backport hmac.compare_digest http://bugs.python.org/issue21306 opened by ncoghlan #21307: PEP 466: backport hashlib changes http://bugs.python.org/issue21307 opened by ncoghlan #21308: PEP 466: backport ssl changes http://bugs.python.org/issue21308 opened by ncoghlan #21309: Confusing "see also" for generic C-level __init__ methods in h http://bugs.python.org/issue21309 opened by r.david.murray #21310: ResourceWarning when open() fails with io.UnsupportedOperation http://bugs.python.org/issue21310 opened by vadmium #21312: Update thread_foobar.h to include timed locking and TLS suppor http://bugs.python.org/issue21312 opened by Jack.McCracken #21313: Py_GetVersion() is broken when using mqueue and a long patch n http://bugs.python.org/issue21313 opened by eric.snow #21314: Bizarre help http://bugs.python.org/issue21314 opened by Vedran.ÄaÄiÄ #21315: email._header_value_parser does not recognise in-line encoding http://bugs.python.org/issue21315 opened by valhallasw #21316: mark test_devpoll to be meaningfull only for Solaris http://bugs.python.org/issue21316 opened by AapoRantalainen #21318: sdist fails with symbolic links do non-existing files http://bugs.python.org/issue21318 opened by jgosmann #21319: WindowsRegistryFinder never added to sys.meta_path http://bugs.python.org/issue21319 opened by eric.snow #21320: dict() allows keyword expansion with integer keys, e.g. dict(* http://bugs.python.org/issue21320 opened by Cyphase #21321: itertools.islice() doesn't release reference to the source ite http://bugs.python.org/issue21321 opened by Anton.Afanasyev #21322: Pathlib .owner() and .group() methods fail on broken links http://bugs.python.org/issue21322 opened by inigoserna #21323: CGI HTTP server not running scripts from subdirectories http://bugs.python.org/issue21323 opened by k.s.solnushkin #21324: dbhash/bsddb leaks random memory fragments to a database http://bugs.python.org/issue21324 opened by wodny #21325: Missing Generic EXIF library for images in the standard librar http://bugs.python.org/issue21325 opened by karlcow #21326: asyncio: request clearer error message when event loop closed http://bugs.python.org/issue21326 opened by mark.dickinson #21327: socket.type value changes after using settimeout() http://bugs.python.org/issue21327 opened by giampaolo.rodola #21328: Resize doesn't change reported length on create_string_buffer( http://bugs.python.org/issue21328 opened by Dustin.Oprea #21329: configparser can't parse MySQL style config http://bugs.python.org/issue21329 opened by dveeden #21331: Reversing an encoding with unicode-escape returns a different http://bugs.python.org/issue21331 opened by Sworddragon #21332: subprocess bufsize=1 docs are misleading http://bugs.python.org/issue21332 opened by raylu #21333: Document recommended exception for objects that shouldn't be p http://bugs.python.org/issue21333 opened by sschwarzer #21335: Update importlib.__init__ to reset _frozen_importlib's loader http://bugs.python.org/issue21335 opened by brett.cannon #21337: Add tests for Tix http://bugs.python.org/issue21337 opened by zach.ware #21338: Silent mode for compileall http://bugs.python.org/issue21338 opened by takluyver #21339: IDLE crash on OS X 1.9 upon shut-down with many windows open http://bugs.python.org/issue21339 opened by rhettinger #21340: Possible concurrency bug in asyncio, AttributeError in tasks.p http://bugs.python.org/issue21340 opened by Jack.Murray #21341: Configuring 'font' with ttk.Style for 'TEntry' does not change http://bugs.python.org/issue21341 opened by barron #21342: multiprocessing RLock and Lock raise incorrect exceptions when http://bugs.python.org/issue21342 opened by steinn #21343: os.path.relpath returns inconsistent types http://bugs.python.org/issue21343 opened by Matt.Bachmann #21344: save scores or ratios in difflib get_close_matches http://bugs.python.org/issue21344 opened by russellballestrini #21345: multiprocessing.Pool._handle_workers sleeps too long http://bugs.python.org/issue21345 opened by Johannes.Baiter #21347: Don't use a list argument together with shell=True in su
Re: [Python-Dev] pep8 reasoning
On 25 April 2014 10:36, Barry Warsaw wrote: > On Apr 25, 2014, at 11:06 PM, Stephen J. Turnbull wrote: > >>And from *outside* of your organization, it's a no-brainer. PEP 8 is >>what Python itself and most 3rd party OSS modules use. Getting your >>people to use PEP 8 will make it a lot easier for them to learn to >>read Python core and stdlib code, and once they start reading --- why, >>the obvious next step is *contributing*. Yay! ;-) > > And if you do deviate from PEP 8, I think it's quite helpful to publish a > style guide outlining the deviations. It helps others contribute to your > project. Of course, the first line of that style guide should be: > > `PEP 8`_ is the basis for this style guide so its recommendations > should be followed except for the differences outlined here. 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 -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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
[Python-Dev] ConfigParser mangles keys with special chars
Hi,
I noticed configparser does behave in a surprising way when a key
has a special meaning in ini-format.
Consider this example:
>>> cp = configparser.ConfigParser()
>>> cp.read_dict({'DEFAULT': {';foo': 'bar'}})
>>> cp.write(sys.stdout)
[DEFAULT]
;foo = bar
Now when reading this again, ";foo = bar" will be a comment and
ignored. There's probably similiar behaviour in other corner cases
(like if you'd use "[foo]" as key for example).
While it seems ConfigParser doesn't do any escaping as all, I'm
thinking it should at least raise some exception when such a value is
trying to be set.
I'd expect writing something and then reading it back via the same
configparser to *always* result in the same data, as long as writing
worked without error.
Thoughts? Should I submit a bug report?
Florian
--
() ascii ribbon campaign - stop html mailwww.asciiribbon.org
/\ www.the-compiler.org | I love long mails http://email.is-not-s.ms/
To give happiness is to deserve happiness.
pgp8GxHvCh_Ah.pgp
Description: PGP signature
___
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] ConfigParser mangles keys with special chars
On Fri, Apr 25, 2014 at 10:22 AM, Florian Bruhin wrote: > While it seems ConfigParser doesn't do any escaping as all, I'm > thinking it should at least raise some exception when such a value is > trying to be set. > > I'd expect writing something and then reading it back via the same > configparser to *always* result in the same data, as long as writing > worked without error. > > Thoughts? Should I submit a bug report? I believe you should, if only to provide a place to record why no change gets made. Had ConfigParser been more careful from the beginning, that would have been really good. At this point, it would be a backward-incompatible change, so it's unlikely such a change could be allowed to affect existing code. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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] ConfigParser mangles keys with special chars
On 4/25/2014 12:46 PM, Fred Drake wrote: On Fri, Apr 25, 2014 at 10:22 AM, Florian Bruhin wrote: While it seems ConfigParser doesn't do any escaping as all, I'm thinking it should at least raise some exception when such a value is trying to be set. I'd expect writing something and then reading it back via the same configparser to *always* result in the same data, as long as writing worked without error. Thoughts? Should I submit a bug report? I believe you should, if only to provide a place to record why no change gets made. When you do, add lukasz.langa as nosy https://docs.python.org/devguide/experts.html#experts You might also take a look in test/test_configparser.py to see if any edge cases are tested for. Had ConfigParser been more careful from the beginning, that would have been really good. At this point, it would be a backward-incompatible change, so it's unlikely such a change could be allowed to affect existing code. -Fred -- Terry Jan Reedy ___ 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] ConfigParser mangles keys with special chars
On 04/25/2014 09:46 AM, Fred Drake wrote: At this point, it would be a backward-incompatible change, so it's unlikely such a change could be allowed to affect existing code. All bug-fixes are backwards-incompatible, yet we fix them anyway. ;) It seems to me the real question is do we fix it in 3.5 only, or can we fix it in 3.4 and previous? And the answer depends on whether this behavior can be reasonably relied on. -- ~Ethan~ ___ 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] ConfigParser mangles keys with special chars
On 4/25/2014 1:41 PM, Ethan Furman wrote: On 04/25/2014 09:46 AM, Fred Drake wrote: At this point, it would be a backward-incompatible change, so it's unlikely such a change could be allowed to affect existing code. All bug-fixes are backwards-incompatible, yet we fix them anyway. ;) It seems to me the real question is do we fix it in 3.5 only, or can we fix it in 3.4 and previous? And the answer depends on whether this behavior can be reasonably relied on. And that depends on whether the current thought-to-be-buggy behavior is specified by the doc, compatible with an ambiguous or under-specified doc, or prohibited by the doc (because the doc specified something else). I leave it to someone to carefully read the doc, but a brief glance indicates "There are nearly as many INI format variants as there are applications using it. configparser goes a long way to provide support for the largest sensible set of INI styles available." So I wonder whether the thought-to-be-buggy behavior is actually buggy with respect to *all* the supported styles or just some of them. -- Terry Jan Reedy ___ 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] ConfigParser mangles keys with special chars
On Fri, Apr 25, 2014 at 2:45 PM, Terry Reedy wrote: > I leave it to someone to carefully read the doc, but a brief glance > indicates "There are nearly as many INI format variants as there are > applications using it. configparser goes a long way to provide support for > the largest sensible set of INI styles available." So I wonder whether the > thought-to-be-buggy behavior is actually buggy with respect to *all* the > supported styles or just some of them. Given that most variants are completely undocumented, answering this is sufficiently intractable for me to call it intractable. We've also run into compatibility issues because some applications treated the "parser" object as an in-memory configuration database throughout the process lifetime, updating values with non-string values of various sorts. Given the age of the module, the existing number of uses of undocumented accidents of implementation is very large. Fixing "bugs" like this has an excellent track record of uncovering these uses, so... we've grown a bit wary. It's not unheard of for projects to fork their own copies of configparser because of changes to the stdlib version. (No, I haven't done a census of such cases, but I do know of at least one in a popular package.) -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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] ConfigParser mangles keys with special chars
On 04/25/2014 11:54 AM, Fred Drake wrote: On Fri, Apr 25, 2014 at 2:45 PM, Terry Reedy wrote: I leave it to someone to carefully read the doc, but a brief glance indicates "There are nearly as many INI format variants as there are applications using it. configparser goes a long way to provide support for the largest sensible set of INI styles available." So I wonder whether the thought-to-be-buggy behavior is actually buggy with respect to *all* the supported styles or just some of them. Given that most variants are completely undocumented, answering this is sufficiently intractable for me to call it intractable. We've also run into compatibility issues because some applications treated the "parser" object as an in-memory configuration database throughout the process lifetime, updating values with non-string values of various sorts. Given the age of the module, the existing number of uses of undocumented accidents of implementation is very large. Fixing "bugs" like this has an excellent track record of uncovering these uses, so... we've grown a bit wary. It's not unheard of for projects to fork their own copies of configparser because of changes to the stdlib version. (No, I haven't done a census of such cases, but I do know of at least one in a popular package.) Seems reasonable. Perhaps an enhancement request then: a way to provide a regex that keys must match, with an exception raised when a key doesn't. That way the safety belt could be used when desired. -- ~Ethan~ ___ 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-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] ConfigParser mangles keys with special chars
On Fri, Apr 25, 2014 at 3:12 PM, Ethan Furman wrote: > Perhaps an enhancement request then: a way to provide a regex that keys > must match, with an exception raised when a key doesn't. That way the > safety belt could be used when desired. You can subclass the parser class you're using and override the ``optionxform`` method to perform the checks you want for option names. I don't know if current versions provide a similar hook to validate section names; providing *that* would be an excellent enhancement. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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
On 04/25/2014 12:45 PM, Florent wrote: 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". 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 problem is that you've named it pep8. To me, that means I can run it and get PEP 8 results. If I have to add a manual configuration to get actual PEP 8 semantics, it's a buggy tool. For a similar example, I am the author/maintainer of enum34, which purports to be the backport of Python's 3.4 enum class. While I could go and make changes to it to better match my style, or even the styles of other users, calling it enum34 after that would be misleading as some one couldn't then switch from using enum34 in Python 3.2 to using the default enum in Python 3.4. If you had extra switches to turn on extra behavior, that would be fine. Leaving it as it is, and calling it something else would be fine. But as it stands now, with the name of pep8 and the behavior of failing on the PEP 8 document... well, that's false advertising. -- ~Ethan~ ___ 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
On 04/25/2014 01:55 PM, Ethan Furman wrote: > On 04/25/2014 12:45 PM, Florent wrote: >> 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". >> >> 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 problem is that you've named it pep8. To me, that means I can run > it and get PEP 8 results. If I have to add a manual configuration to > get actual PEP 8 semantics, it's a buggy tool. > > For a similar example, I am the author/maintainer of enum34, which > purports to be the backport of Python's 3.4 enum class. While I could > go and make changes to it to better match my style, or even the styles > of other users, calling it enum34 after that would be misleading as some > one couldn't then switch from using enum34 in Python 3.2 to using the > default enum in Python 3.4. > > If you had extra switches to turn on extra behavior, that would be > fine. Leaving it as it is, and calling it something else would be > fine. But as it stands now, with the name of pep8 and the behavior of > failing on the PEP 8 document... well, that's false advertising. I think this fuss is unreasonable and unwarranted. I'd like to thank Florent for taking the time to maintain an extremely-useful tool that makes it feasible to keep to a consistent PEP 8 style throughout a large codebase with many contributors, and I think he should have the leeway as maintainer to make the necessary judgment calls about precisely which PEP 8 recommendations are reported precisely how by the tool, given that: - we aren't talking about real variance from the spirit or recommendations of PEP 8 (though you wouldn't know it from some of the rhetoric here about "personal preferences") - the tool makes it very easy to turn off whichever errors you don't prefer to enforce. - PEP 8 changes regularly (as Florent noted, the offending code example was only added recently), and there is value in the automated tool maintaining some stability for its users. Personally, I would much rather see pep8.py err on the side of being too strict with PEP 8's recommendations than too loose. Again, it's not hard to turn off the ones you don't want. If python-dev wants to control the precise behavior of pep8.py, bring it into the standard library and adopt maintenance of it. Otherwise, please give Florent some grace. Carl ___ 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
On Apr 25, 2014, at 5:52 PM, Carl Meyer wrote: > On 04/25/2014 01:55 PM, Ethan Furman wrote: >> On 04/25/2014 12:45 PM, Florent wrote: >>> 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". >>> >>> 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 problem is that you've named it pep8. To me, that means I can run >> it and get PEP 8 results. If I have to add a manual configuration to >> get actual PEP 8 semantics, it's a buggy tool. >> >> For a similar example, I am the author/maintainer of enum34, which >> purports to be the backport of Python's 3.4 enum class. While I could >> go and make changes to it to better match my style, or even the styles >> of other users, calling it enum34 after that would be misleading as some >> one couldn't then switch from using enum34 in Python 3.2 to using the >> default enum in Python 3.4. >> >> If you had extra switches to turn on extra behavior, that would be >> fine. Leaving it as it is, and calling it something else would be >> fine. But as it stands now, with the name of pep8 and the behavior of >> failing on the PEP 8 document... well, that's false advertising. > > I think this fuss is unreasonable and unwarranted. > > I'd like to thank Florent for taking the time to maintain an > extremely-useful tool that makes it feasible to keep to a consistent PEP > 8 style throughout a large codebase with many contributors, and I think > he should have the leeway as maintainer to make the necessary judgment > calls about precisely which PEP 8 recommendations are reported precisely > how by the tool, given that: > > - we aren't talking about real variance from the spirit or > recommendations of PEP 8 (though you wouldn't know it from some of the > rhetoric here about "personal preferences") > > - the tool makes it very easy to turn off whichever errors you don't > prefer to enforce. > > - PEP 8 changes regularly (as Florent noted, the offending code example > was only added recently), and there is value in the automated tool > maintaining some stability for its users. > > Personally, I would much rather see pep8.py err on the side of being too > strict with PEP 8's recommendations than too loose. Again, it's not hard > to turn off the ones you don't want. > > If python-dev wants to control the precise behavior of pep8.py, bring it > into the standard library and adopt maintenance of it. Otherwise, please > give Florent some grace. > > Carl Carl’s post mirrors my own thoughts and it’s said much better than I could have. pep8.py doesn’t violate PEP8, it just takes a stricter view of it. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
On 25 April 2014 17:52, Carl Meyer wrote: > On 04/25/2014 01:55 PM, Ethan Furman wrote: >> On 04/25/2014 12:45 PM, Florent wrote: >>> 2014-04-25 18:10 GMT+02:00 Nick Coghlan: > I think this fuss is unreasonable and unwarranted. > > I'd like to thank Florent for taking the time to maintain an > extremely-useful tool that makes it feasible to keep to a consistent PEP > 8 style throughout a large codebase with many contributors, and I think > he should have the leeway as maintainer to make the necessary judgment > calls about precisely which PEP 8 recommendations are reported precisely > how by the tool, given that: > > - we aren't talking about real variance from the spirit or > recommendations of PEP 8 (though you wouldn't know it from some of the > rhetoric here about "personal preferences") Yes we are. My name is on PEP 8 as one of the three co-authors, and my request to downgrade anything in the "pep8" tools that is not *explicitly* disallowed by the PEP to be a warning at most has been ignored. If you read the GitHub issue, you can see 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, yet claims to be based on a PEP I helped write. There is a way to get changes made to the common guidelines in PEP 8: you bring your case to python-dev and argue for the adoption of those rules in the standard library. If a tool doesn't claim to be speaking in my name, I don't care what rules it enforces. If a tool adds extra warnings, I also don't care. But "pep8" currently claims as errors code that is listed *in PEP 8 itself* as acceptable. I am *not* OK with that. > - the tool makes it very easy to turn off whichever errors you don't > prefer to enforce. This is about the default behaviour, and claiming as errors things that are explicitly listed in the PEP as OK. > - PEP 8 changes regularly (as Florent noted, the offending code example > was only added recently), and there is value in the automated tool > maintaining some stability for its users. > > Personally, I would much rather see pep8.py err on the side of being too > strict with PEP 8's recommendations than too loose. Again, it's not hard > to turn off the ones you don't want. No, this is exactly the *wrong* way to approach it. A tool laying claim to PEP 8's authority should err on the side of *not* enforcing rules that are not clearly rules - if more clarity is desired, then ask for clarity from python-dev. > If python-dev wants to control the precise behavior of pep8.py, bring it > into the standard library and adopt maintenance of it. Otherwise, please > give Florent some grace. Note that I don't complain about the default behaviour of pylint, pychecker, or any other linter tools. But by continuing to call the tool "pep8", 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). There is a very, very simple guideline that can be followed here: anything which is not clearly and unambiguously disallowed in the PEP itself should never be more than a warning in a tool that is called "pep8". Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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
On 25 April 2014 18:26, Donald Stufft wrote: >> If python-dev wants to control the precise behavior of pep8.py, bring it >> into the standard library and adopt maintenance of it. Otherwise, please >> give Florent some grace. >> >> Carl > > Carl’s post mirrors my own thoughts and it’s said much better than I could > have. > > pep8.py doesn’t violate PEP8, it just takes a stricter view of it. In other words, it adds rules that have not been discussed on python-dev, and effectively claims that those rules are part of PEP 8 when they're not. Note that my problem is *specifically* with errors, and especially with errors that are on by default. Even with the name "pep8", warnings and below are clearly at the discretion of the tool authors and maintainers, and while "off-by-default" errors strike me as nonsensical (why not just make them warnings instead?), I also don't have a problem with adding more of them. However, keeping E121 (which requires all indentation of continued lines in expressions to also be a multiple of 4, rather than only semantically significant indentations) and E701 (which completely disallows the use of single line compound statements, even through the PEP text only discourages them) as errors rather than warnings is apparently more important than my wholehearted endorsement of the tool as a co-author of PEP 8. So be it - but while that is the case, pep8 is *not* a PEP 8 linter, it remains "PEP 8 plus extra rules python-dev has never discussed". Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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
On 04/25/2014 03:26 PM, Donald Stufft wrote: pep8.py doesn’t violate PEP8, it just takes a stricter view of it. If pep8 reports errors on things that PEP 8 says are okay, that's a violation. -- ~Ethan~ ___ 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
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. On Fri, Apr 25, 2014 at 4:20 PM, Ethan Furman wrote: > On 04/25/2014 03:26 PM, Donald Stufft wrote: > >> >> pep8.py doesn’t violate PEP8, it just takes a stricter view of it. >> > > If pep8 reports errors on things that PEP 8 says are okay, that's a > violation. > > -- > ~Ethan~ > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ 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
On Apr 25, 2014, at 7:56 PM, Florent wrote: > 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. I agree that I’ve never taken the name to mean that you’re claiming any sort of endorsement. There are a *vast* number of projects that implement something that was defined somewhere else and I don’t think any reasonable person can assume that all of those tools are endorsed by the authors of what they are implementing. > > 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/donald%40stufft.io - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
On Apr 25, 2014, at 7:20 PM, Ethan Furman wrote: > On 04/25/2014 03:26 PM, Donald Stufft wrote: >> >> pep8.py doesn’t violate PEP8, it just takes a stricter view of it. > > If pep8 reports errors on things that PEP 8 says are okay, that's a violation. > > -- > ~Ethan~ > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/donald%40stufft.io Not really, any code that passes the pep8.py check is perfectly valid in the eyes of PEP8, if a check was implemented to say, require camelCase method names, then that would be a violation of a check. Being stricter is not a violation, it’s being stricter. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
On 25 April 2014 19:56, Florent wrote: > 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. I apologise for my impatience. As I stated in that issue, I really *want* to be able to uncritically endorse pep8 for use on new Python projects, as while I like pylint personally, I think it's too complicated (and noisy by default) to recommend its use outside large multi-developer projects where taking the time to set up a custom config file is likely to pay off. Hence it's frustrating to me that I can't currently recommend pep8 for this use case, as the default behaviour includes rules I disagree with (in particular, the ones that the examples in PEP 8 itself fail). I believe the combination of the implied endorsement from the name of the tool and an explicit endorsement from me saying "use this on your projects" would imply that I agree with *all* the default behaviour, and that simply isn't the case (E121 in particular is outright wrong, since it violates the approach of aligning indented lines with an opening parenthesis). It seemed simple enough to me to say "yes, that makes sense, we can make those warnings eventually, but it's not a high priority to do so". That would put it back on me to craft a pull request to make the change, and would be an entirely appropriate response when I'm asking other people to do extra work. That hasn't been my impression of the response I received to date though - my impression of the response has been "we don't care about your feelings". Defending PEP 8 against people who think it's overly prescriptive is irritating enough, without having to also figure out whether people are actually complaining about the PEP or about a tool I didn't help write :( Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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
On 25 April 2014 21:29, Nick Coghlan wrote: > On 25 April 2014 19:56, Florent wrote: >> 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. > > I apologise for my impatience. As I stated in that issue, I really > *want* to be able to uncritically endorse pep8 for use on new Python > projects, as while I like pylint personally, I think it's too > complicated (and noisy by default) to recommend its use outside large > multi-developer projects where taking the time to set up a custom > config file is likely to pay off. Note that I've now resumed this discussion on the pep8 issue tracker (including splitting out a separate RFE specifically relating to the new'ish guideline for handling of single line function definitions). My apologies to Florent specifically, and the list in general, for letting frustrations with unrelated issues boil over into impatience and unconstructive criticism of a fellow open source contributor's efforts. Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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
On 04/25/2014 05:42 PM, Donald Stufft wrote: On Apr 25, 2014, at 7:20 PM, Ethan Furman wrote: On 04/25/2014 03:26 PM, Donald Stufft wrote: pep8.py doesn’t violate PEP8, it just takes a stricter view of it. If pep8 reports errors on things that PEP 8 says are okay, that's a violation. Being stricter is not a violation, it’s being stricter. Then it should be called stricterThanPep8. ;) I think we're going to have to agree to disagree on this point. A tool that implements PEP 8 [1], but tells me that something PEP 8 allows is an error -- well, that's not PEP 8 then, is it? At any rate, this part of the thread is pretty off-topic, so this is my last post about it. -- ~Ethan~ [1] Yes, I checked the site for pep8, and saw the escape clause of "some of the style conventions" -- the problem is the cognitive dissonance between the name of the tool and the actions of the tool. ___ 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
[Python-Dev] Help with changes in stack from 2.7 to 3.x
I wrote the following code that works in Python 2.7 that takes the variables
passed to the function into a dictionary. The following call:
strA = 'a'
intA = 1
dctA = makeDict(strA, intA)
produces the following dictionary:
{'strA':'a', 'intA':1}
To access the names passed into the function, I had to find the information by
parsing through the stack. The code that used to work is:
from traceback import extract_stack
def makeDict(*args):
strAllStack = str(extract_stack())
intNumLevels = len(extract_stack())
intLevel = 0
blnFinished = False
while not blnFinished:
strStack = str(extract_stack()[intLevel])
if strStack.find("makeDict(")>0:
blnFinished = True
intLevel += 1
if intLevel >= intNumLevels:
blnFinished = True
strStartText = "= makeDict("
intLen = len(strStartText)
intOpenParenLoc = strStack.find(strStartText)
intCloseParenLoc = strStack.find(")", intOpenParenLoc)
strArgs = strStack[ intOpenParenLoc+intLen : intCloseParenLoc ].strip()
lstVarNames = strArgs.split(",")
lstVarNames = [ s.strip() for s in lstVarNames ]
if len(lstVarNames) == len(args):
tplArgs = map(None, lstVarNames, args)
newDict = dict(tplArgs)
return newDict
else:
return "Error, argument name-value mismatch in function 'makeDict'. lstVarNames: "
+ str(lstVarNames) + "\n args: " + str(args), strAllStack
The same code does not work in Python 3.3.4. I have tried parsing through the
stack information and frames and I can't find any reference to the names of the
arguments passed to the function. I have tried inspecting the function and
other functions in the standard modules, but I can't seem to find anything that
will provide this information.
Can anyone point me in the direction to find this information? Any help is
appreciated.
---Andrew
___
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
Florent writes: > 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 :-) Of course there is an implicit claim of endorsement: the name. Read the TeX license -- pretty much the only restriction is *you can't call it "TeX" or any variation including that trademark if it doesn't pass TRIP*. When Don Knuth cares that much that names denote conformance to standard, Nick is in really good company. I agree 100% with Nick: in a program named "pep8", the examples in PEP 8 should *all* pass in the sense of not being labelled errors. Of course if the PEP changes that doesn't mean you should withdraw or rename the program, or even that you are required to address the issue within any time span. But you should consider it a bug. That said, issuing *warnings* for discouraged-but-sometimes-allowed practices is a great idea. A stricter warnings-are-errors *mode* is a good idea, especially for automated checkers, but it should be configurable for different policies. > http://pep8.readthedocs.org/en/latest/intro.html#disclaimer Disclaimers are for lawyers. Other people assume names mean what they say. ___ 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
On 4/25/2014 5:52 PM, Carl Meyer wrote: - we aren't talking about real variance from the spirit or recommendations of PEP 8 So the one example under discussion is: foo = long_function_name( var_one, var_two, var_three, var_four) and comes from http://legacy.python.org/dev/peps/pep-0008/#indentation Specifically the third example with a heading of "Optional". From my reading of the text, plus all the other examples around it, I would have assumed the 2 space indent was simply a typo and should have indeed been 4 spaces. If this is really meant to show that indents other than 4 spaces are allowed in this situation maybe verbiage to that effect could be added. Janzert ___ 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] Help with changes in stack from 2.7 to 3.x
On Sat, Apr 26, 2014 at 1:11 PM, Andrew Konstantaras wrote: > Can anyone point me in the direction to find this information? Any help is > appreciated. I'd recommend python-list rather than python-dev (the latter is for the development *of* Python, rather than development *with* Python). But to be quite honest, I don't think you should be doing this at all. It's extremely odd for this function to even work, and most users will not expect that renaming a local variable will materially change anything. Fiddling around with stack backtraces in string form and using those to find the source code line and fetching parameter names? Definitely weird, definitely not recommended, and not at all surprising that it broke between versions. ChrisA ___ 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
On Apr 26, 2014, at 12:31 AM, Stephen J. Turnbull wrote: > Florent writes: > >> 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 :-) > > Of course there is an implicit claim of endorsement: the name. Read > the TeX license -- pretty much the only restriction is *you can't call > it "TeX" or any variation including that trademark if it doesn't pass > TRIP*. When Don Knuth cares that much that names denote conformance > to standard, Nick is in really good company. No there isn’t. For instance there are things on PyPI named after websites, like github, twitter, Facebook, etc. These things are not written by the companies behind those websites and are merely written to interface with those websites. Should we assume that those companies all endorse every single one of those projects simply because they chose a descriptive name for their project? The name indicates what it attempts to do, create a PEP8 linter, it makes no claim of endorsement by the authors of the PEP. You can say it’s confusing if it’s named pep8 but doesn’t actually make it “PEP8”, but claiming it’s endorsement isn’t correct. > > I agree 100% with Nick: in a program named "pep8", the examples in PEP > 8 should *all* pass in the sense of not being labelled errors. Of > course if the PEP changes that doesn't mean you should withdraw or > rename the program, or even that you are required to address the issue > within any time span. But you should consider it a bug. Or required to address it at all if you don’t wish to. Since the issue is still open I assume that means that the author hasn’t decided what the correct remediation is yet. > > That said, issuing *warnings* for discouraged-but-sometimes-allowed > practices is a great idea. A stricter warnings-are-errors *mode* is a > good idea, especially for automated checkers, but it should be > configurable for different policies. > >> http://pep8.readthedocs.org/en/latest/intro.html#disclaimer > > Disclaimers are for lawyers. Other people assume names mean what they > say. > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/donald%40stufft.io - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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] ConfigParser mangles keys with special chars
On Fri, Apr 25, 2014 at 12:46:42PM -0400, Fred Drake wrote: > On Fri, Apr 25, 2014 at 10:22 AM, Florian Bruhin > wrote: > > While it seems ConfigParser doesn't do any escaping as all, I'm > > thinking it should at least raise some exception when such a value is > > trying to be set. > > > > I'd expect writing something and then reading it back via the same > > configparser to *always* result in the same data, as long as writing > > worked without error. > > > > Thoughts? Should I submit a bug report? > > I believe you should, if only to provide a place to record why no > change gets made. > > Had ConfigParser been more careful from the beginning, that would have > been really good. > > At this point, it would be a backward-incompatible change, so it's > unlikely such a change could be allowed to affect existing code. It seems to me that the current behaviour is a bug and should be fixed. I think the relevant part of the docs is the part following the "comment_prefixes" and "inline_comment_prefixes" section: Please note that config parsers don’t support escaping of comment prefixes so using inline_comment_prefixes may prevent users from specifying option values with characters used as comment prefixes. When in doubt, avoid setting inline_comment_prefixes. In any circumstances, the only way of storing comment prefix characters at the beginning of a line in multiline values is to interpolate the prefix, for example: ... This is *seriously* underspecified, which is a bug in itself: option *values* don't support including inline_comment_prefixes, but do option *keys* support them? How about keys beginning with comment_prefixes? The specification doesn't say, but nor does it say that it's undefined behaviour. I think that a line beginning with "#spam" is ambiguous, it isn't clear if it is intended as a comment "spam" or a key starting with #, so by the Zen, configparser should refuse to guess. -- Steven ___ 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
Carl Meyer writes: > I'd like to thank Florent for taking the time to maintain an > extremely-useful tool that makes it feasible to keep to a > consistent PEP 8 style throughout a large codebase with many > contributors, I would too. N.B. Nick's complaints are a sort of left-handed compliment, too. > and I think he should have the leeway as maintainer to make the > necessary judgment calls about precisely which PEP 8 > recommendations are reported precisely how by the tool, given that: Of course. But whether an example in the PEP passes or not is *not* a judgment call at all, IMO. Do you think that it is? > - we aren't talking about real variance from the spirit or > recommendations of PEP 8 (though you wouldn't know it from some of > the rhetoric here about "personal preferences") That parenthetical remark was unnecessary, and at least in my case, I understood very well that there is no "real" variance. I disagree with the implied requirements, however. A program *intended to test standard conformance* MUST (in the sense of RFC 2119) aspire to a higher standard than "in the spirit", don't you think? Anyway, that's what I think. > - the tool makes it very easy to turn off whichever errors you > don't prefer to enforce. This is precisely backward. *I* have no errors I prefer to enforce or not to enforce. I want "PEP 8 conformance", I don't want to think or make judgments about individual recommendations in PEP 8. I want to leave that up to the PEP 8 maintainers. I suspect that is a common use case. > - PEP 8 changes regularly (as Florent noted, the offending code > example was only added recently), and there is value in the > automated tool maintaining some stability for its users. Achieving "some" stability would not be difficult: version the error sets of the tool, and provide a switch to invoke specific versions. Each version could be dated, as well, to allow such stability without knowing the precise content of the version of PEP 8 or pep8.py. I personally would not use such a switch, however. I would either change my code to conform to current PEP 8, or not. ;-) > Personally, I would much rather see pep8.py err on the side of > being too strict with PEP 8's recommendations than too > loose. Again, it's not hard to turn off the ones you don't want. Again, for many users of the tool, that is precisely *not* why they want to use the tool. They want to delegate the decision of which rules to enforce to the PEP 8 authors. Since *you* have preferences, I repeat your words back to you: it's not hard to turn on the ones you want. (Or it needn't be.) > If python-dev wants to control the precise behavior of pep8.py, > bring it into the standard library and adopt maintenance of it. > Otherwise, please give Florent some grace. Note that what Nick is complaining about is not that pep8.py varies from PEP 8 -- that's inevitable -- but rather that the variation is not *acknowledged* as a bug. So python-dev (but you really mean Nick) doesn't want to control the precise behavior of pep8.py, as code. What Nick wants is for code *bearing the name* to conform to the PEP it was named for. For users who want PEP 8 conformance merely because it is the standard, that's exactly right. For those of you who want to pick and choose which rules to follow and how strictly, the name doesn't much matter, does it? I think that in naming we should consider the use cases of those who depend on the name to be meaningful as higher priority than those who don't, but make their own judgments anyway. Regards, ___ 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] ConfigParser mangles keys with special chars
On Sat, Apr 26, 2014 at 1:34 AM, Steven D'Aprano wrote: > I think that a line beginning with "#spam" is ambiguous, it isn't clear > if it is intended as a comment "spam" or a key starting with #, so by > the Zen, configparser should refuse to guess. Seriously? Perhaps the second paragraph here could be strengthened a little: https://docs.python.org/3/library/configparser.html#supported-ini-file-structure But that seems clear to me. Lines starting with the comment prefix are comments. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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
On Fri, Apr 25, 2014 at 08:13:35PM -0400, Donald Stufft wrote: > I agree that I’ve never taken the name to mean that you’re claiming any > sort of endorsement. There are a *vast* number of projects that implement > something that was defined somewhere else and I don’t think any reasonable > person can assume that all of those tools are endorsed by the authors > of what they are implementing. I think that is wrong. "Endorsed" is the wrong word -- what's important is that if package PEP8 "checks for PEP 8 compliance", then if package PEP8 checks for foo, then people assume that foo-checking is specified by PEP 8 -- whether it does or not. If something claims to be "JSON", say, then most people would expect that by default it would implement the JSON standard rather than some tweaked version of almost JSON. If their JSON library fails to match the standard, a significant number of people will assume that the library's non-standard version *is* the standard. It may even become the de-facto standard, regardless of what the standard actually says, and so introduce ambiguity where there was none. E.g. consider browser's treatment of ISO-8859-1 as Windows-1252. People and corporations often take this sort of stuff really seriously, and I'm not surprised that Nick feels as strongly as he does. I would too. Try releasing a package using the name "iPhone" without Apple's approval: https://developer.apple.com/softwarelicensing/index.php In this case, I too would have assumed that a package calling itself "PEP8" checks for compliance with PEP 8, and that any differences between PEP 8 and the package is a bug in the package. Providing the ability to turn on or off checks, or make them more or less strict, is okay, but I would expect that by default it should check for PEP 8 compliance, exactly PEP 8 compliance, and nothing but PEP 8 compliance. -- Steven ___ 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
