Hi All,
Apologies if this has already been discussed to death.
Python 3 allows Unicode characters in strings and identifiers but the actual quotation marks are only accepted in plain ASCII, i.e. the following all successfully initialise strings:
```
S1 = "Double Quoted" # Opened and closed with chr(34)0x22
S2 = 'Single Quoted' # Opened and closed with chr(39)0x27
```
But the following all result in an error - "SyntaxError: invalid character in identifier":
```
S1 = "Double Quoted" # Opened with \u201c and closed with \u201d
S2 = 'Single Quoted' # Opened with \u2018 and closed with \u2019
```
To the experienced eye, and depending on the character font used, it is "obvious" what the problem is! The wrong quotation marks were used. The big problem, especially for beginners, is that the same keys were typed, just in the "wrong" editor or even the wrong editor mode or context I have found that in Outlook if the font is FixSys or I am replying to a plain text email it is fine but otherwise it is "helpful" - unfortunately, especially on Windows, "wrong" editors abound and include, but are not limited to, MS-Outlook, MS-Word, some online editing environments such as Quora.
On top of that is the helpful substitution of a m-hyphen for minus when you press space a word later so:
A = 3 - 2 # With a space syntax error due to \u2013
A = 3 - 2 # No Space or CR after I last typed it is OK as 0x2d
Use cases that catch people out:
1. Sending a code snipped by email using Outlook
2. User manuals written in MS-Word - (many peoples work environment)
3. Articles published on Quora - people expect to be able to copy and paste the code for some reason.
I am sure that many us have encountered these issues or similar.
What can be done?
1. Persuade Microsoft, and others, to stop being so helpful by default - good luck with that!
2. Tell all users that they need to use a "proper" editor or IDE - This seems like adding an additional barrier to new & casual users.
3. Better yet tell them to use a "proper" OS like .... - At the very least many of us have to use Windows at work.
4. Start accepting hyphens as minus & Unicode quotation marks - this would be the ideal answer for pasted code but has a lot of possible things to iron out such as do we require that the quotes match and are in the typographically correct order. It is also quite a big & complex change to the python interpreter.
5. Normalise the input to the python interpreter (at least for these characters and possibly a few others) so that entering or reading from a file S1 = "Double Quoted" becomes S1 = "Double Quoted", etc. - this should be a easier change to the interpreter but, from a purist point of view, could be said to make us as bad as the others because we are not honouring what the user entered.
6. Change the error message "SyntaxError: invalid character in identifier" to include which character and it's Unicode value so that it becomes "SyntaxError: invalid character 0x201c " in identifier" - this is almost certainly the easiest change and fits well with explicit is better than implicit but still leaves it to the user to correct the erroneous input (which could be argued is both good and bad).
I would like to suggest that an incremental approach might be the best - clarifying the existing error message being the thing that should not break anything and either substituting for problem characters or processing them "properly" as a later enhancement.
Steve Barnes
Hi Rob
You wrote:
So: You're asking that the bytecode generated for the for-loop depends
> on something that happens (or not) after the end of the for-loop body
> (which could be arbitrarily long).
>
> I speak from ignorance, but I suspect that even with the new parser,
> which I am reliably informed can make the tea and implement world peace,
> that would be asking a lot.
>
I'm also speaking from ignorance. However, here I'm the optimist. Ignorance
is bliss. You're the pessimist. The devil is in the details.
Until we have knowledge and wisdom on this, I think we need both points of
view. So I'm grateful for your
https://en.wikipedia.org/wiki/Grain_of_salt (American
English, pinch of salt in British English). I hope it makes my dish taste
better!
--
Jonathan
Hey all,
What are thoughts about implementing an object-compare function in the
unittest package? (Compare two objects recursively, attribute by
attribute.) This seems like a common use case in many testing scenarios,
and there are many 3rd party solutions solving the same problem. (Maybe we
can promote standardization by implementing it in the standard library?)
Apologies ahead of time if this idea has already been proposed; I was not
able to find similar posts in the archive.
Best,
-Henry
Hello,
The idea here is to use the same operator already used to type-hint the
return of functions `->` to define the return of a Callable.
* Current syntax:
Callable[[ArgumentList], ReturnType]
eg.
def x(method: Callable[[int, dict], None]) -> None:
pass
* Proposed syntax:
Callable[ArgumentList] -> ReturnType
eg.
def x(method: Callable[int, dict] -> None) -> None:
pass
Do you think this is more intuitive? Is it viable?
Kind regards,
Thiago
Thank you Rob, for your contribution. I find it very helpful. You've raised
important implementation questions.
Regarding the no-iterations case. Suppose we have
for i in items:
loop_body
case:
zero:
print('no items to process')
In this case, the Python compiler knows that the post-iteration block
contains a 'zero:' statement. And in other cases it knows that it does not.
So why not have the compiler produce bytecode that records this fact. (This
could be done by providing an additional bytecode, or if there's room
adding a flag to an existing bytecode.)
Depending on how we choose to implement, if we wish we could keep both the
bytecode and interpreter code exactly the same, for the currently allowed
post-iteration blocks.
I apologize that it wasn't clear to you from my example code, that for
example we allow any identifier as the 'label argument' in a break
statement. As in
break error_1
break error_2
break time_out
The compiler can and I think should ensure that all labels in the
post-iteration block occur in the iteration block. And a code analysis code
aka linter should warn about unreachable code. This unreachable code
should, of course, not generate any bytecode.
Thank you again for your comment. I hope this helps.
--
Jonathan
Hello!
According to PEP8, there should be 2 blank lines before the function definition. But,
I think in case of defining new typing.TypeVar, that will be used only in one function
definition, it would be better to put it right before the function definition, i.e. with no
blank lines. So I suggest to update PEP8, so it'd recommend skipping blank lines in this
case.
Thank you for your attention and sorry for my bad English.
Sincerely yours,
Nikita Serba.
Hello, I'd like to bring to your attention https://bugs.python.org/issue41383. The core idea here is per Elizaveta Shashkova:
I would like to have a lazy repr evaluation for the objects! Sometimes users have many really large objects, and when debugger is trying to show them in Variables View (=show their string representation) it can takes a lot of time. We do some tricks, but they not always work. It would be really-really cool to have parameter in repr, which defines max number of symbols we want to evaluate during repr for this object.
Maybe repr is not the best here, because that should be interpreter meaningful, but instead the __str__ method that's better for this. Maybe we could pass in an optional limit argument to these methods, so that the user can decide what to print depending on how many characters he has left?
Any takes, better ideas how we could help this problem?
Thanks,
Bernat
ELSE-clause in FOR and WHILE has unclear syntax. I suggest new clause instead:
if COND:
...
[elif COND:
...]
[else:
...]
This IF-clause like must be immediately after FOR- or WHILE-cycle (only comment allowed between). It looks like a regular IF, but COND is special.
COND may be "break", "pass" or "finally". "if break:" - if used break-operator to exit cycle. "if pass:" - cycle executed 0 times. "if finally:" - cycle executed 0 or more times ("pass-case" is included in "finally-case"). For compatibility only "else:" means "if finally:".
It's compatible enhancement. No new keyword. There can be no combination "break", "pass" or "finally" after "if"/"elif:" in current version.
-----------------
This idea was suggested as enhancement issue (https://bugs.python.org/issue41272).
Eric V. Smith (eric.smith) advised me to put this on the python-ideas mailing list (https://bugs.python.org/issue41272#msg373486).
Right now in str.format(), we have !s, !r, and !a to allow us to call str(), repr(), and ascii() respectively on the given expression.
I'm proposing that we add a !p conversion to have pprint.pformat() be called to convert the given expression to a 'pretty' string.
Calling
```
print(f"My dict: {d!p}")
```
is a lot more concise than:
```
import pprint
print(f"My dict: {pprint.pformat(d)}")
```
We may even be able to have a static attribute stored to change the various default kwargs of pprint.pformat().
