Mailman 3 March 2020 - Python-ideas

Re: Exception for parameter errors
by Marco Sulla 10 Mar '20

10 Mar '20

On Wed, 4 Mar 2020 at 12:33, Chris Angelico <rosuav(a)gmail.com> wrote: > Being able to easily distinguish "that isn't callable" from "the > parameters don't line up" from "the function, during execution, raised > TypeError" would be useful. I **completely** agree. And I add that the change can also be non-breaking, if the new ArgumentError is simply a subclass of TypeError. Yes, it's incorrect, but this way no old code will break. PS: if you read the official docs (https://docs.python.org/3/library/exceptions.html#TypeError): > exception TypeError > Raised when an operation or function is applied to an object of inappropriate type. etc. It's never stated that TypeError should be raised when the number of arguments is invalid, for example. It seems that TypeError itself is saying "now I'm used outside my scope" :-)

1 0

Re: Fwd: Possible Addition to Python Language: Marked Sub-condition
by Shrinivas Kulkarni 10 Mar '20

10 Mar '20

Hi Rajeev and others Thanks for your responses. I completely overlooked the simple fact that the conditions are evaluated to boolean values and as such can be stored in variables. In the hindsight there may perhaps be a couple of (far-fetched) merits to my proposal (like useful in conditions with dynamic function calls or sparing users the effort of maintaining rather ephemeral variables) but they are of course not worth the effort of making a change to the language itself. So I am sorry for the spam. Will be careful the next time. Best regards Shrinivas Kulkarni On Mon, Mar 9, 2020 at 10:21 AM Rajeev J Sebastian <rajeev.sebastian(a)alokin.in> wrote: > > Hi Shrinivas, > > Wouldn’t these just be variables? > > Cond1 = color == Blue and count == 20 > Cond2 = color == Red > > if cond1 or cond2: > Do something > elif cond3: > Do something else > > Regards > Rajeev J Sebastian > On 8 Mar 2020, 20:42 +0530, Shrinivas Kulkarni <shrinivk(a)gmail.com>, wrote: > > Hello Everyone > > While writing python code, I frequently come across the need to do > certain tasks based on combined conditions. > > Much of the task for all the sub-conditions are common but some are > specific to one or more of these sub-conditions. > > A simplified example: > > ########################## Code ########################## > if (color == BLUE and count == 20) or (color == RED and count % 5 == 0): > rotate_the_wheel() # Common to the two sub-conditions > if(color == BLUE and count == 20): # First sub-condition > set_signal() > if(color == RED and count % 5 == 0): # Second sub-condition > clear_signal() > proc_post_rotate() # Common to the two sub-conditions > > I am not sure if there is a better way to do this. If not, maybe there > can be an extension to the language, which would allow marking a > sub-condition just like we mark a sub-expression in a regular > expression. > > Tentative syntax for this could be ({} marks the sub-condition and > \number refers back to it): > > ########################## Code ########################## > if {(color == BLUE and count == 20)} or {(color == RED and count % 5 == 0)}: > rotate_the_wheel() > if(\1): # First marked condition > set_signal() > if(\2): # Second marked condition > unset_signal() > proc_post_rotate() > > And like sub-expressions, the nesting of marked sub-condions should > also be possible: > > ########################## Code ########################## > if {{(color == BLUE and count == 20)} and {value == 20}} or {(color == > RED and count % 5 == 0)}: > if(\1):# Refers to the entire subcondition {{(color == BLUE and > count == 20)} and {value = 20}} > proc1() > if(\2):# Refers to sub-subcondition {value == 20} > > This will not only avoid the repetition of sub-conditions, but make > code readable since something like \1 will give an immediate > indication of a sub-condition that's defined earlier. > > Please let me know something similar is already implemented. > Even otherwise, all your thoughts, inputs and criticism are welcome. > > Thanks and best regards > Shrinivas Kulkarni > _______________________________________________ > Python-ideas mailing list -- python-ideas(a)python.org > To unsubscribe send an email to python-ideas-leave(a)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/M5OUL… > Code of Conduct: http://python.org/psf/codeofconduct/

2 1

Mailman 3 monthly summaries broken for Python-ideas
by André Roberge 09 Mar '20

09 Mar '20

