[issue12776] argparse: type conversion function should be called only once
Arnaud Fontaine added the comment: Any news about applying these patches? -- ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Arnaud Fontaine added the comment: Does the patch I attached fix your issue? -- ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Arnaud Fontaine added the comment: It would definitely help if you could apply the patch for Python 2.7 manually on your local installation (after making a backup of course). You can just download the patch for Python 2.7 then (only the first part of the patch can be applied, the second part is for the test so it doesn't matter): # cd /usr/lib/python2.7/ # patch -b -p2 -i /PATH/TO/THE/PATCH Thanks much. -- ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Arnaud Fontaine added the comment: I have had a look at the issue more closely and my initial patch was not completely right as it didn't work properly with argparse_test.py despite all tests passing. Therefore, I have amended my patch to not check whether action.default was a basestring which didn't make sense at all, but check instead if action.default is None (action.default default value is None if not given to add_argument as far as I understand). I also added a test for the issue reported above as it was missing and ran patchcheck to make sure everything was fine. All the tests (include argparse_test.py) passes without problem. Could you please apply them? Many thanks. -- ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Changes by Arnaud Fontaine : Added file: http://bugs.python.org/file23775/py2.7-argparse-call-type-function-once-v3.patch ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Changes by Arnaud Fontaine : Added file: http://bugs.python.org/file23776/py3k-argparse-call-type-function-once-v3.patch ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Arnaud Fontaine added the comment: BTW, about argparse_test, the default should be either '0' or 0 but not '\t' AFAIK because even the default value is converted using the given type function. It fails even with the last 2.7 version but it works well with my patch... -- ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Arnaud Fontaine added the comment:
> Could you add a test to verify that custom actions are still getting
> the converted values passed to their __call__? I suspect this may not
> be happening under the current patch - if that's the case, you may
> also need to add conversions in _get_values, where the lines look like
> "value = action.default".
There seems to be already a test for that, namely TestActionUserDefined,
which use type=float and type=int. The value is properly converted to
{int,float} when passed to __call__(). Just in case, I also tested with
a 'type' function I defined myself (which only returns float()) for
OptionalAction and it's working fine.
> Also, "action.default == getattr(namespace, action.dest)" should
> probably use "is" instead of "==".
Good point, it would be much better. Thanks for the advice. I have just
modified the patch with that.
--
___
Python tracker
<http://bugs.python.org/issue12776>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Changes by Arnaud Fontaine : Added file: http://bugs.python.org/file23972/py2.7-argparse-call-type-function-once-v4.patch ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Changes by Arnaud Fontaine : Added file: http://bugs.python.org/file23973/py3k-argparse-call-type-function-once-v4.patch ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
New submission from Arnaud Fontaine : When specifying a function to be called in type keyword argument of add_argument(), the function is actually called twice (when a default value is set and then when the argument is given). While this may not be a problem in most cases (such as converting to an int for example), it is an issue for example when trying to open a file whose filename is given as a default value but is not accessible for whatever reason because the first call will fail whereas only the second should be done. I know this may sound like a twisted example but the type function should not be called twice anyhow IMHO. I tested with Python 2.7 and 3.2 from Debian packages only but the bug seems to be present in py3k and 2.7 hg branches as well. I have attached a small script showing the issue and two patches (for 2.7 and tip (py3k) hg branches), including an additional test case. All argparse tests pass well with 2.7 and 3.2. Hope that's ok. -- components: Library (Lib) files: example-argparse-type-function-called-twice.py messages: 142306 nosy: arnau priority: normal severity: normal status: open title: argparse: type conversion function should be called only once type: behavior versions: Python 2.7, Python 3.2 Added file: http://bugs.python.org/file22926/example-argparse-type-function-called-twice.py ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Changes by Arnaud Fontaine : -- keywords: +patch Added file: http://bugs.python.org/file22927/py2.7-argparse-call-type-function-once.patch ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Changes by Arnaud Fontaine : Added file: http://bugs.python.org/file22928/py3k-argparse-call-type-function-once.patch ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Arnaud Fontaine added the comment:
Thanks for the review. Sorry to send that here instead of the review page, but
I get an error when replying: "Invalid XSRF token.".
> This looks good, especially if all existing tests still pass as you report,
> but
> I wonder about one thing: you have removed the part where the conversion
> function was applied to the default value, so I expected you to edit the other
> line were the conversion function was already called, but that’s not the
> case.
> Am I misunderstanding something?
Yes, sorry, I should have perhaps explained it in further details... Here are
some examples:
* Example test case 1:
parser = argparse.ArgumentParser()
parser.add_argument('--foo', type=type_foo_func, default='foo')
parser.parse_args('--foo bar'.split())
=> Before the patch, type function is called in parse_known_args() for the
default given in add_argument(), and then in _parse_known_args() for '--foo
bar' given in parse_args above, whereas type function should have been called
only for the second one.
* Example test case 2:
parser = argparse.ArgumentParser()
parser.add_argument('--foo', type=type_foo_func)
parser.parse_args('--foo bar'.split())
=> This was already working well before my patch.
* Example test case 3:
parser = argparse.ArgumentParser()
parser.add_argument('--foo', type=type_foo_func, default='foo')
parser.parse_args('')
=> type_foo_func is called after parsing arguments (none in this case) in my
patch.
Therefore, my patch just moves the function type call after parsing the
arguments (given to parse_args()) instead of before, only and only if it was
not previously given in parse_args().
> http://bugs.python.org/review/12776/diff/3181/9898#newcode1985
> Lib/argparse.py:1985: if hasattr(namespace, action.dest) and \
> It is recommended to use parens to group multi-line statements, backslashes
> are
> error-prone.
I have just updated the patch on the bug report. Thanks.
--
___
Python tracker
<http://bugs.python.org/issue12776>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Changes by Arnaud Fontaine : Removed file: http://bugs.python.org/file22927/py2.7-argparse-call-type-function-once.patch ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Changes by Arnaud Fontaine : Removed file: http://bugs.python.org/file22928/py3k-argparse-call-type-function-once.patch ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Changes by Arnaud Fontaine : Added file: http://bugs.python.org/file22978/py2.7-argparse-call-type-function-once.patch ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Changes by Arnaud Fontaine : Added file: http://bugs.python.org/file22979/py3k-argparse-call-type-function-once.patch ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8269] Missing return values for PyUnicode C/API functions
New submission from Arnaud Fontaine : For example, PyUnicode_FromFormat() does not specify the return value but it does not seem to be only one. I only have a basic knowledge of Python C/API, so I am not sure whether it is meaningful. -- assignee: georg.brandl components: Documentation messages: 101959 nosy: arnau, georg.brandl severity: normal status: open title: Missing return values for PyUnicode C/API functions type: feature request versions: Python 2.6, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue8269> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8269] Missing return values for PyUnicode C/API functions
Arnaud Fontaine added the comment: I meant whether it returns a new reference or not. For instance, documentation for PyUnicode_FromObject() and PyUnicode_AsWideChar() states that a new reference is returned, but this is most specified for most functions in Unicode Object (at least). -- ___ Python tracker <http://bugs.python.org/issue8269> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8269] Missing return values for PyUnicode C/API functions
Arnaud Fontaine added the comment: I meant whether it returns a new reference or not. For instance, documentation for PyUnicode_FromObject() and PyUnicode_AsWideChar() states that a new reference is returned, but this is not specified for most functions in Unicode Object (at least). -- ___ Python tracker <http://bugs.python.org/issue8269> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Arnaud Fontaine added the comment: ping? -- ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Arnaud Fontaine added the comment: Could you please apply this patch? It's been 4 months without reply now... -- ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21308] PEP 466: backport ssl changes
Arnaud Fontaine added the comment: Would it be possible to also backport the changes to httplib.py to support TLS SNI as many libraries (including setuptools) relies on this module to download files and some servers reject clients not supporting TLS SNI (such as cloud.github.com)? I have added a patch for Python 2.7.8. Thanks for working on the backports of SSL changes! -- nosy: +arnau Added file: http://bugs.python.org/file36174/tls_sni_httplib.patch ___ Python tracker <http://bugs.python.org/issue21308> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20613] Wrong line information in bytecode generated by compiler module
New submission from Arnaud Fontaine: I know that compiler module is deprecated since 2.6, but I found a regression introduced in version 2.7 by the following cleanup commit (replacing pyassem.py modified in this commit by the one just before does not trigger this bug): http://hg.python.org/releasing/2.7.6/rev/42faa8054c3d Actually, there is nothing wrong when executing the generated bytecode, it's just that tracebacks and anything that display source code from the generated bytecode object gets sometimes completely wrong when there is if/elif/else because of compiler.pyassem.order_blocks(). This issue was found when noticing that tracebacks in Zope Python Script (using RestrictedPython which in turn uses compiler module) were displaying completely wrong line information and stepping with pdb into the source code was displaying wrong source code and line information too. After investigating, I found out that the problem is actually in compiler module and wrote a small program triggering the bug (I know that some variables are undefined but it does not matter here): if if1: if1_entered = 1 if if2: if subif1: subif1_entered = 1 elif subif2: subif2_entered = 1 subif_ended = 1 Using compiler module to generate the bytecode with the program attached returns two different bytecodes: $ python2.7 compiler_wrong_ordering_block_test.py 1 0 LOAD_NAME0 (if1) 3 POP_JUMP_IF_FALSE 30 2 6 LOAD_CONST 1 (1) 9 STORE_NAME 1 (if1_entered) 12 JUMP_FORWARD15 (to 30) 7 >> 15 LOAD_NAME2 (subif2) 18 POP_JUMP_IF_FALSE 51 8 21 LOAD_CONST 1 (1) 24 STORE_NAME 3 (subif2_entered) 27 JUMP_FORWARD21 (to 51) >> 30 LOAD_NAME4 (if2) 33 POP_JUMP_IF_FALSE 60 36 LOAD_NAME5 (subif1) 39 POP_JUMP_IF_FALSE 15 42 LOAD_CONST 1 (1) 45 STORE_NAME 6 (subif1_entered) 48 JUMP_FORWARD 0 (to 51) 10 >> 51 LOAD_CONST 1 (1) 54 STORE_NAME 7 (subif_ended) 57 JUMP_FORWARD 0 (to 60) >> 60 LOAD_CONST 0 (None) 63 RETURN_VALUE 1 0 LOAD_NAME0 (if1) 3 POP_JUMP_IF_FALSE 15 2 6 LOAD_CONST 1 (1) 9 STORE_NAME 1 (if1_entered) 12 JUMP_FORWARD 0 (to 15) 4 >> 15 LOAD_NAME2 (if2) 18 POP_JUMP_IF_FALSE 60 5 21 LOAD_NAME3 (subif1) 24 POP_JUMP_IF_FALSE 36 6 27 LOAD_CONST 1 (1) 30 STORE_NAME 4 (subif1_entered) 33 JUMP_FORWARD15 (to 51) 7 >> 36 LOAD_NAME5 (subif2) 39 POP_JUMP_IF_FALSE 51 8 42 LOAD_CONST 1 (1) 45 STORE_NAME 6 (subif2_entered) 48 JUMP_FORWARD 0 (to 51) 10 >> 51 LOAD_CONST 1 (1) 54 STORE_NAME 7 (subif_ended) 57 JUMP_FORWARD 0 (to 60) >> 60 LOAD_CONST 0 (None) 63 RETURN_VALUE As you can see from the output above, the first generated bytecode gets all the line numbers (lnotab) messed up because 'subif2' block (and its children too) is emitted *before* its 'dominator' block, namely 'if2'. Now, compiler.pyassem.order_blocks() arranges blocks to be emitted within a 'dominators' dict where the key is a block and the value a list of blocks which must be emitted *before* that one. However, for at least 'if/elif' blocks (created by compiler.pycodegen.CodeGenerator().visitIf()), the 'elif' block (subif2) does not have prev/next (where prev and next define respectively the parent and children blocks) sets to its parent (if2) as it is only set for the first 'if' (subif1) and furthermore for some reasons I don't know the code asserts that next list length must be equal to 1 anyway (anyone knows why BTW?)... Thus, when creating 'dominators' dict using next/prev block attributes, the 'elif' block (subif2) ends up being considered kind of an orphan block because next/prev is not set and thus could be emitted anytime... Enabling debug mode in compiler.pyassem and adding a print call in order_blocks() to display 'dominators' dict co
[issue20613] Wrong line information in bytecode generated by compiler module
Arnaud Fontaine added the comment: compiler module being deprecated does not mean that it's not used. For example, it is used by RestrictedPython as part of Zope2. As I could not figure out a way to fix this bug properly, I reverted the following commit and have not had any problem so far (nor my colleagues): https://hg.python.org/cpython/raw-rev/42faa8054c3d I have attached the reverted patch to this bug report in case of. -- keywords: +patch Added file: http://bugs.python.org/file38418/fix_compiler_module_issue_20613.patch ___ Python tracker <http://bugs.python.org/issue20613> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
