[Python-ideas] Re: Tuple Comprehension
On Sun, Nov 17, 2019, at 21:39, Daniel Zeng wrote: > Syntax for tuple comprehension, something like: > (i, for i in range(10)) > > This shouldn't result in ambiguity, since generators need to be in > parentheses anyway: > (i, for i in range(10)) vs (1, (i for i in range(10))) I think it should be (i for i in range(10),). I'd expect your syntax to make a generator that yields 1-tuples. ___ 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/BRSPCPOWTRSCHDEMXKJKKST5FTUIAOSF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Tuple Comprehension
> > Is this meant to produce a tuple that contains inner tuples, or is it > the same as tuple(i for i in range(10)) ? This would be equivalent to tuple(i for i in range(10)) > Is the comma just magic that says "tuple comprehension, not genexp"? I think that my proposal is consistent with Python's current tuple syntax, especially for one element: ((1,),) # all very similar, but ((1,),) ((1,)) # (1,) ((1),) # (1,) ((1)) # 1 I would say the comma says "tuple, not expression": (1+2)*3 # 9 (1+2,)*3 # (3, 3, 3) ___ 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/4X3ER6UDU3XKMML4F2O5OQW5MRVL6Q5Q/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation
On Sun, Nov 17, 2019, at 16:43, Greg Ewing wrote: > Probably. I may also have mixed it up with closing(), which > does something different. It occurs to me that almost any usage of closing likely has the same problem, in that the expression passed to closing may itself throw an exception. It may be worth incorporating closing into the mechanism I proposed in another reply (i.e. something similar to my deferred_caller, but having its cleanup code call .close on the non-context-manager object returned by the given callable) ___ 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/YDQ4GQNZUCGXHZVCRNZULXEVH3NF6OJC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation
On Sun, Nov 17, 2019, at 14:17, Oscar Benjamin wrote: > Also I don't know of any other misbehaving context managers besides > open so I'm not sure that a general utility is needed rather than just > a well-behaved alternative for open. It's not in dbapi2, but most database connections are context managers, including sqlite3 in the stdlib. So is requests.Response (so is Session, but AIUI it can't return an error on construction, whereas Response is returned by functions like get which raise exceptions) ___ 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/SI5SS37BF3POXVXYPNZTAH2IAOTDZUMZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Tuple Comprehension
Syntax for tuple comprehension, something like: (i, for i in range(10)) This shouldn't result in ambiguity, since generators need to be in parentheses anyway: (i, for i in range(10)) vs (1, (i for i in range(10))) ___ 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/LSGZF3G4RFVTKXB5Y2EW5USL2JANG5RS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Consider blocking heterogeneous chained comparison
> Please recall that chained comparisons such are > >>> A < B < C > is to produce simple code when B is not an identifier, but an expression. For example > >>> low < len(x) < high > or > >>> inner ** 2 < x**2 + y**2 + z**2 < outer**2 > which determines if (x, y, z) is in a spherical shell. Even in those cases, each individual expression could be stored in a variable before doing the comparison: >>> a, b, c = inner ** 2, x**2 + y**2 + z**2, outer**2 >>> a < b and b < c But then again I don't find the rich boolean comparison operators (<, <=, >, =>, ==, !=) to be an issue when they're chained together on standard numeric types such as the above example, particularly when it's the same operator. IMO, it only becomes difficult to read when the operators start to become "mixed up"; more so when the objects are not the builtin types and have overridden operators: >>> a is b < c in d Not only do you have to sort out what is happening logically with the operators, you also have to figure out what those operators actually do for that particular object. Whether or not that is "readable" might be somewhat subjective though. But I think we're probably veering a bit off topic here, the main focus of this thread is on whether or not "A in B < C" should be permissible syntax. Although I'm not a fan of the syntax, I don't think it would be worthwhile for it to raise a SyntaxError for the reasons I mentioned previously. This seems to be something to either enforce in a linter or manually revise in a code review process, rather than through the language itself. ___ 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/TGS4TRV54E2EB3OQJ5W7FMQ6GHPXJNI7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation
On 18/11/19 8:17 am, Oscar Benjamin wrote: PEP 343 gives the example of "opened" which doesn't have this problem https://www.python.org/dev/peps/pep-0343/#examples but apparently that didn't make it to the final release of 2.5 (I guess that's what Greg is referring to). Probably. I may also have mixed it up with closing(), which does something different. -- Greg ___ 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/AS466ZD7RCOENU6Y4KIJU6ZRRQ7HQDA5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Using 'with' with extra brackets for nicer indentation
On Sun, 17 Nov 2019 at 06:28, Random832 wrote: > On Sat, Nov 16, 2019, at 16:13, Greg Ewing wrote: > > > > I seem to remember we had such a context manager for a brief > > time after the with-statement was invented, until someone had > > the bright idea to make open() do double duty. > > > > The main source of confusion I foresee if we re-introduce it, > > is that people are now used to doing 'with open()...', so we > > either make open() no longer a context manager and break > > existing code, or have two ways to do it, with the one that is > > currently the most widely used one having a subtle trap hidden > > in it. > > I wonder if a general mechanism for turning badly behaved context manager > factories into nice ones would be a useful addition to contextlib. something > like this: That might be useful but it doesn't solve the problem from the perspective of someone writing context manager utilities like nested because it still leaves a trap for anyone who uses open with those utilities. Also I don't know of any other misbehaving context managers besides open so I'm not sure that a general utility is needed rather than just a well-behaved alternative for open. PEP 343 gives the example of "opened" which doesn't have this problem https://www.python.org/dev/peps/pep-0343/#examples but apparently that didn't make it to the final release of 2.5 (I guess that's what Greg is referring to). Ultimately the problem is that the requirements on a context manager are not clearly spelled out. The with statement gives context manager authors a strong guarantee that if __enter__ returns successfully then __exit__ will be called at some point later. There needs to be a reverse requirement on context manager authors to guarantee that it is not necessary to call __exit__ whenever __enter__ has not been called. With the protocol requirements specified in both directions it would be easy to make utilities like nested for combining context managers in different ways. -- Oscar ___ 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/6SHONDJJCITR55JX7KCX6OAP7VG7I3EI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Consider blocking heterogeneous chained comparison
Kyle Stanley wrote: > I agree, that syntax definitely seems counter-intuitive. If it came up in > a code review, I would request a revision to "A in B and B < C". > Please recall that chained comparisons such are >>> A < B < C is to produce simple code when B is not an identifier, but an expression. For example >>> low < len(x) < high or >>> inner ** 2 < x**2 + y**2 + z**2 < outer**2 which determines if (x, y, z) is in a spherical shell. Even for "A < B < C" it might be better to have "A < B and B < C". Particularly if B and C are complicated expressions. -- Jonathan ___ 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/737OEOYCOLU26QJNVCBSJ7IKDCGROB5W/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Consider blocking heterogeneous chained comparison
> Some people find this legal syntax confusing: > A in B < C I agree, that syntax definitely seems counter-intuitive. If it came up in a code review, I would request a revision to "A in B and B < C". > I feel like most code reviews would not allow this kind of code to be checked in, at least without a comment explaining what the code does. What are the motivating reasons for allowing this syntax? Is there any idiomatic code that uses it? I can't personally imagine any practical use case for the syntax that couldn't be expressed differently in a way that's far more clear to readers. But, I don't think this is so much of a case of us choosing to *allow* the syntax, this seems to be more of a case where we don't explicitly *prevent* the syntax (through raising a SyntaxError). >From my experience, SyntaxError is raised primarily from clear mistakes that are easy to make (particularly for those who are new to the language or accidental typos) rather than simply syntax that is obscure, impractical, and/or hard to understand. It's realistically impossible to isolate every case of highly counter-intuitive usage of Python syntax, not to mention the resources it takes to implement a SyntaxError for each of them. To me, it seems that the usage of "A in B C" is something that's not easy to do by accident, I can't imagine what someone would be intending to practically accomplish and mistakenly end up with that syntax, not knowing it could be expressed differently. A few important questions to consider: 1) Is this syntax misused enough to justify implementing a SyntaxError? 2) Would raising a SyntaxError help to point those who misuse it in the right direction? 3) Is it worth the resources it would take to implement the SyntaxError? 4) Does implementing the SyntaxError provide enough positive benefit to justify breaking backwards compatibility? Even if it's very rarely used and could be expressed differently, this still applies. > Also, in my opinion, the existence is a deterrent to Python and takes away from Python's beauty as a language. I would have to disagree, every language has its obscure corner cases and confusing ways to write expressions. I don't think the number of ways that users can misuse the language in an obscure manner to write confusing code should at all detract from it's beauty. If it were easy to misuse the language and *accidentally* write confusing code that would be one thing, but I don't think "A in B < C" is an example of that scenario. As the others mentioned, I think the best solution to dealing with this type of syntax would be with a linter rather than directly preventing its usage. (resent because the CC address was incorrect) On Sun, Nov 17, 2019 at 6:01 AM Kyle Stanley wrote: > > Some people find this legal syntax confusing: > > > A in B < C > > I agree, that syntax definitely seems counter-intuitive. If it came up in > a code review, I would request a revision to "A in B and B < C". > > > I feel like most code reviews would not allow this kind of code to be > checked in, at least without a comment explaining what the code does. What > are the motivating reasons for allowing this syntax? Is there any > idiomatic code that uses it? > > I can't personally imagine any practical use case for the syntax that > couldn't be expressed differently in a way that's far more clear to > readers. But, I don't think this is so much of a case of us choosing to > *allow* the syntax, this seems to be more of a case where we don't > explicitly *prevent* the syntax (through raising a SyntaxError). > > From my experience, SyntaxError is raised primarily from clear mistakes > that are easy to make (particularly for those who are new to the language > or accidental typos) rather than simply syntax that is obscure, > impractical, and/or hard to understand. It's realistically impossible to > isolate every case of highly counter-intuitive usage of Python syntax, not > to mention the resources it takes to implement a SyntaxError for each of > them. > > To me, it seems that the usage of "A in B C" is > something that's not easy to do by accident, I can't imagine what someone > would be intending to practically accomplish and mistakenly end up with > that syntax, not knowing it could be expressed differently. A few important > questions to consider: > > 1) Is this syntax misused enough to justify implementing a SyntaxError? > > 2) Would raising a SyntaxError help to point those who misuse it in the > right direction? > > 3) Is it worth the resources it would take to implement the SyntaxError? > > 4) Does implementing the SyntaxError provide enough positive benefit to > justify breaking backwards compatibility? Even if it's very rarely used and > could be expressed differently, this still applies. > > > Also, in my opinion, the existence is a deterrent to Python and takes > away from Python's beauty as a language. > > I would have to disagree, every language has its obscure corner cases and >
[Python-ideas] Re: Consider blocking heterogeneous chained comparison
Hi Neil
I'm an amateur (unpaid) research mathematician. I find the syntax
>>> A in B < C
clear. And in some cases appropriate to use. Although I don't like the
choice of identifiers. Mathematicians usually use upper-case letters for
set, and lower-case letters for their elements.
Thus I prefer
>>> a in B < C
which in now clearer. And if
>>> A = {a}
then equivalently we have
>>> A < B < C
I agree with Chris, this sort of thing is better done using a linter.
That's how the gotcha
>>> def wibble(lst=[])
>>># do something with lst
>>>return lst
is detected.
Finally, when an expression such as
>>> a in B < C
I'd expect B to one of the variables being looped over (otherwise there's
invariant code that can be move outside the loop.
Thank you, Neil, for your interesting question. I don't doubt that some
people find
>>> A in B < C
confusing. Although there may be a problem to be solve here, I think making
it a syntax error is disproportionate. Perhaps you could find a more
focused solution.
--
Jonathan
___
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/NAMXXWYDVL5CLHHKNEMJ57NF33JTQQS4/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Consider blocking heterogeneous chained comparison
On Sun, Nov 17, 2019 at 12:43:55AM -0800, Neil Girdhar wrote: > Some people find this legal syntax confusing: > > A in B < C > > (It means A in B and B < C.) > > I feel like most code reviews would not allow this kind of code to be > checked in, at least without a comment explaining what the code does. What > are the motivating reasons for allowing this syntax? Is there any > idiomatic code that uses it? Programming languages permit lots of unidiomatic code that is allowed without there being a specific motivating reason for allowing it. I doubt that any of us would ask for a motivating reason to allow this: print(print(value) or print(another_value) or third_value) or expect there to be idiomatic code that includes this: if True is (((value is True) is (True is True) is True) is True) just because the language allows it. It is a never ending task to try to prevent any unidiomatic, ugly code at the language itself, especially since what counts as "ugly" is often so subjective. Generally, we need a better reason to prohibit something than just personal preference "I don't think you should write that code". Not all code is, or needs to be, best practice. I don't recall if I've ever chained operators similar to the example you have given, but I've written lots of code that *I* don't approve of, because if I'm experimenting in the REPL who cares if I write something idiomatic or not? It works, it does what I want, it doesn't matter if it is ugly or wouldn't survive a code review. What error message could you raise that wouldn't come across as sounding like HAL from 2001 scolding the coder? "I'm sorry Dave, I'm afraid I can't allow you to do that." Better to leave this to linters, style guides, code reviews and the individual good taste of the coder. > If not, I suggest dividing the comparison operators into two groups: [...] Still allowed: a > b < c a <= b >= c != a a in b is c is not a which are equally as hideous as your motivating example. This is adding a significant semantic complication to the language, without actually preventing what you set out to prevent: Aim: prevent the coder from abusing chained comparisons. Result: now there are two kinds of comparison operators which have nothing in common except an arbitrary division, but the coder can still abuse chained comparisons. > For example, > you might write your own comparison operator and then want to see if it's > working: > > A < B is None > > returns false if B is not None even if A < B returns None. "Suspiciously specific example." Did you do this? Ironically, this similarly awful code would be allowed under your "two groups" proposal: a in b is None since the `in` operator is in the same group as the `is` operator. So would these: a < b == None a < b == -1# using -1 instead of None as sentinel > Also, in my opinion, the existence is a deterrent to Python o_O Do you have evidence of actual, real people saying words to the effect of this? "I was going to use Python, but when I saw that you can abuse chained comparisons to write ugly code, I decided against it." > and takes away from Python's beauty as a language. *shrug* I don't know, I think that the cure in this case is worse than the disease. Yes, there are some ugly abuses of chained comparisons, but dividing comparison operators into two arbitrary groups seems even uglier to me. None is not a > b 0 != a > b I can't say that the language is improved by prohibiting the first but allowing the second. I think that the status quo has the beauty of simplicity: a b c => "a b and b c" for op1, op2 both comparison operators while your proposal has the ugliness of (unnecessary?) complexity: a b c => "a b and b c" for op1, op2 both "group 1 comparison operators", or op1, op2 both "group 2 comparison operators", or a syntax error for op1, op2 in different groups. -- Steven ___ 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/O6KLZBV3TWYMBIKGBIUSNIQI4SSFT45Y/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Consider blocking heterogeneous chained comparison
On Sun, Nov 17, 2019 at 7:45 PM Neil Girdhar wrote: > If not, I suggest dividing the comparison operators into two groups: > > in, not in, is, is not > > and > > <, >, <=, >=, ==, != > > and then disallowing chaining of operators from both groups. > > For example, still allowed: > > A <= B <= C > > A in B in C > > disallowed: > > A < B in C > And also allowed: A is B in C A in B is C I'm not sure these are any better than the ones you've chosen to disallow :) If you want to push for these to be disallowed, I would recommend doing it first in a linter or code quality tool. That's a completely safe way to try it out, with no language changes at all. Reject them automatically in code review, or even as a pre-commit/pre-push hook (or equivalent in your own source control system). If it's done at the syntactic level, there's absolutely no recourse, and any code anywhere that uses these chained comparisons will be suddenly broken. 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/UBQO6AD4PSB3FS42EZKNVC5IUQ3QGDN6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Consider blocking heterogeneous chained comparison
Neil Girdhar wrote: > Some people find this legal syntax confusing: > A in B < C > (It means A in B and B < C.) > I feel like most code reviews would not allow this kind of code to be > checked in, at least without a comment explaining what the code does. What > are the motivating reasons for allowing this syntax? Is there any > idiomatic code that uses it? > If not, I suggest dividing the comparison operators into two groups: > in, not in, is, is not > and > <, >, <=, >=, ==, != > and then disallowing chaining of operators from both groups. FWIW, I totally agree. Expressions like that are extremely confusing, and it is surprising that they are valid. Real-wold usage of those is more likely to be accidental than purposeful, so it would be better if they were disallowed and treated as syntax errors. -- Steve J. ___ 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/GV6BKGW4MRNCKEVL7R75JFD7KRALNJRH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Consider blocking heterogeneous chained comparison
Some people find this legal syntax confusing: A in B < C (It means A in B and B < C.) I feel like most code reviews would not allow this kind of code to be checked in, at least without a comment explaining what the code does. What are the motivating reasons for allowing this syntax? Is there any idiomatic code that uses it? If not, I suggest dividing the comparison operators into two groups: in, not in, is, is not and <, >, <=, >=, ==, != and then disallowing chaining of operators from both groups. For example, still allowed: A <= B <= C A in B in C disallowed: A < B in C The advantage of such a change is that there is fewer "gotcha" code. I admit that this code is rarely written, but it can come up. For example, you might write your own comparison operator and then want to see if it's working: A < B is None returns false if B is not None even if A < B returns None. Also, in my opinion, the existence is a deterrent to Python and takes away from Python's beauty as a language. The downside of such a change is that the language is more complicated. As far as implementation goes, this can be done after parsing when the AST is checked and errors are raised (from what I remember). Best, Neil ___ 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/S7NBNTIPUON2N6WGNBCJXBRVAJNFPNPS/ Code of Conduct: http://python.org/psf/codeofconduct/
