Georg Brandl wrote:
>Guido van Rossum wrote:
>
>
>>Backticks certainly are deprecated -- Py3k won't have them (nor will
>>they become available for other syntax; they are undesirable
>>characters due to font issues and the tendency of word processing
>>tools to generate backticks in certain case
Guido van Rossum wrote:
> Backticks certainly are deprecated -- Py3k won't have them (nor will
> they become available for other syntax; they are undesirable
> characters due to font issues and the tendency of word processing
> tools to generate backticks in certain cases where you type forward
> t
Backticks certainly are deprecated -- Py3k won't have them (nor will
they become available for other syntax; they are undesirable
characters due to font issues and the tendency of word processing
tools to generate backticks in certain cases where you type forward
ticks).
So it would be a good idea
Fredrik Lundh wrote:
> for some reason, the language reference uses the term "string con-
> version" for the backtick form of "repr":
>
> http://docs.python.org/ref/string-conversions.html
>
> any suggestions for a better term ? should backticks be deprecated,
> and documented in terms of re
Fredrik Lundh wrote:
> for some reason, the language reference uses the term "string con-
> version" for the backtick form of "repr":
>
The language reference also says that trailing commas for expressions
work with backticks. This is incorrect. I think this is necessary to
allow nested 'strin
for some reason, the language reference uses the term "string con-
version" for the backtick form of "repr":
http://docs.python.org/ref/string-conversions.html
any suggestions for a better term ? should backticks be deprecated,
and documented in terms of repr (rather than the other way aroun
