[issue20291] Argument Clinic should understand *args and **kwargs parameters

Change by colorfulappl : -- pull_requests: +30177 pull_request: https://github.com/python/cpython/pull/32092 ___ Python tracker ___

[issue46676] ParamSpec args and kwargs are not equal to themselves.

Change by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue46676] ParamSpec args and kwargs are not equal to themselves.

Serhiy Storchaka added the comment: New changeset cbdcae5ab90710e8d82c213f3798af1154670ff9 by Gregory Beauregard in branch '3.10': [3.10] bpo-46676: Make ParamSpec args and kwargs equal to themselves (GH-31203) (GH-31210) https://github.com/python/cpython/commit

[issue46676] ParamSpec args and kwargs are not equal to themselves.

Change by Gregory Beauregard : -- pull_requests: +29380 pull_request: https://github.com/python/cpython/pull/31210 ___ Python tracker ___

[issue46676] ParamSpec args and kwargs are not equal to themselves.

Serhiy Storchaka added the comment: New changeset c8b62bbe46e20d4b6dd556f2fa85960d1269aa45 by Gregory Beauregard in branch 'main': bpo-46676: Make ParamSpec args and kwargs equal to themselves (GH-31203) https://github.com/python/cpython/commit/c8b62bbe46e20d4b6dd556f2fa85960d1269aa45

[issue46676] ParamSpec args and kwargs are not equal to themselves.

Change by Gregory Beauregard : -- keywords: +patch pull_requests: +29373 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31203 ___ Python tracker

[issue46676] ParamSpec args and kwargs are not equal to themselves.

New submission from Gregory Beauregard : from typing import ParamSpec P = ParamSpec("P") print(P.args == P.args) # False print(P.kwargs == P.kwargs) # False ParamSpec args and kwargs are not equal to themselves; this can cause problems for unit tests and type introspect

[issue20291] Argument Clinic should understand *args and **kwargs parameters

Change by colorfulappl : -- nosy: +colorfulappl nosy_count: 11.0 -> 12.0 pull_requests: +28526 pull_request: https://github.com/python/cpython/pull/30286 ___ Python tracker

[issue20291] Argument Clinic should understand *args and **kwargs parameters

Batuhan Taskaya added the comment: New changeset f88e138a1aa3b9a9e013963e4fd7d5cce6a0b85c by Ken Jin in branch 'main': bpo-20291: Fix MSVC warnings in getargs.c (GH-27211) https://github.com/python/cpython/commit/f88e138a1aa3b9a9e013963e4fd7d5cce6a0b85c --

[issue20291] Argument Clinic should understand *args and **kwargs parameters

Change by Ken Jin : -- nosy: +kj nosy_count: 10.0 -> 11.0 pull_requests: +25749 pull_request: https://github.com/python/cpython/pull/27211 ___ Python tracker ___

[issue40820] Mock Call attributes args and kwargs have no changeversion

Karthikeyan Singaravelan added the comment: Thanks for the report. Closing this in favor of https://bugs.python.org/issue41325 -- resolution: -> fixed stage: patch review -> resolved status: open -> closed superseder: -> Document addition of `mock.call_args.args` and

[issue40820] Mock Call attributes args and kwargs have no changeversion

Change by Karthikeyan Singaravelan : -- nosy: +xtreak status: pending -> open ___ Python tracker ___ ___ Python-bugs-list mailing

[issue40820] Mock Call attributes args and kwargs have no changeversion

Change by Andrius Gobis : -- status: open -> pending ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40820] Mock Call attributes args and kwargs have no changeversion

Change by Roundup Robot : -- keywords: +patch nosy: +python-dev nosy_count: 2.0 -> 3.0 pull_requests: +19763 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20519 ___ Python tracker

[issue40820] Mock Call attributes args and kwargs have no changeversion