I am currently attempting to go through the entire archives of Python-ideas to make a summary of the discussions about adding a syntax for decimal literals in Python. In doing so, I encountered a weird bug which I find especially annoying since it makes me look like a spammer. If one goes through the archives by month, from May 2010 [1] to June 2011 [2], the first post shown at the top for each and every one of these monthly treads is one I wrote on May 15, 2010 [3]. This problem is not limited to the period between May 2010 and June 2011, as other misplaced posts often appear at or near the top of monthly tread summaries. [1] https://mail.python.org/archives/list/python-ideas@python.org/2010/5/ [2] https://mail.python.org/archives/list/python-ideas@python.org/2011/6/ [3] https://mail.python.org/archives/list/python-ideas@python.org/thread/G4JCU5… Please note that there is no need to discuss the idea I mentioned in that old thread as it has since been implemented as a separate package. André Roberge

4 3

Re: Possible Addition to Python Language: Marked Sub-condition
by Paul Moore 09 Mar '20

09 Mar '20

On Sun, 8 Mar 2020 at 15:02, Shrinivas Kulkarni <shrinivk(a)gmail.com> wrote: > > Hello Everyone > > While writing python code, I frequently come across the need to do > certain tasks based on combined conditions. > > Much of the task for all the sub-conditions are common but some are > specific to one or more of these sub-conditions. > > A simplified example: > > ########################## Code ########################## > if (color == BLUE and count == 20) or (color == RED and count % 5 == 0): > rotate_the_wheel() # Common to the two sub-conditions > if(color == BLUE and count == 20): # First sub-condition > set_signal() > if(color == RED and count % 5 == 0): # Second sub-condition > clear_signal() > proc_post_rotate() # Common to the two sub-conditions > > I am not sure if there is a better way to do this. If not, maybe there > can be an extension to the language, which would allow marking a > sub-condition just like we mark a sub-expression in a regular > expression. I would have thought that simply naming the sub-conditions would be sufficient. blue_20 = (color == BLUE and count == 20) red_5 = (color == RED and count % 5 == 0) if blue_20 or red_5: rotate_the_wheel() # Common to the two sub-conditions if blue_20: # First sub-condition set_signal() if red_5: # Second sub-condition clear_signal() proc_post_rotate() # Common to the two sub-conditions I don't know how experienced you are with Python programming, but if you had framed your question as "how do I modify this code to avoid repeating the conditions?" you would likely have been given this advice on the python-list mailinglist, or other similar Python programming help resources. Starting with a proposed language change before you've explored the existing options isn't likely to be the best approach (and would likely have meant you could resolve your issue without needing to bring it to python-ideas at all). Paul

3 2

When type hint is used, Python forbids checking variable types at run time
by 铁皮石斛 09 Mar '20

09 Mar '20

An immature idea. Python now has a type prompt, so you can provide a parameter for the Python interpreter to control whether to open the check type operation. For example, in the code, I explicitly use the type prompt, such as: # Test1.py def foo(a: str, b: str) -> str: c = None # type:str return 'hi' We can run the code with a parameter, such as python -T test1.py To prevent the Python interpreter from detecting the variable types in it, so as to improve the running speed. Thank you for reading.

2 1

Fwd: Possible Addition to Python Language: Marked Sub-condition
by Shrinivas Kulkarni 08 Mar '20

08 Mar '20

Hello Everyone While writing python code, I frequently come across the need to do certain tasks based on combined conditions. Much of the task for all the sub-conditions are common but some are specific to one or more of these sub-conditions. A simplified example: ########################## Code ########################## if (color == BLUE and count == 20) or (color == RED and count % 5 == 0): rotate_the_wheel() # Common to the two sub-conditions if(color == BLUE and count == 20): # First sub-condition set_signal() if(color == RED and count % 5 == 0): # Second sub-condition clear_signal() proc_post_rotate() # Common to the two sub-conditions I am not sure if there is a better way to do this. If not, maybe there can be an extension to the language, which would allow marking a sub-condition just like we mark a sub-expression in a regular expression. Tentative syntax for this could be ({} marks the sub-condition and \number refers back to it): ########################## Code ########################## if {(color == BLUE and count == 20)} or {(color == RED and count % 5 == 0)}: rotate_the_wheel() if(\1): # First marked condition set_signal() if(\2): # Second marked condition unset_signal() proc_post_rotate() And like sub-expressions, the nesting of marked sub-condions should also be possible: ########################## Code ########################## if {{(color == BLUE and count == 20)} and {value == 20}} or {(color == RED and count % 5 == 0)}: if(\1):# Refers to the entire subcondition {{(color == BLUE and count == 20)} and {value = 20}} proc1() if(\2):# Refers to sub-subcondition {value == 20} This will not only avoid the repetition of sub-conditions, but make code readable since something like \1 will give an immediate indication of a sub-condition that's defined earlier. Please let me know something similar is already implemented. Even otherwise, all your thoughts, inputs and criticism are welcome. Thanks and best regards Shrinivas Kulkarni

