[issue42980] argparse: GNU-style help formatter
Will Noble added the comment: Ya I was following the precedent of non-documentation figuring that formal documentation should be done for the entire class and that would be a much larger undertaking and maybe involve further refactoring. I could potentially undertake that task in the future but I think it's out-of-scope for this change. -- ___ Python tracker <https://bugs.python.org/issue42980> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42980] argparse: GNU-style help formatter
Will Noble added the comment: The main contribution of my PR is simply factoring out _format_option_with_args as an overridable method. Note that this actually enables subclassing HelpFormatter to produce all the examples you presented above with 1-3 trivial lines of code, as opposed to overriding the entire _format_action_invocation which is 20 lines in the base class. If HelpFormatter had a stable internal structure (i.e. some sort of assurance that it's overridable methods were not subject to change), I wouldn't have bothered including an implementation of GnuStyleLongOptionsHelpFormatter in this PR, since I could just implement it downstream as-needed. However, I chose to push it upstream because a) it's trivial and non-invasive and b) it establishes a use-case of _format_option_with_args for posterity, just in case anybody came in later and saw such a trivial, "private" (underscore-prefixed) method and decided to inline it. This lack of perceived stability is alluded to in https://bugs.python.org/issue42966. My preferred solution would be to refactor HelpFormatter to have more overridable methods like this, make them non-"private", document them properly, and keep them relatively stable. In order to do that, we'd want to establish all the desired use-cases and be sure to craft the method structure in such a way that they're all supported. Since that would be a somewhat daunting design task and probably not high on the priority list atm, I think this small incremental improvement pushes things in the right direction; establishing a desirable use-case without committing to too many implementation details yet. -- ___ Python tracker <https://bugs.python.org/issue42980> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42980] argparse: GNU-style help formatter
Change by Will Noble : -- keywords: +patch pull_requests: +23098 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24275 ___ Python tracker <https://bugs.python.org/issue42980> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42980] argparse: GNU-style help formatter
New submission from Will Noble : argparse allows GNU-style long options (with '=' in between the option and the value as opposed to a space): https://docs.python.org/3/library/argparse.html#option-value-syntax Call it pickiness, but I'd like to be able to print the help message in that format. Looking at the code, a simple refactor would be much cleaner than implementing my own custom help formatter and having to copy-paste a bunch of implementation details that are potentially subject to change in future releases. I'll submit a patch shortly. -- components: Library (Lib) messages: 385359 nosy: will priority: normal severity: normal status: open title: argparse: GNU-style help formatter type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42980> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)
Fergus Noble added the comment: GPS time doesn't include leap seconds so I think datetime is a good representation. If datetime doesn't know about leap seconds then there would still be some issues with finding the timedelta between a GPS time and a UTC time straddling a leap second but I guess a similar issue also exists with two UTC times. For my application all the times I am dealing with are in a short period and will have the same UTC offset so its a little easier, I can probably avoid most of these issues. However, wouldn't it be possible to implement the general case with a non-constant utcoffset function (and new fromutc implementation) in the tzinfo class? Of course there is no way to properly handle UTC times more than 6 months or so in the future... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5288 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)
Fergus Noble added the comment: Digging up an old issue but I am also interested in seeing this enhancement. Specifically to represent GPS time which is (currently) 16 seconds ahead of UTC. -- nosy: +Fergus.Noble ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5288 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7899] MemoryError While Executing Python Code
Prashanth noble prashanth.b...@gmail.com added the comment: please find the testcase i am using -- Added file: http://bugs.python.org/file16208/Aura_Test_Scripts_FCT_ACTUSER_EVENT_L.tsv ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7899 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7899] MemoryError While Executing Python Code
New submission from Prashanth noble prashanth.b...@gmail.com: we are executing two queries and storing the result sets and matching the data. the table has got around 8 million records and while executing the same i am getting the Memory Issue. TRACE Arguments: [ DatabaseLibrary.resultset.Resultset instance at 0x01750828 | DatabaseLibrary.resultset.Resultset instance at 0x01750E68 ] FAIL MemoryError DEBUG Traceback (most recent call last): File c:\python26\lib\site-packages\DatabaseLibrary\__init__.py, line 52, in resultsets_should_match resultset1.matches_with(resultset2) File c:\python26\lib\site-packages\DatabaseLibrary\resultset.py, line 37, in matches_with for row_a, row_b in zip(self, other): Please let me know how to resolve this issue -- components: Windows messages: 99164 nosy: p_noblebose severity: normal status: open title: MemoryError While Executing Python Code type: performance versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7899 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