New submission from Andrius Gobis : In Python 3.8, the ``args`` and ``kwargs`` properties were added to Mock ``Call`` objects (PR: https://github.com/python/cpython/pull/11807 Issue: https://bugs.python.org/issue21269). However, the change did not add a change version to the documentation

[issue36290] _ast.ast_type_init does not handle args and kwargs correctly.

miss-islington added the comment: New changeset 1a4e9e6f35dad26b37639198f1444591d04399e0 by Miss Islington (bot) in branch '3.9': bpo-36290: Fix keytword collision handling in AST node constructors (GH-12382) https://github.com/python/cpython/commit/1a4e9e6f35dad26b37639198f1444591d04399e0

[issue36290] _ast.ast_type_init does not handle args and kwargs correctly.

miss-islington added the comment: New changeset 907ee1f14aaf587683ced44818c5a1d1cabf4174 by Miss Islington (bot) in branch '3.8': bpo-36290: Fix keytword collision handling in AST node constructors (GH-12382) https://github.com/python/cpython/commit/907ee1f14aaf587683ced44818c5a1d1cabf4174

[issue36290] _ast.ast_type_init does not handle args and kwargs correctly.

Change by Pablo Galindo Salgado : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue36290] _ast.ast_type_init does not handle args and kwargs correctly.

Change by miss-islington : -- pull_requests: +19630 pull_request: https://github.com/python/cpython/pull/20366 ___ Python tracker ___

[issue36290] _ast.ast_type_init does not handle args and kwargs correctly.

Pablo Galindo Salgado added the comment: New changeset c73914a562580ae72048876cb42ed8e76e2c83f9 by Rémi Lapeyre in branch 'master': bpo-36290: Fix keytword collision handling in AST node constructors (GH-12382) https://github.com/python/cpython/commit/c73914a562580ae72048876cb42ed8e76e2c83f9

[issue36290] _ast.ast_type_init does not handle args and kwargs correctly.

Change by miss-islington : -- nosy: +miss-islington nosy_count: 6.0 -> 7.0 pull_requests: +19629 pull_request: https://github.com/python/cpython/pull/20365 ___ Python tracker

[issue20291] Argument Clinic should understand *args and **kwargs parameters

Change by Batuhan Taskaya : -- keywords: +patch nosy: +BTaskaya nosy_count: 9.0 -> 10.0 pull_requests: +18009 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/18609 ___ Python tracker

[issue21269] Provide args and kwargs attributes on mock call objects

Karthikeyan Singaravelan added the comment: Thanks @kakshay for the patch. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue21269] Provide args and kwargs attributes on mock call objects

Chris Withers added the comment: New changeset b0df45e55dc8304bac0e3cad0225472b84190964 by Chris Withers (Kumar Akshay) in branch 'master': bpo-21269: Provide args and kwargs attributes on mock call objects GH11807 https://github.com/python/cpython/commit

[issue36290] _ast.ast_type_init does not handle args and kwargs correctly.

Change by Rémi Lapeyre : -- keywords: +patch pull_requests: +12340 stage: -> patch review ___ Python tracker ___ ___

[issue21269] Provide args and kwargs attributes on mock call objects

Kumar Akshay added the comment: ping.. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36290] _ast.ast_type_init does not handle args and kwargs correctly.

Change by Brett Cannon : -- nosy: +benjamin.peterson, brett.cannon, serhiy.storchaka, yselivanov ___ Python tracker ___ ___

[issue36290] _ast.ast_type_init does not handle args and kwargs correctly.

t.Constant(1, value=2).value 2 The last lines should have raised TypeError. I could reproduce the issue with Python 2.7, 3.7 and 3.8 but I'm not sure it's worth fixing for 2.7. I will write a patch to fix the issue. -- components: Library (Lib) messages: 337926 nosy: remi.lapeyre priority

[issue21269] Provide args and kwargs attributes on mock call objects

