[Python-ideas] Re: Conditional 1-line expression in python (Dom Grigonis)
Hello all,
Please Dom Grigonis add choices :
- "No preference" choice to first question
- "I don't know" or "I can't tell" to third question
And I will answer to your poll and probably other people will feel and
do the same.
I agree that question 2 makes me prefer C syntax.
But C is not the nicest syntax in my point of view.
In MySQL SQL, there is IF(condition, if_result, else_result)
which I find nice.
Moreover, it fits well with black style of formatting:
foo_var = IF(
this_is_a very_long_condition_expression_which_may_have_nested_parts,
this_is_a very_long_if_result_expression_which_may_have_nested_parts,
this_is_a very_long_else_result_expression_which_may_have_nested_parts,
)
to compare with :
foo_var = (
this_is_a very_long_condition_expression_which_may_have_nested_parts,
? this_is_a very_long_if_result_expression_which_may_have_nested_parts,
: this_is_a very_long_else_result_expression_which_may_have_nested_parts,
)
I can enjoy both, but I prefer the SQL apart from the fact that "IF"
keyword would be ambiguous.
I also enjoy very much :
foo_var = CASE
WHEN condition THEN if_result
WHEN condition2 THEN elif_result
ELSE else_result
END
from SQL.
And CASE is not a reserved keyword and WHEN, THEN, ELSE could have
specific meaning inside of case.
Truly, I would enjoy the following syntax for Python à la black :
foo_var = case(
when condition then if_result
when condition2 then elif_result
else else_result
)
or even more concise and still readable :
foo_var = case(
condition : if_result,
condition2 : elif_result,
else_result,
)
Best regards,
Laurent Lyaudet
Le lun. 17 juil. 2023 à 22:42, a écrit :
>
> Message: 2
> Date: Mon, 17 Jul 2023 23:41:25 +0300
> From: Dom Grigonis
> Subject: [Python-ideas] Conditional 1-line expression in python
> To: python-ideas
> Message-ID: <31303e8b-05a4-408b-af4d-916f805b5...@gmail.com>
> Content-Type: multipart/alternative;
> boundary="Apple-Mail=_41C44739-410D-45EA-89FF-6E2F1AF86836"
>
> Hi everyone,
>
> I am not very keen on long discussions on such matter as I do not think there
> is much to discuss: there is no technical complexity in it and it doesn’t
> really change or introduce anything new. It is only a matter of opinion &
> style/design preferences with respect to logical order and brevity of a
> statement.
>
> So I thought, if anyone can be bothered on such question and instead of
> writing 3-minute e-mail, would take few seconds to answer 3-question poll.
>
> https://q5yitzu62.supersurvey.com <https://q5yitzu62.supersurvey.com/>
>
> Would be interesting to see if my preference is an outlier or not really.
>
>
> Kind regards,
> D. Grigonis
>
>
> -- next part --
> A message part incompatible with plain text digests has been removed ...
> Name: not available
> Type: text/html
> Size: 1499 bytes
> Desc: not available
>
> --
>
> Subject: Digest Footer
>
> ___
> 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/
>
>
> --
>
> End of Python-ideas Digest, Vol 200, Issue 34
> *
___
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/F3D6T4AEQLFIK7B3AXTUAJERI3BANMHP/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Feedback before submission of PEP 661: Sentinel Values
Hello, Thanks for this nice PEP, I have just read it. I think it is a good thing to add to Python and will enable cleaner code. I support the idea to have common sentinels suggested by Christopher Barker. For example, a common confusion is to identify None with NULL in DB, but then when you are filtering rows in a SQL query generated by a framework function, you have to do convoluted things because most frameworks do not distinguish "Do not filter" and "Keep only rows where value is NULL", because the vocabulary of sentinels is too limited. Some sentinels could be created also for some constants of R language for example. Anyway, extending the language with common sentinels can be done later. But it would be nice to really think about it. Regarding the type of Sentinels, the proposition in the PEP is not perfect. Recently, I used MY_SENTINEL = object() TypeMySentinel = Literal(MY_SENTINEL) in my code. But what I would have like to be able to do is just : TypeMySentinel = MY_SENTINEL exactly like None "is" its own type. However, it was rejected on import of the corresponding file, when using it in function signature. It would be really nice if all sentinel values could have this feature to be their own type. Last, I spotted a typo in the PEP : "Most common exiting idioms" -> "existing' Thanks, best regards, Laurent Lyaudet, PhD ___ 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/NOWXLQPAVG4T7FNCDBOF6IZRXYI7B4L3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Feature request enumerate_with_rest or enumerate with skip or filter callback
Le dim. 3 oct. 2021 à 16:21, a écrit : > Date: Mon, 4 Oct 2021 01:03:34 +1100 > From: Steven D'Aprano > Subject: [Python-ideas] Re: Feature request enumerate_with_rest or > enumerate with skip or filter callback > To: python-ideas@python.org > Message-ID: <20211003140333.gr16...@ando.pearwood.info> > Content-Type: text/plain; charset=us-ascii > > Hi Laurent, Hello Steve, > It is not clear to me what you mean by "filter by indices". > > On Sat, Oct 02, 2021 at 10:25:05PM +0200, Laurent Lyaudet wrote: > > > The idea is to filter a list by indices : > [...] > > Since filter() returns an iterator instead of a list, it could do what > > is needed... if the callback had access to the index like the > > Javascript array filter function. > > Do you mean this? > > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/filter Yes exactly, > You shouldn't assume we are all experts on Javascript :-) > No problem, I'll give more links next time :) > If that is what you want, it is easy to get access to the index. We can > just do: > > filter(function, enumerate(items)) > That's exactly what I proposed. Except for the fact that I incorrectly permuted the two arguments of filter. I quote my second email : Le sam. 2 oct. 2021 à 22:35, a écrit : > Date: Sat, 2 Oct 2021 22:25:05 +0200 > From: Laurent Lyaudet >... > Currently, the following solution is available : > filter(enumerate(my_list), lambda x: x[0] != i) > But it is slightly ugly and unefficient to have two function calls for > such a simple task I think. I feel uncomfortable because it is often the case that I write explicitly something, and I get an answer as if the person answered without reading all my email or reading another version. > If you want something else, I'm afraid you will have to explain in more > detail what you want, sorry. Again for my second email, I would like one of these 3 options. > What would be your prefered way of doing this ? > enumerate(my_list, filter_callback=(lambda x: x != i)) > filter_by_index(my_list, lambda x: x != i) > # à la JS > filter(my_list, lambda _, x: x != i) filter_by_index(lambda x: x != i, my_list) could be defined as follow (I permuted args to have similar order to python's filter()): def filter_by_index(function, my_list): for i, item in enumerate(my_list) if function(i): yield item like filter is just (without the case function=None) filter(function, my_list): for i, item in enumerate(my_list) if function(item): yield item The problem is not that it is hard to code in Python. The problem is that it is a basic building block for an iterators tools library like itertools. enumerate(my_list, filter_callback=(lambda x: x != i)) could be defined in a similar way but there are two variants. It just needs to return one of the two indices of the item: - either the index of the item in the original sequence, - or the index of the item in the filtered sequence (new counter). For my use case, I do not need the index so I have no argument in favor of either one of the two indices. > # à la JS > filter(my_list, lambda _, x: x != i) You provided the link from MDN and an helper function for that. The lambda takes 2 or 3 parameters: item, index, array/list/sequence and returns true for item that must be output. I see nothing more to say. Best regards, Laurent Lyaudet ___ 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/OYN3N45QN57AABWD235WHXY4GWTQYBUO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Python-ideas Digest, Vol 179, Issue 25
Le dim. 3 oct. 2021 à 16:21, a écrit : > Date: Mon, 4 Oct 2021 01:03:34 +1100 > From: Steven D'Aprano > Subject: [Python-ideas] Re: Feature request enumerate_with_rest or > enumerate with skip or filter callback > To: python-ideas@python.org > Message-ID: <20211003140333.gr16...@ando.pearwood.info> > Content-Type: text/plain; charset=us-ascii > > Hi Laurent, Hello Steve, > It is not clear to me what you mean by "filter by indices". > > On Sat, Oct 02, 2021 at 10:25:05PM +0200, Laurent Lyaudet wrote: > > > The idea is to filter a list by indices : > [...] > > Since filter() returns an iterator instead of a list, it could do what > > is needed... if the callback had access to the index like the > > Javascript array filter function. > > Do you mean this? > > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/filter Yes exactly, > You shouldn't assume we are all experts on Javascript :-) > No problem, I'll give more links next time :) > If that is what you want, it is easy to get access to the index. We can > just do: > > filter(function, enumerate(items)) > That's exactly what I proposed. Except for the fact that I incorrectly permuted the two arguments of filter. I quote my second email : Le sam. 2 oct. 2021 à 22:35, a écrit : > Date: Sat, 2 Oct 2021 22:25:05 +0200 > From: Laurent Lyaudet >... > Currently, the following solution is available : > filter(enumerate(my_list), lambda x: x[0] != i) > But it is slightly ugly and unefficient to have two function calls for > such a simple task I think. I feel uncomfortable because it is often the case that I write explicitly something, and I get an answer as if the person answered without reading all my email or reading another version. > If you want something else, I'm afraid you will have to explain in more > detail what you want, sorry. Again for my second email, I would like one of these 3 options. > What would be your prefered way of doing this ? > enumerate(my_list, filter_callback=(lambda x: x != i)) > filter_by_index(my_list, lambda x: x != i) > # à la JS > filter(my_list, lambda _, x: x != i) filter_by_index(lambda x: x != i, my_list) could be defined as follow (I permuted args to have similar order to python's filter()): def filter_by_index(function, my_list): for i, item in enumerate(my_list) if function(i): yield item like filter is just (without the case function=None) filter(function, my_list): for i, item in enumerate(my_list) if function(item): yield item The problem is not that it is hard to code in Python. The problem is that it is a basic building block for an iterators tools library like itertools. enumerate(my_list, filter_callback=(lambda x: x != i)) could be defined in a similar way but there are two variants. It just needs to return one of the two indices of the item: - either the index of the item in the original sequence, - or the index of the item in the filtered sequence (new counter). For my use case, I do not need the index so I have no argument in favor of either one of the two indices. > # à la JS > filter(my_list, lambda _, x: x != i) You provided the link from MDN and an helper function for that. The lambda takes 2 or 3 parameters: item, index, array/list/sequence and returns true for item that must be output. I see nothing more to say. Best regards, Laurent Lyaudet ___ 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/VBRVBGN5EFFM7F2NWYTNYRMPDO2IN32R/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Feature request enumerate_with_rest or enumerate with skip or filter callback
Le dim. 3 oct. 2021 à 06:01, Stephen J. Turnbull a écrit : > > Laurent Lyaudet writes: > > Hello, > > > > This is a very simple feature request that does not break anything but > > I don't know if you may find it interesting. > > It would be nice to have a function or method of list objects that does > this : > > - First idea : > > def enumerate_with_rest(my_list): > > for i, item in enumerate(my_list): > > yield i, item, my_list[:i] + my_list[i + 1:] > > First, the name confused me, at least: in many contexts dealing with > iteration, "rest" means tail. > > Second, what's wrong with: > > for i, item in enumerate(my_list): > rest = my_list[:i] + my_list[i + 1:] > # do stuff with i, item, rest > > compared to > > for i, item, rest in enumerate_with_rest(my_list): > # do stuff with i, item, rest > > You save one line, but you (and everyone who reads your code) needs to > learn a new function definition, and you need to remember it on every > invocation. On the other hand, "explicit is better than implicit" > (which goes back to my confusion of "rest" with "tail"). > > Unless you can show both a substantial speedup with a native C > implementation (which leaves out any Python implementation in a > different language) and a need for that speed, I'm -1 on defining this > at all. It's not one of those cases where defining even a one-line > function is easy to get semantically wrong. > Hello, Thanks for your feedback. You do not quote my second email where I also said that enumerate_with_rest was probably too specific and not worth it. I would appreciate your feedback on my second email where I stress out that python is missing a "filter_by_index" construct and give several propositions. Best regards, Laurent Lyaudet ___ 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/L2JCDWBN2QNND426IPEQGD6NP2EEXLJ3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Feature request enumerate_with_rest or enumerate with skip or filter callback
Le sam. 2 oct. 2021 à 15:54, a écrit : > Date: Sat, 2 Oct 2021 12:45:33 +0200 > From: Laurent Lyaudet > Subject: [Python-ideas] Feature request enumerate_with_rest or > enumerate with skip or filter callback > To: python-ideas@python.org > Message-ID: > > Content-Type: text/plain; charset="UTF-8" > > Hello, > > This is a very simple feature request that does not break anything but > I don't know if you may find it interesting. > It would be nice to have a function or method of list objects that does this : > - First idea : > def enumerate_with_rest(my_list): > for i, item in enumerate(my_list): > yield i, item, my_list[:i] + my_list[i + 1:] > > It could be called easily with: > > for i, item, rest in enumerate_with_rest(my_list): ># do something > > or > for i, item, rest in my_list.enumerate_with_rest(): ># do something > > I am not the only one who had the same need : > https://stackoverflow.com/questions/56966429/getting-pairs-of-one-item-and-the-rest-over-a-python-list > > It would be nice to have an optimized C function for this. > However, it may be less interesting than this : > - Second idea > enumerate_with_rest above has quadratic complexity. > It is probably true that most processes that use it will also have > quadratic complexity. > However, it would be better to return an iterator instead of a list > for the rest, > it would use less space. > For this a param skip to enumerate would do the job > def enumerate_with_rest(my_list): > for i, item in enumerate(my_list): > yield i, item, enumerate(my_list, skip=i) > There could be variants of this idea like : > - enumerate(my_list, skip=i) > - enumerate(my_list, skip=[i]) > - enumerate(my_list, filter_callback=(lambda x: x != i)) > > Please let me know what you think of it :) > > Thanks for your time, best regards, > Laurent Lyaudet Hello, Regarding the last suggestion. - enumerate(my_list, filter_callback=(lambda x: x != i)) The idea is to filter a list by indices : a quick search for that just yields : https://stackoverflow.com/questions/11847491/python-filtering-lists-by-indices which is not really helpful Since filter() returns an iterator instead of a list, it could do what is needed... if the callback had access to the index like the Javascript array filter function. > def enumerate_with_rest(my_list): > for i, item in enumerate(my_list): > yield i, item, my_list[:i] + my_list[i + 1:] could also be : def enumerate_with_rest(my_list): for i, item in enumerate(my_list): yield i, item, filter_by_index(my_list, lambda x: x != i) I think my feature request for enumerate_with_rest is maybe too specific. However, I think there should definitely be in itertools something to filter indices like JS permits. I have not found a function to do this there: https://docs.python.org/3/library/functions.html https://docs.python.org/3/library/itertools.html What would be your prefered way of doing this ? enumerate(my_list, filter_callback=(lambda x: x != i)) filter_by_index(my_list, lambda x: x != i) # à la JS filter(my_list, lambda _, x: x != i) Currently, the following solution is available : filter(enumerate(my_list), lambda x: x[0] != i) But it is slightly ugly and unefficient to have two function calls for such a simple task I think. I would appreciate any feedback; even if none of my ideas are accepted, I may learn something :) Best regards, Laurent Lyaudet ___ 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/U224WQJP5P3D6YV523EGT4F74JFDJ5W5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Feature request enumerate_with_rest or enumerate with skip or filter callback
Hello, This is a very simple feature request that does not break anything but I don't know if you may find it interesting. It would be nice to have a function or method of list objects that does this : - First idea : def enumerate_with_rest(my_list): for i, item in enumerate(my_list): yield i, item, my_list[:i] + my_list[i + 1:] It could be called easily with: for i, item, rest in enumerate_with_rest(my_list): # do something or for i, item, rest in my_list.enumerate_with_rest(): # do something I am not the only one who had the same need : https://stackoverflow.com/questions/56966429/getting-pairs-of-one-item-and-the-rest-over-a-python-list It would be nice to have an optimized C function for this. However, it may be less interesting than this : - Second idea enumerate_with_rest above has quadratic complexity. It is probably true that most processes that use it will also have quadratic complexity. However, it would be better to return an iterator instead of a list for the rest, it would use less space. For this a param skip to enumerate would do the job def enumerate_with_rest(my_list): for i, item in enumerate(my_list): yield i, item, enumerate(my_list, skip=i) There could be variants of this idea like : - enumerate(my_list, skip=i) - enumerate(my_list, skip=[i]) - enumerate(my_list, filter_callback=(lambda x: x != i)) Please let me know what you think of it :) Thanks for your time, best regards, Laurent Lyaudet ___ 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/5LGWV3YLCNBVSL4QHQKJ7RPNTMWOALQA/ Code of Conduct: http://python.org/psf/codeofconduct/
