Mailman 3 September 2021 - Python-ideas

Re: A better math.factorial
by Steven D'Aprano 19 Sep '21

19 Sep '21

On Sat, Sep 18, 2021 at 03:50:00PM -0700, Christopher Barker wrote: > Folks are not surprised by: > > >> 2 * 3 == [2] * 3 > > False > > Because 2 is not only a different type than [2] but because they are > different values as well. What counts as a value? In some programming languages, 2.0 != 2 and I can't say that they are wrong to make that decision. Given: a, = [2] b, = (2,) then clearly a==b. In that sense, we can say that the two sequences have the same value. But: [2] != (2,) [2]*5 != (2,)*5 so in Python, the concept of "same value" does depend on type. Numeric types are an exception, because they are automatically coerced to a common type. And that's a mixed benefit. It means that we have to deal with surprises like this: >>> 1234567890123456789 == 1234567890123456789.0 False Even more surprising: >>> x = 1234567890123456789 >>> x == x + 0 True >>> x == x + 0.0 False I still think that there is little or no justification for having factorial automatically delegate to gamma *in Python*, but there are languages where it would work. In the right circumstances, it works fine. It's not a dumb idea. For instance, in Javascript, there is no int type, everything is a float. So in Javascript, there is no question that factorial(65) will unquestionably equal factorial(65.0), and that it would be perfectly safe to have factorial take fractional values and compute the gamma function. Similarly for the various calculator languages used in advanced programmable calculators, where it is the case that fractional arguments to factorial return the gamma function. (Possibly in symbolic form.) -- Steve

3 2

A better math.factorial
by Jonatan 18 Sep '21

18 Sep '21

Currently, math.factorial only supports integers and not floats, whereas the "mathematical" version supports both integers and floats. I.e: ``` import math def better_factorial(n): return n * math.gamma(n) print(math.factorial(10) == better_factorial(10)) ``` This ends up in `True`, as that's correct. However, `math.factorial(math.pi)` (for example, or any float) Ends up in `ValueError: factorial() only accepts integral values`. unlike `better_factorial(math.pi)` which would end up in 7.188082728976031. My proposal is to make another function for floats, or even use the same math.factorial function and check inside it whether the given input is an integer or a float object. I would like to hear your review. Jonathan.

8 9

New feature to revert 'barry_as_FLUFL' future import
by Jeremiah Vivian 18 Sep '21

18 Sep '21

NEW_FEATURE = "remove_barry_from_BDFL" or "barry_resign_as_FLUFL"/"barry_resign_as_BDFL"; Add a new future import NEW_FEATURE. This reverts the effects of the future import "barry_as_FLUFL" easter egg IF it is ever imported. This is absolutely unnecessary when "barry_as_FLUFL" isn't imported. There can be optional messages attached to a Barry-related future import: - When future import NEW_FEATURE is imported and future import "barry_as_FLUFL" is already imported: -- "Barry was overthrown from BDFL-ship!" ( friendlier message: "Barry has resigned from FLUFL-ship."/"Barry has resigned from BDFL-ship." ) - When future import "barry_as_FLUFL" is imported and NEW_FEATURE is already imported: -- "Barry has returned as FLUFL." ( or "Barry has returned as BDFL." ) This idea also suggests allowing future imports anywhere in the file as long as it's Barry-related ( optional feature: only allow a Barry-related future import IF it is the opposite of the previous Barry-related future import. The opposite of "no Barry-related future imports yet" is the future import "barry_as_FLUFL" ) Test cases: >>> from __future__ import barry_resigned_as_FLUFL # no effect >>> from __future__ import barry_as_FLUFL >>> 1 <> 2 True >>> 1 != 2 File "<stdin>", line 1 1 != 2 ^^ SyntaxError: with Barry as BDFL, use '<>' instead of '!=' >>> from __future__ import barry_resigned_as_FLUFL Barry has resigned from BDFL-ship. >>> 1 <> 2 File "<stdin>", line 1 1 <> 2 ^^ SyntaxError: invalid syntax >>> 1 != 2 True >>> from __future__ import barry_as_FLUFL Barry has returned as FLUFL. >>> 1 != 2 File "<stdin>", line 1 1 != 2 ^^ SyntaxError: with Barry as BDFL, use '<>' instead of '!=' >>> 1 <> 2 True >>> from __future__ import barry_resigned_as_FLUFL Barry has resigned from BDFL-ship. >>> 1 != 2 True >>> 1 <> 2 File "<stdin>", line 1 1 <> 2 ^^ SyntaxError: invalid syntax