Karthikeyan Singaravelan added the comment: This feels safer to me with respect to backwards compatibility and also that it might be easier to backport this to mock on GitHub which works with Python 2.7. I have less knowledge on difference between tuple and namedtuple internals so I might

[issue21269] Provide args and kwargs attributes on mock call objects

Rémi Lapeyre added the comment: @xtreak, couldn't we have made `_Call` inherit from namedtuple to achieve a similar result (albeit the handling of name would be weird)? -- ___ Python tracker

[issue21269] Provide args and kwargs attributes on mock call objects

Rémi Lapeyre added the comment: I like this patch, working with calls often feels weird and this change simplify attribute access. -- nosy: +remi.lapeyre ___ Python tracker

[issue21269] Provide args and kwargs attributes on mock call objects

Kumar Akshay added the comment: Thanks @xtreak! I've added a PR with the following API ➜ cpython git:(fix-issue-21269) ✗ ./python.exe Python 3.8.0a0 (heads/fix-issue-21269-dirty:2433a2ab70, Feb 10 2019, 14:24:54) [Clang 10.0.0 (clang-1000.10.44.4)] on darwin Type "help", "copyright",

[issue21269] Provide args and kwargs attributes on mock call objects

Change by Kumar Akshay : -- keywords: +patch, patch, patch pull_requests: +11819, 11820, 11821 stage: needs patch -> patch review ___ Python tracker ___

[issue21269] Provide args and kwargs attributes on mock call objects

Change by Kumar Akshay : -- keywords: +patch pull_requests: +11819 stage: needs patch -> patch review ___ Python tracker ___ ___

[issue21269] Provide args and kwargs attributes on mock call objects

Change by Kumar Akshay : -- keywords: +patch, patch pull_requests: +11819, 11820 stage: needs patch -> patch review ___ Python tracker ___

[issue21269] Provide args and kwargs attributes on mock call objects

Karthikeyan Singaravelan added the comment: @kakshay, I am not working on it so feel free to pick it up. I stumbled upon this while looking into mock issues and I just posted a patch to gather API feedback. I guess it would be helpful if someone confirms it would be a good addition so that

[issue21269] Provide args and kwargs attributes on mock call objects

Kumar Akshay added the comment: Hey @xtreak, if you're not working on this, can I submit the patch? -- nosy: +kakshay ___ Python tracker ___

[issue21269] Provide args and kwargs attributes on mock call objects

Karthikeyan Singaravelan added the comment: args and kwargs property can be introduced on the call object to return the args and kwargs stored in the tuple. Currently wrapping call object with tuple can get a tuple of args and kwargs but a property would be helpful. A first attempt patch

[issue34356] Add support for args and kwargs in logging.conf

Vinay Sajip added the comment: There aren't any changes planned to the fileConfig code, other than bug fixes. If you need improved functionality, you can use dictConfig, which already supports improved configuration features when compared to fileConfig. The fileConfig API was present when

[issue34356] Add support for args and kwargs in logging.conf

Karthikeyan Singaravelan added the comment: Adding Vinay for his thoughts on this. Also Python 3.4 and 3.5 are in security fixes only mode and can be removed. Thanks -- nosy: +vinay.sajip, xtreak ___ Python tracker

[issue34356] Add support for args and kwargs in logging.conf

Change by Xavier Hardy : -- keywords: +patch pull_requests: +8234 stage: -> patch review ___ Python tracker ___ ___

[issue34356] Add support for args and kwargs in logging.conf

for args and kwargs in logging.conf type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue34

[issue20291] Argument Clinic should understand *args and **kwargs parameters

Change by Gordon P. Hemsley : -- nosy: +gphemsley ___ Python tracker ___ ___

[issue20291] Argument Clinic should understand *args and **kwargs parameters

STINNER Victor added the comment: Once this feature will be implemented, print() should be modified to use Argument Clinic: see the issue #29296. -- ___ Python tracker