1 0

Re: [Python-ideas] Allow star unpacking within an slice expression
by Neil Girdhar 07 Mar '20

07 Mar '20

I didn't think of this when we were discussing 448. I ran into this today, so I agree with you that it would be nice to have this. Best, Neil On Monday, December 4, 2017 at 1:02:09 AM UTC-5, Eric Wieser wrote: > > Hi, > > I've been thinking about the * unpacking operator while writing some numpy > code. PEP 448 allows the following: > > values = 1, *some_tuple, 2 > object[(1, *some_tuple, 2)] > > It seems reasonable to me that it should be extended to allow > > item = object[1, *some_tuple, 2] > item = object[1, *some_tuple, :] > > Was this overlooked in the original proposal, or deliberately rejected? > > Eric >

2 2

More descriptive error message than "too many values to unpack"
by Alex Hall 06 Mar '20

06 Mar '20

Currently this code: d = {"key": "value"} for key, value in d: pass produces this error: ValueError: too many values to unpack (expected 2) I suggest that the error message should also have: 1. The name of the type of the unpacked value 2. The length of the unpacked value, if it exists and (to not execute arbitrary __len__ implementations) if the type belongs to a safe subset, e.g. only builtin types. Then the error message could be: ValueError: too many values to unpack (expected 2, found 3) from object of type str

8 11

CSV Dictwriter - Handling escape characters
by allu.matikainen＠hotmail.com 06 Mar '20

06 Mar '20

Hi, I would like if the DictWriter would be able to write escape characters (\n and \r and their combinations such as \n\n\n and \r\n) as literal characters. At the moment, DictWriter writes \n:s as new lines (shown in notepad or Excel) and I would like it to just write "\n" characters in my csv file. I asked a question about this on Stack Overflow but have had no good answers yet. My question also has an example of the data and its form. https://stackoverflow.com/questions/60073809/python-how-to-write-literal-n-…

6 5

IDEA: Allow override of all assignments of a built in type to be a different type
by Steve Barnes 05 Mar '20

05 Mar '20

One of the lovely things about Python is that we have the capability to avoid issues such as the vagaries of the floating point type with libraries such as decimal and fractions. This is wonderous to me but comes with an issue that I suspect is limiting its usage. That issue is that you have to litter your code with constructors of those types, e.g. ``` a = 0.1 b = 0.2 c = 0.3 a + b == c # This doesn't work but it is easy to forget why ``` vs: ``` from decimal import * # I know why this is bad but it comes straight from the examples a = Decimal("0.1") # Needs to be a string to avoid being temporarily a float b = Decimal("0.2") # Ditto c = Decimal("0.3") # Ditto a + b == c # Magic this works! ``` While this works it is not very friendly to users and there will often be cases where people forget to quote the values, etc. and there are similar issues with using the fractions library and I am sure with others. I suspect that this is why the decimals library, and some others, is not used as widely as it possibly should be. Wouldn't it be possible to have something along the lines of: ``` from decimal import TreatFloatsAsDecimal @TreatFloatsAsDecimal a = 0.1 # These are all now decimals b = 0.2 c = 0.3 a + b == c # This now works ``` Less obviously this sort of approach could also apply to making all integers into Fractions or other base types into something else. I do know that this goes against the explicit is better than implicit so an alternative might be to have a flexible base modifier, something like: ``` from decimal import DecimalBase as D a = 0D0.1 # These are all now decimals b = 0D0.2 c = 0D0.3 a + b == c # This now works ``` Since anything like this would require overriding at least part of the base interpreter I do not think that this is a suitable one for an external PyPi library or at least some hooks in the interpreter would be required to make it possible. Any thoughts, feedback, interest, expressions of horror? Or is this already there and I have missed it? Steve Barnes

11 16