4 4

Python Documentation in Bengali (translation)
by sharifmehedi24＠outlook.com 16 Sep '21

16 Sep '21

Hi there all, I am preparing a team to start translating python documentation to Bengali. I'd appreciate some reference materials, comments and ideas about this. Thank you

4 4

argparse: reduce complexity around 'subcommand action objects'?
by rleonar7＠uoregon.edu 15 Sep '21

15 Sep '21

I would love to make the 'subcommands' functionality provided in argparse more user-friendly. I think I have a worthwhile feature request to share: * Be able to add multiple subcommands to an ArgumentParser, without needing to track the 'action_object' I've outlined an motivating example below, and shared an implementation of this feature that I've started using in one of my projects. Thanks! -Ryan # Motivating Example I am working with ArgumentParser subcommands a lot recently, and I've run into the interesting implementation detail when it comes to 'adding multiple subcommands to a parser': `argparse.ArgumentParser` provides a [special 'action object' to manage subcommands](https://docs.python.org/3/library/argparse.html#sub-commands). Lets look at an example of how this works: First, setup our `root_parser`: root_parser = ArgumentParser() Then, later on, lets add a 'post' subcommand: action_object = root_parser.add_subparsers() post_parser = action_object.add_subparser("post") Finally, lets add a 'get' subcommand to the `root_parser`: action_object = root_parser.add_subparsers() <--- Error here! get_parser = action_object.add_subparser("get") This second code block will not work, and will raise an error! : error: cannot have multiple subparser arguments So, it seems these ephemeral 'action objects' are a thorn in my side. Specifically, these objects are impeding the following functionality: * Add multiple subcommands to an ArgumentParser **from multiple scopes** So, I would like some way for to track the 'action object' alongside `root_parser` to enable 'adding subcommands from multiple scopes.' This can be done by extending `ArgumentParser` to track that 'action object, then provide some `add_subcommand(str)` method. Let's rewrite the example code blocks above assuming we have this new method -- we'll use the class name `SubcommandArgumentParser`. root_parser = SubcommandArgumentParser() The Post parser... post_parser = root_parser.add_subcommand("post") The Get parser... get_parser = root_parser.add_subcommand("get") I wonder, am I totally missing some obvious complexity of subparsers/subcommands with this suggested feature? that this could make working with subcommadns # Example Implementation Here is an implementation of that functionality that I put together for my project. class SubcommandArgumentParser(configargparse.ArgumentParser): count = 0 def __init__(self, *args, **kwargs): self.subparser_factory = None super().__init__(args, kwargs) def _create_subparser_factory(self): unique_str = f'action{SubcommandArgumentParser.count}' SubcommandArgumentParser.count += 1 # Create the subparser factory! self.subparser_factory = self.add_subparsers(dest=unique_str) self.subparser_factory.required = True def add_subparser(self, subcommand: str) -> 'SubcommandArgumentParser': """Some programs split functionality up into subcommands. Each subcommand has a dedicated `configargparse.ArgumentParser`. Arguments: subcommand (str): The subcommand to be added to this parser. Returns: SubcommandArgumentParser: The ArgumentParser that can be Example: Given a Subcommand parser.add_subparser() """ if self.subparser_factory is None: self._create_subparser_factory() return self.subparser_factory.add_parser(subcommand)

2 1

Addition of a "plus-minus" binary numeric operator
by yahbai＠gmail.com 14 Sep '21

14 Sep '21