[issue20291] Argument Clinic should understand *args and **kwargs parameters

Serhiy Storchaka added the comment: Thank you for your examples Raymond, but they don't directly related to this issue, implementing support of var-positional and var-keyword parameters. I believe that it is possible to solve it, and the solution is complex, but is not extremal hard. I'm

[issue20291] Argument Clinic should understand *args and **kwargs parameters

STINNER Victor added the comment: FYI I started to work on a different Argument Clinic enhancement, issue #29299: "Argument Clinic: Fix signature of optional positional-only arguments". -- nosy: +haypo ___ Python tracker

[issue20291] Argument Clinic should understand *args and **kwargs parameters

Raymond Hettinger added the comment: In case it is helpful, here's my list of examples where the AC and existing signature objects are insufficiently expressive: type(obj) type(name, bases, mapping) two different signatures depending on type range(stop) range(start, stop) range(start,

[issue20291] Argument Clinic should understand *args and **kwargs parameters

Serhiy Storchaka added the comment: I'll try to implement the support of var-positional parameters. -- assignee: larry -> serhiy.storchaka versions: +Python 3.7 -Python 3.4, Python 3.5 ___ Python tracker

[issue20291] Argument Clinic should understand *args and **kwargs parameters

Changes by INADA Naoki : -- nosy: +inada.naoki ___ Python tracker ___ ___

Re: *args and **kwargs

On 2016-09-02 15:44, Ben Finney wrote: > Note that this has nothing to do with how the function is defined; in > the definition of the function, parameters are neither positional nor > keyword. You name each of them, and you define an order for them; and > neither of those makes any of them

Re: *args and **kwargs

