[Python-ideas] Re: Unpack operator "**" and Mapping
On Sat, Dec 26, 2020 at 11:23:16AM -, Anton Abrosimov wrote: > I am trying to release comfortable dataclass unpacking using `**` > operator. Now I have 5 different ways to do it. But not a single good > one. Confused by the implementation of the unpacking operator. > > So when I try to unpack any custom class, I get the error: > > `type object argument after ** must be a mapping, not MyClass` > > Ok, nothing special. I need to use `collections.abc.Mapping` right? > Now I need to implement: `__getitem__`, `__iter__`, `__len__`. Not a problem. > But additionally I get: `keys`, `items`, `values`. > Hey, I don't need them. I don't need the full mapping functionality. I > only need the double asterisk to work. Why do you want something that isn't a mapping to be usable with mapping unpacking? Does it *really* hurt you to provide mapping methods when you get them for free? Just inherit from Mapping. -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/76XZD4JTDNPHDTJBDJWYXUWWQDUUKRDY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Unpack operator "**" and Mapping
On Sat, Dec 26, 2020 at 09:18:09PM -0800, Brendan Barnwell wrote: > >Yes it is documented: > > > > help(dict.update) > > > >and it was intentionally the inspiration for the behaviour of dict > >augmented assignment. > > I see. It's rather disturbing that that isn't mentioned in the docs > on python.org. "Disturbing"? It's an oversight, not a conspiracy :-) Just submit a PR and I'm sure it will be accepted. > >If you want to argue it's not a protocol, just an interface, okay, it's > >an interface. That's a difference that makes no difference. > > No, it does make a difference. What you're describing is the > interface to a single existing type. It's part of the MutableMapping ABC, although you need to read the source code of that (or the doctsring) to see it: https://github.com/python/cpython/blob/3.9/Lib/_collections_abc.py -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BIUZTVKNPG74ADCLTFQWQVBGWLN77VUQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: str.isfloat()
You should really just write your own function -- Python can't include every validation function you can think of. It already provides an extensible and well tested float conversion which throws an exception on bad input (the 'float' constructor) You want it to not throw an exception, but rather return a status indicating success. This is called Look Before You Leap (LBYL) and is considered un-Pythonic (i.e. is not standard practice while writing Python). If you absolutely must have it in this format (which you shouldn't), you should just write a function that accepts a string, and has a try/except block and then returns the status. Again, don't do this, it's not good practice: def parsefloat(s): try: return float(s) except: return none # or whatever you want to indicate failure I think the confusion of the 'isdigit()' method (and thus your original inquiry into a 'isfloat()' meyhod) stems from a misunderstanding; 'isdigit()' tests whether characters are in a Unicode character set or not -- it doesn't actually convert to a number. Parsing floats is a more complicated and different problem, which doesn't belong in the 'str' class, and already does exist in the 'float' class. Although you say that try/except blocks are ugly/unnecessary/etc, try programming with LBYL idioms as you've suggested. I think you'll find they're not only more verbose, less necessary, and uglier, but they also make exception shadowing much easier (and thus, proper exception handling harder to do). On Sun, Dec 27, 2020, 5:58 PM Joao S. O. Bueno wrote: > > > On Sun, 27 Dec 2020 at 19:31, Chris Angelico wrote: > >> On Mon, Dec 28, 2020 at 9:22 AM Joao S. O. Bueno >> wrote: >> > >> > I agree - the three builtin methods are almost the same (not sure if >> > there is any difference at all), >> >> Yes - they all check if the string matches a particular set of characters. >> >> > while there is no trivial way to check for a valid >> > float, or otherwise a chosen representation of a decimal number >> without resorting >> > to a try-except statement, or complicated verification schemes that have >> > to deal with a lot of corner cases. >> >> If you want to know whether the float() call will throw, the best way >> to check is to call float() and see if it throws. >> >> > For validity one has to check if there are only digits - and decimal >> points - >> > and the "-" unary sign. What if there is more of a "." in the string? >> > what if the "-" is not the first character? >> > And besides validity checking, there are also validity choices: >> > What if an unary "+" is present? Whitespace ok? "_" as digit separator >> ok? >> > scientific exponential notation accepted? What about Inf and Nan >> literals? >> > What about taking into account the locale setting? >> > >> > But maybe, instead of yet another str method, a "parsefloat" function >> > that could get arguments and sensitive defaults for some choices - >> > it could live in "math" or "numbers". >> >> How about a built-in called "float", which either returns the >> floating-point value represented by the string, or signals an invalid >> string with an exception? >> >> > I think it would be preferable than, say, adding a lot of options >> > to the `float` constructor. These are the options I can think >> > of the top of my mind: >> >> YAGNI. If you want to allow specific subsets of valid options, it's >> not that hard to do your own validation. >> >> > The return value would consitss of a boolean, where True would indicate >> success, and then the number. >> > Or it could return a single float, returning a NaN in case of parsing >> error. >> >> Or it could raise in the case of parsing error. That's the Pythonic way. >> >> Sorry, I thought my message conveyed that I know "float" exists, and > try/except is the current usable pattern (it is in the original posting > anyway) > > I tried to make clear this should be in addition to that - > But yes, I failed to mention in my message that I think such a function > would mostly benefit beginners learning around with "input" and "print" - > it is painful to suddenly have to tour the students on several other > concepts just > to get a correct user-inputed number. (OTOH, yes, for code on this level, > one normally won't be concerned if the program user will be typing > "1.02e2" on > the `input` prompt). > > The point is exactly that parsing a number correctly, and moreover > respecting > these options, is subject to error and the stdlib could benefit from > a construct that would not require a try/except block for everything. > (As you can see, I contemplate that raising may be a desired option for > a flexible function, and there is an option for that in my example > signature) . > > > > > > ChrisA >> ___ >> Python-ideas mailing list -- python-ideas@python.org >> To unsubscribe send an email to python-ideas-le...@python.org >>
[Python-ideas] Re: str.isfloat()
On 2020-12-27 at 19:55:39 -0300, "Joao S. O. Bueno" wrote: > I tried to make clear this should be in addition to that - But yes, I > failed to mention in my message that I think such a function would > mostly benefit beginners learning around with "input" and "print" - it > is painful to suddenly have to tour the students on several other > concepts just to get a correct user-inputed number. (OTOH, yes, for > code on this level, one normally won't be concerned if the program > user will be typing "1.02e2" on the `input` prompt). OTOH, learning that translating a user-entered string to a floating point number is not as simple as it sounds is a great lesson. Please don't teach beginners that handling user input (let alone floating point arithmetic) is easy and/or foolproof. Start with letting the program fail when the input is invalid, teach them to isolate input validation into its own function(s), and introduce try/except as one method of control flow in a validation function. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/GKMQV75D5PXLTC6SE2V7YFNHLKKPVN52/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: str.isfloat()
On Mon, Dec 28, 2020 at 9:55 AM Joao S. O. Bueno wrote: > On Sun, 27 Dec 2020 at 19:31, Chris Angelico wrote: > Sorry, I thought my message conveyed that I know "float" exists, and > try/except is the current usable pattern (it is in the original posting > anyway) And my point is that try/except is a perfectly usable pattern. You don't need to probe a string to figure out if you'd then be able to convert it to a float - just attempt the conversion. > The point is exactly that parsing a number correctly, and moreover respecting > these options, is subject to error and the stdlib could benefit from > a construct that would not require a try/except block for everything. > (As you can see, I contemplate that raising may be a desired option for > a flexible function, and there is an option for that in my example signature) > . You can always write the flexibility yourself. Most of the time you won't need anything like that much flexibility. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2SRSZQLR326SYNAWTPZY2A6PQ4BK6BWE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: str.isfloat()
On Sun, 27 Dec 2020 at 19:31, Chris Angelico wrote: > On Mon, Dec 28, 2020 at 9:22 AM Joao S. O. Bueno > wrote: > > > > I agree - the three builtin methods are almost the same (not sure if > > there is any difference at all), > > Yes - they all check if the string matches a particular set of characters. > > > while there is no trivial way to check for a valid > > float, or otherwise a chosen representation of a decimal number without > resorting > > to a try-except statement, or complicated verification schemes that have > > to deal with a lot of corner cases. > > If you want to know whether the float() call will throw, the best way > to check is to call float() and see if it throws. > > > For validity one has to check if there are only digits - and decimal > points - > > and the "-" unary sign. What if there is more of a "." in the string? > > what if the "-" is not the first character? > > And besides validity checking, there are also validity choices: > > What if an unary "+" is present? Whitespace ok? "_" as digit separator > ok? > > scientific exponential notation accepted? What about Inf and Nan > literals? > > What about taking into account the locale setting? > > > > But maybe, instead of yet another str method, a "parsefloat" function > > that could get arguments and sensitive defaults for some choices - > > it could live in "math" or "numbers". > > How about a built-in called "float", which either returns the > floating-point value represented by the string, or signals an invalid > string with an exception? > > > I think it would be preferable than, say, adding a lot of options > > to the `float` constructor. These are the options I can think > > of the top of my mind: > > YAGNI. If you want to allow specific subsets of valid options, it's > not that hard to do your own validation. > > > The return value would consitss of a boolean, where True would indicate > success, and then the number. > > Or it could return a single float, returning a NaN in case of parsing > error. > > Or it could raise in the case of parsing error. That's the Pythonic way. > > Sorry, I thought my message conveyed that I know "float" exists, and try/except is the current usable pattern (it is in the original posting anyway) I tried to make clear this should be in addition to that - But yes, I failed to mention in my message that I think such a function would mostly benefit beginners learning around with "input" and "print" - it is painful to suddenly have to tour the students on several other concepts just to get a correct user-inputed number. (OTOH, yes, for code on this level, one normally won't be concerned if the program user will be typing "1.02e2" on the `input` prompt). The point is exactly that parsing a number correctly, and moreover respecting these options, is subject to error and the stdlib could benefit from a construct that would not require a try/except block for everything. (As you can see, I contemplate that raising may be a desired option for a flexible function, and there is an option for that in my example signature) . ChrisA > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/F5TGEV5V4ZKAPSD5AI62EJ6YZRKQQPFQ/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/X3DYXKVBABN7IUCQQM7TWL4O3OUPW7U3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: str.isfloat()
On Mon, Dec 28, 2020 at 9:22 AM Joao S. O. Bueno wrote: > > I agree - the three builtin methods are almost the same (not sure if > there is any difference at all), Yes - they all check if the string matches a particular set of characters. > while there is no trivial way to check for a valid > float, or otherwise a chosen representation of a decimal number without > resorting > to a try-except statement, or complicated verification schemes that have > to deal with a lot of corner cases. If you want to know whether the float() call will throw, the best way to check is to call float() and see if it throws. > For validity one has to check if there are only digits - and decimal points - > and the "-" unary sign. What if there is more of a "." in the string? > what if the "-" is not the first character? > And besides validity checking, there are also validity choices: > What if an unary "+" is present? Whitespace ok? "_" as digit separator ok? > scientific exponential notation accepted? What about Inf and Nan literals? > What about taking into account the locale setting? > > But maybe, instead of yet another str method, a "parsefloat" function > that could get arguments and sensitive defaults for some choices - > it could live in "math" or "numbers". How about a built-in called "float", which either returns the floating-point value represented by the string, or signals an invalid string with an exception? > I think it would be preferable than, say, adding a lot of options > to the `float` constructor. These are the options I can think > of the top of my mind: YAGNI. If you want to allow specific subsets of valid options, it's not that hard to do your own validation. > The return value would consitss of a boolean, where True would indicate > success, and then the number. > Or it could return a single float, returning a NaN in case of parsing error. Or it could raise in the case of parsing error. That's the Pythonic way. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/F5TGEV5V4ZKAPSD5AI62EJ6YZRKQQPFQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: str.isfloat()
I agree - the three builtin methods are almost the same (not sure if there is any difference at all), while there is no trivial way to check for a valid float, or otherwise a chosen representation of a decimal number without resorting to a try-except statement, or complicated verification schemes that have to deal with a lot of corner cases. For validity one has to check if there are only digits - and decimal points - and the "-" unary sign. What if there is more of a "." in the string? what if the "-" is not the first character? And besides validity checking, there are also validity choices: What if an unary "+" is present? Whitespace ok? "_" as digit separator ok? scientific exponential notation accepted? What about Inf and Nan literals? What about taking into account the locale setting? But maybe, instead of yet another str method, a "parsefloat" function that could get arguments and sensitive defaults for some choices - it could live in "math" or "numbers". I think it would be preferable than, say, adding a lot of options to the `float` constructor. These are the options I can think of the top of my mind: ```python def parsefloat( input: str, /, *, unary_minus: Bool = True, unary_plus: Bool = False, exponential: Bool = False, inf_literal: Bool = False, nan_literal: Bool = False, whitespace: Bool = False, use_locale: Bool = False, digit_separators: Bool = False, base: int = 10 (?), decimal_places: Optional[int]=None(?), enforce_decimal_places: Bool = False(?), raise_on_error: Bool = False(?), ...) -> Tuple[Bool, float]: ... ``` The return value would consitss of a boolean, where True would indicate success, and then the number. Or it could return a single float, returning a NaN in case of parsing error. this is simple callable - but it could be built on top of a class that could take the configurations and parse more than one number - it would be fit as a float parser to be supplied for tasks like Json decoding, or converting values in a Pandas Series. On Sun, 27 Dec 2020 at 14:12, Tushar Sadhwani wrote: > str currently has methods like isdecimal, isnumeric and isdigit, but there > isn't an isfloat check, which could be very handy. > > a trivial implementation could be as simple as: > > try: > float(self) > return True > except ValueError: > return False > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/KEUR54FVEE7FRY4RGLK4IGTJOTKXQH5H/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7FJVCF746GOBTM5OD2TGRUCBGB2VSTIG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] str.isfloat()
str currently has methods like isdecimal, isnumeric and isdigit, but there isn't an isfloat check, which could be very handy. a trivial implementation could be as simple as: try: float(self) return True except ValueError: return False ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/KEUR54FVEE7FRY4RGLK4IGTJOTKXQH5H/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Add aggregations and joins code-generating library along with itertools
1. I think this is too complex for the stdlib. One tool should do one thing. What about the PEP for this project? 2. This is very particular. For those who often convert data in different ways, but do not use pandas, attrs, SQL... 3. What about `typing`? 4. OTF code generation (if I understood correctly) is an debugging hell. 5. `pylint` has "several complaints" about the code. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/NNVQEA25WQCQLH2RSBGTN3QOJU2JHFHK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Add aggregations and joins code-generating library along with itertools
Hello everyone! The idea: it would be cool to have the functionality of "convtools" library available along with "itertools". Python should provide decent functionality of aggregations and joins out-of- the-box. Given that named tuples generate some could, this one could too: https://pypi.org/project/convtools/ https://convtools.readthedocs.io/en/latest/cheatsheet.html https://github.com/iTechArt/convtools Please, let me know your view on this or any ideas (I would appreciate it). Thank you and happy holidays! Nikita Almakov ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/PP6HREMDLPMACAPIYQR3HD73UTHKGCLL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Unpack operator "**" and Mapping
Christopher Barker wrote: > My first thought is that for dataclasses, you can use the asdict() method, > and you're done. I thought in a similar way. I'll ask another (7K wtf in 2 years, 3 month) question about converting a dataclass to dict. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/Y3VLMQY3E7LPGIHN7P4WUJPMBZW37DLA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Unpack operator "**" and Mapping
0. I believe that the `dict` behavior needs to be frozen. The change will break a lot of existing code, it's too much damage. 0.1. Yes, `keys` is not a good name for internal use, but that's okay. 0.2. If I want to make a class look like a `dict`, I understand that I will get `keys`, `items`... This is what I expect. 0.3. When I work with dicts in my code, I have a choice, I can use the default `dict`, or I can create my own dict-like class and implement different behavior. 0.4. `other[k] for k in other.keys()` default behaviour in `dict.update(other: Dict)` is a different big question about the degree of damage. Basically I can use `dict.update(dict.items())`. Back to the stars: 1. `*`, `**` are operators, but behaviorally they are methods or functions. I think this is the main problem. 1.1. Python operators (mostly?) use their dunder methods to control their behavior. 1.2. Unpack operators are nailed to specific objects and their behavior, like an function or method. As a result, we lose control over them. 2. `*` nailed to `Iterable`, not so bad. 2.1. It uses the `__iter__` method. I can implement any behaviour. 2.2. I only see one problem. I can't realize any other behavior for iterating and unpacking inside a custom class. 2.3. A new special method for unpacking is a better idea. By default, this method should return `self.__iter__`. This will give control and not break existing code. 3. `**` nailed to `dict`. I think this is the fundamental problem. 3.1. `dict` is a good choice for the DEFAULT `kwargs` container. But `dict` is too excess for `**`. One method that returns an iterator is enough. 3.2. `**` use a `kwargs[k] for k in kwargs.keys()` like implementation. I have no control over this behavior. 3.3. I am forced to implement excessive functionality. 3.4. I must take userspace named `keys()`. 3.5. I cannot implement `keys` and `__getitem__` independent unpacking inside the class. 4. Which I think we can do. 4.1. Make `*` and `**` operators with their own methods. 4.2. Implement `return self .__ iter __ ()` as the default behavior of `*`. 4.3. Create a new implementation of the `**` operator expecting: `Iterator [Tuple [key, val]]`. 4.4. Implement `return ((k, self[k]) for k in self.keys())` as the specific behaviour of `dict`. 4.5. Create a `collections.abc` layout with an abstract two star unpacking method. 4.6. Update PEP 448. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XTNNF2ZW52KCT4MJW5POJWZLIXXZZJ4G/ Code of Conduct: http://python.org/psf/codeofconduct/