Hi all, I was wondering on whether there is any interest in introducing a "plus-minus" operator: Conceptually very simple; instead of: upper, lower = a + b, a - b use instead: upper, lower = a +- b In recent projects I've been working on, I've been having to do the above "plus minus" a lot, and so it would simplify/clean-up/reduce error potential cases where I'm writing the results explicitly. It isn't a big thing, but seems like a clean solution, that also takes advantage of python's inherent ability to return and assign tuples.

6 5

classmethod __eq__ comparisons and Any wildcards
by Randolf Scholz 14 Sep '21

14 Sep '21

Hey, I noticed that writing a class with a classmethod `__eq__`, it does not work as expected: ```python class ANY: @classmethod def __eq__(cls, other): return True assert ANY == 2 # succeeds assert ANY == 2 # fails ``` This is, to my understanding, because `ANY == 2` translates into `type(ANY).__eq__(2)`. However, I think it would be useful to allow user implementation of `classmethod` dunder methods that work as expected, or at least put a big disclaimer in the documentation. I am not sure how difficult this would be to do, but I imagine that `type` could check if the given object/class has a classmethod __eq__ and if so use it as a replacement for `type(obj).__eq__` As a sidenote, I think it would actually be kinda cool to have the `typing.Any` behave this way, i.e. always comparing to True. One example where this would be useful is that it would allow comparisons like ```python assert mytuple == (Any, "abc") ``` which would then be equivalent, but imo a lot more elegant than ```python assert len(mytuple) == 2 and mytuple[-1] == "abc" ``` Best regards - Randolf

4 6

Add @parametrize decorator to unittest library
by Leonardo Freua 12 Sep '21

12 Sep '21

When writing some unit tests with the standard Unittest library, I missed being able to create parameterized tests. This functionality exists in PyTest (https://docs.pytest.org/en/6.2.x/parametrize.html) and there is also a library called *parameterized*(https://github.com/wolever/parameterized) which aims to add this functionality. However, I think it would be beneficial to have a decorator in Python's standard Unittest library. Note: If this functionality exists natively in Python, please put some example or documentation link below. Thanks in advance.

16 37

Should for loops run in their own scope?
by Steven D'Aprano 12 Sep '21

12 Sep '21

Over on Discuss, there's a small discussion about the "lambdas in for loop" problem described in the FAQs. https://discuss.python.org/t/make-lambdas-proper-closures/10553 https://docs.python.org/3/faq/programming.html#why-do-lambdas-defined-in-a-… I've created a poll on Discuss. If you have an account, you may like to vote on whether for loops should run in their own scope: https://discuss.python.org/t/should-loops-be-in-their-own-scope-poll/10593 * No change, leave loops as they are. * Change loops to use their own scope. * No change for loops by default, but add an option to run them in a new scope. Just throwing out some random syntax to be shot down, how does this read to folks? for item in sequence in scope: # block here has its own scope ... I have no idea what the implementation difficulties might be, but with lots of hand-waving and in full knowledge that it won't be *me* having to do the implementation, I imagine it could be easy enough if the for loop is compliled into a nested function that is then immediately executed. Sort of like a comprehension? Personally, I'm happy with Python not using block scopes (only functions and classes create a new scope, other blocks do not). But for loop scope does seem to be frequently requested, so while I don't see the benefit myself, maybe others do. -- Steve

3 2

Add a special TypeError subclass for implementation errors
by Serhiy Storchaka 12 Sep '21

12 Sep '21

There are two different kinds of TypeError: if the end user passes an instance of wrong type and if the author of the library makes an error in implementation of some protocols. For example, len(obj) raises TypeError in two cases: if obj does not have __len__ (user error) and if obj.returns non-integer (implementation error). for x in obj raises TypeError if obj does not have __iter__ (user error) and if iter(obj) does not have __next__ (implementation error). User errors can be fixed on user side, implementation errors can only be fixed by the author of the class. Even if the user and the author is the same person, these errors point to different places of code. Would it be worth to add a special TypeError subclass for implementation errors to distinguish them from user errors? How to name it (ImplementationError, ProtocolError, etc)?

9 17