Ben Finney wrote: in the definition of the function, parameters are neither positional nor keyword. In Python 3 that's not quite true -- it's possible to define "keyword only" parameters that can't be passed positionally. However, it's true that any of the "ordinary" parameters (ones that

Re: *args and **kwargs

fter specifying a keyword argument, you may not then specify any positional arguments. Hence the SyntaxError. & the solution is to change the order of the definition def start( must_have,*args,**kwargs,data=none): thanks a lot -- https://mail.python.org/mailman/listinfo/python-list

Re: *args and **kwargs

After specifying a keyword argument, you may not then specify any positional arguments. Hence the SyntaxError. thanks a lot -- https://mail.python.org/mailman/listinfo/python-list

Re: *args and **kwargs

t; * A keyword argument, ‘data="Fish"’. > * A positional argument, ‘2’. > * A positional argument, ‘3’. > * A keyword argument, ‘tox="tux"’. > > After specifying a keyword argument, you may not then specify any > positional arguments. Hence the SyntaxError. & the solution is to change the order of the definition def start( must_have,*args,**kwargs,data=none): -- Pretend to spank me -- I'm a pseudo-masochist! -- https://mail.python.org/mailman/listinfo/python-list

Re: *args and **kwargs

Smith writes: > I'm trying to understand the concept of * args and ** kwarg with > python3 Welcome. Your questions are fine in this forum; but you may also want to participate in our collaborative learning forum for Python beginners,

*args and **kwargs

Hello to all, I'm trying to understand the concept of * args and ** kwarg with python3 But I can not understand why I returns the error message "SyntaxError: positional argument follows the keyword argument" when I insert values. You can help me? def start(data=None, *args

[issue20291] Argument Clinic should understand *args and **kwargs parameters

Serhiy Storchaka added the comment: I think at first step we can support var-positional parameter only when there are no other positional parameters, and var-keyword parameter only when there are no other keyword parameters. So print, max and dict.update will be supported, but

[issue25770] expose name, args, and kwargs from methodcaller

Guido van Rossum added the comment: To me, the best rhythm has always been (*args, **kwds). -- ___ Python tracker ___

[issue25770] expose name, args, and kwargs from methodcaller

Joe Jevnik added the comment: people have had some time to think about this, whats should the name be so we can merge this? -- ___ Python tracker ___

[issue25770] expose name, args, and kwargs from methodcaller

Serhiy Storchaka added the comment: functools.partial is not the only precedence. The "kwargs" attribute is used in following classes: concurrent.futures.process._CallItem concurrent.futures.process._WorkItem concurrent.futures.thread._WorkItem inspect.BoundArguments sched.Event

[issue25770] expose name, args, and kwargs from methodcaller

Raymond Hettinger added the comment: Now that partial() has started down the path of using "keywords", it seems reasonable to stick with that name. In pure python code, we mostly use **kwds or **kwargs but there are other variants and not much consistency, so spelling out keywords isn't

[issue25770] expose name, args, and kwargs from methodcaller

Serhiy Storchaka added the comment: I don't like the name "keywords". May be I'm not right. Needed opinions of other core developers. -- ___ Python tracker

[issue25770] expose name, args, and kwargs from methodcaller

Joe Jevnik added the comment: ping: any decision on this? -- ___ Python tracker ___ ___ Python-bugs-list

[issue25770] expose name, args, and kwargs from methodcaller

Joe Jevnik added the comment: Is there a decision on the name? I can update the patch if needed. -- ___ Python tracker ___

[issue25770] expose name, args, and kwargs from methodcaller

Joe Jevnik added the comment: partial's unique usage is why I feel like it would be so jarring for them do be named differently. I would be happiest having this feature at all so I will change the name to 'kwargs' if you would like. I just want to be sure that my reasons for choosing this

[issue25770] expose name, args, and kwargs from methodcaller

Serhiy Storchaka added the comment: functools.partial() is unique in it's usage of name "keywords". -- nosy: +ncoghlan, rhettinger ___ Python tracker ___

[issue25770] expose name, args, and kwargs from methodcaller

Martin Panter added the comment: Left a review comment which may help you chase that refleak Also, as a new feature, surely it should be documented? -- nosy: +martin.panter ___ Python tracker

[issue25770] expose name, args, and kwargs from methodcaller

Joe Jevnik added the comment: Thanks for pointing me at the refleak, uploading an update -- Added file: http://bugs.python.org/file41203/methodcaller-attrs-1.patch ___ Python tracker

[issue25770] expose name, args, and kwargs from methodcaller

Joe Jevnik added the comment: Added a test case for the mutation of keywords. -- Added file: http://bugs.python.org/file41204/methodcaller-attrs-2.patch ___ Python tracker

[issue25770] expose name, args, and kwargs from methodcaller

Martin Panter added the comment: This is a bit odd. You can mutate the keyword arguments, but you are not allowed to change the positional arguments (“args” is readonly). If you want this to be part of the supported API, it should be documented, but it seems like bad design IMO. --

[issue25770] expose name, args, and kwargs from methodcaller

Serhiy Storchaka added the comment: "keywords" is unusual name. The most used name for the dict of keyword arguments is "kwargs". $ find Lib/ -name '*.py' -exec egrep -ho '\*\*[a-zA-Z_0-9]+' '{}' + | sort | uniq -c | sort -nr | head 803 **kwargs 442 **kw 244 **kwds ... If you

[issue25770] expose name, args, and kwargs from methodcaller

Joe Jevnik added the comment: I only want this feature to keep the usage close to functools.partial. I was actually sort of surprised to see that mutation of the dict held in partial, but I would rather be consistent. -- ___ Python tracker

[issue25770] expose name, args, and kwargs from methodcaller

Stéphane Wirtel added the comment: Hi, I just tried your patch with the last revision and I have an error with the tests. stephane@sg1 ~/s/h/cpython> ./python -m test test_operator [1/1] test_operator Fatal Python error: ./Modules/_operator.c:975 object at 0x7ff804c2e3d8 has negative ref

[issue25770] expose name, args, and kwargs from methodcaller

Joe Jevnik added the comment: Thanks for review, looking into the reference count issue. -- ___ Python tracker ___

[issue25770] expose name, args, and kwargs from methodcaller

Changes by Emanuel Barry : -- nosy: +ebarry stage: -> patch review ___ Python tracker ___

[issue25770] expose name, args, and kwargs from methodcaller

a different method with the same args. -- components: Library (Lib) files: methodcaller-attrs.patch keywords: patch messages: 255636 nosy: ll priority: normal severity: normal status: open title: expose name, args, and kwargs from methodcaller type: enhancement versions: Python 3.6

[issue25000] _mock_call does not properly grab args and kwargs

Michael Foord added the comment: This is actually the specified and documented behaviour of mock when it is passed mutable arguments. Deep copying arguments on calls is rife with potential problems (not everything can be copied and it breaks comparison by identity). The documentation suggests

[issue25000] _mock_call does not properly grab args and kwargs

Alex Etling added the comment: I attempted to fix this by just deepcopying on creation of the _call object, on line 927 of mock.py but this caused a lot of strange errors I did not expect. If you could advise on how best to proceed to fix, I would greatly appreciate it. --

[issue25000] _mock_call does not properly grab args and kwargs

Actual: %r' % (calls, self.mock_calls) AssertionError: Calls not found. Expected: [call({})] Actual: [call({'val': 5})] Mock thinks that I have passed in {'val': 5}, when I in fact did pass in {}. The errors seems to be the way args and kwargs are being grabbed in _mock_call function -- components

[issue25000] _mock_call does not properly grab args and kwargs

Changes by Ned Deily : -- nosy: +michael.foord, rbcollins -ned.deily, ronaldoussoren versions: -Python 3.2, Python 3.3 ___ Python tracker

[issue20291] Argument Clinic should understand *args and **kwargs parameters

Changes by Serhiy Storchaka storch...@gmail.com: -- components: +Argument Clinic ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20291 ___ ___

[issue20291] Argument Clinic should understand *args and **kwargs parameters

Nick Coghlan added the comment: Yes, I agree we should follow the Python level semantics, and only capture the excess positional arguments. For the record, the four builtins I flagged as needing this in order to add introspection information: __build_class__ - 2 positional only args,

[issue20291] Argument Clinic should understand *args and **kwargs parameters

get the same args (and kwargs) that a Python function would--that is, post-argument-processing. In the above example args should get (4, 5). This might be somewhat painful to do in round 1, where we're still leveraging off PyArg_ParseTuple*. But in the future it'll be cheaper to do it this way

[issue20291] Argument Clinic should understand *args and **kwargs parameters

Changes by Zachary Ware zachary.w...@gmail.com: -- components: +Demos and Tools nosy: +zach.ware type: behavior - enhancement versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20291

[issue21269] Provide args and kwargs attributes on mock call objects

New submission from Michael Foord: The unittest.mock.call object could have args/kwargs attributes to easily access the arguments it was called with. -- messages: 216585 nosy: michael.foord priority: normal severity: normal status: open title: Provide args and kwargs attributes on mock

[issue21269] Provide args and kwargs attributes on mock call objects

Changes by Michael Foord mich...@voidspace.org.uk: -- assignee: - michael.foord components: +Library (Lib) nosy: +kushal.das stage: - needs patch type: - behavior versions: +Python 3.5 ___ Python tracker rep...@bugs.python.org

[issue20291] Argument Clinic should understand *args and **kwargs parameters

priority: normal severity: normal stage: needs patch status: open title: Argument Clinic should understand *args and **kwargs parameters type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20291

Re: Python 2.7.x - problem with obejct.__init__() not accepting *args and **kwargs

On Wed, May 15, 2013 at 8:06 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Wed, 15 May 2013 13:16:09 +0100, Oscar Benjamin wrote: I don't generally use super() Then you should, especially in Python 3. If you're not using super in single-inheritance classes, then you're

Re: Python 2.7.x - problem with obejct.__init__() not accepting *args and **kwargs

On 16 May 2013 03:06, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Wed, 15 May 2013 13:16:09 +0100, Oscar Benjamin wrote: I don't generally use super() Then you should, especially in Python 3. If you're not using super in single-inheritance classes, then you're merely

Python 2.7.x - problem with obejct.__init__() not accepting *args and **kwargs

): def __init__(self,*args,**kwargs): super(a,self).__init__(*args,**kwargs) print args print kwargs print init in a class b(object): def __init__(self,*args,**kwargs): super(b,self).__init__(*args,**kwargs) print args print kwargs print init in b class c(a,b

Re: Python 2.7.x - problem with obejct.__init__() not accepting *args and **kwargs

On 15 May 2013 12:18, wzab wza...@gmail.com wrote: I had to implement in Python 2.7.x a system which heavily relies on multiple inheritance. Working on that, I have came to very simplistic code which isolates the problem: (The essential thing is that each base class receives all arguments

Re: Python 2.7.x - problem with obejct.__init__() not accepting *args and **kwargs

On Wed, May 15, 2013 at 6:16 AM, Oscar Benjamin oscar.j.benja...@gmail.com wrote: I don't generally use super() but I did see some advice about it in this article: https://fuhm.net/super-harmful/ From the conclusion: Never use positional arguments in __init__ or __new__. Always use keyword

Re: Python 2.7.x - problem with obejct.__init__() not accepting *args and **kwargs

On Wed, 15 May 2013 13:16:09 +0100, Oscar Benjamin wrote: I don't generally use super() Then you should, especially in Python 3. If you're not using super in single-inheritance classes, then you're merely making your own code harder to read and write, and unnecessarily difficult for others

[issue17435] threading.Timer.__init__() should use immutable argument defaults for args and kwargs

Roundup Robot added the comment: New changeset 2698920eadcd by R David Murray in branch '3.3': Issue #17435: Don't use mutable default values in Timer. http://hg.python.org/cpython/rev/2698920eadcd New changeset 8c15e57830dd by R David Murray in branch 'default': Merge #17435: Don't use mutable

[issue17435] threading.Timer.__init__() should use immutable argument defaults for args and kwargs

R. David Murray added the comment: Thanks, Denver. I'm choosing not to backport it to 2.7, but that can be done later if someone finds it worth doing. -- resolution: - fixed stage: patch review - committed/rejected status: open - closed versions: -Python 2.7, Python 3.2

[issue17435] threading.Timer.__init__() should use immutable argument defaults for args and kwargs

Terry J. Reedy added the comment: The reported behavior is not a bug by our usual standards. The code is exactly as documented. manual: class threading.Timer(interval, function, args=[], kwargs={}) docstring: t = Timer(30.0, f, args=[], kwargs={}) Threading is not a beginner module. Any

[issue17435] threading.Timer.__init__() should use immutable argument defaults for args and kwargs

Guido van Rossum added the comment: I agree with the OP -- it's a simple fix and the current code definitely violates our recommendations. I see no reason not to submit this (if there's nothing *else* wrong with it -- it actually seems pretty complete). Not sure how important it is to fix

[issue17435] threading.Timer.__init__() should use immutable argument defaults for args and kwargs

Denver Coneybeare added the comment: Thanks r.david.murray. I appreciate you taking the time to look at this issue! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17435 ___

[issue17435] threading.Timer.__init__() should use immutable argument defaults for args and kwargs

threading.Timer is a function in 2.7 (instead of a class), it still ultimately returns a class whose args and kwargs members can be modified. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17435

[issue17435] threading.Timer.__init__() should use immutable argument defaults for args and kwargs

R. David Murray added the comment: I'm sorry, you are correct. I replied too quickly without thinking it through. -- versions: +Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17435

  1   2   3   >