New submission from rurpy:
In the first example in the documentation for library module email.policy
(http://docs.python.org/3/library/email.policy.html#module-email.policy):
>>> from email import msg_from_binary_file
>>> from email.generator import BytesGenerator
&
rurpy added the comment:
Raymond Hettinger (rhettinger) msg177365:
> For some of the points, a couple examples will do a better job of explaining
> hex() that trying to write-out the full code specification in prose.
Examples should never substitute for a clear, complete and c
rurpy added the comment:
An ammendment to my proposed doc change.
Replace the text (which is unchanged from the current doc),
"...the result is a valid Python expression"
with,
"...the result is a valid Python "hexinteger" literal (see link:[Python Lang
Ref, se
New submission from rurpy:
Python Language Reference, chapter 6 "Expressions".
The last section (6.15) of this is titled, "Summary". That title is misleading
-- it is not really a summary of the "Expressions" chapter but rather, as the
first sentence ma
rurpy added the comment:
I would like to submit the following post made to c.l.p in support of my claim
that a cross-reference to the string formatting "x" format specifier would be
desireable in the documentation for the hex() builtin:
Newsgroups: comp.lang.python
Subject: Re:
New submission from rurpy:
In the current (3.3.3 and 3.4dev) Language Reference Manual, the section on the
Raise statement fails to mention that the second expression can be None (per
PEP-409/415) or the special behavior (suppressing a chained exception) that
ensues. Rather it explicitly
New submission from rurpy the second :
The Python HOWTOs->Idioms and Anti-Idioms has a section
"Using Backslash to Continue Statements".
It says that line continuation is "dangerous" and gives two reasons.
1. Hard to see a space after the backslash.
This is not &qu
rurpy the second added the comment:
I find the changes suggested by T Reedy and refined in the
patch by E Bendersky an improvement. However, I found the
following things confused me when reading it:
"...constructor creates a function..."
the constructor creates a Timeit insta
New submission from rurpy the second :
PEP 414 proposes restoring the "u" string prefix (semantically as a "noop") to
make porting from Python2 easier. I would like to propose that "ru"-strings
also interpret embedded "\u" unicode literals in t
Changes by rurpy the second :
--
nosy: +rurpy2
___
Python tracker
<http://bugs.python.org/issue15216>
___
___
Python-bugs-list mailing list
Unsubscribe:
rurpy the second added the comment:
This continues to be a problem on Python-3.3.0
--
nosy: +rurpy2
versions: +Python 3.3 -Python 3.2
___
Python tracker
<http://bugs.python.org/issue16
rurpy the second added the comment:
I happened upon this issue while Googling for a formatter with the behavior
described here.
I put together a formatter derived from the code submitted by GraylinKim
(2011-08-22) and offer it for consideration (though it is missing some things
like
rurpy the second added the comment:
Additional comment loosely related to the ParagraphFormatter offered in
previous comment...
[If this is not the right venue -- perhaps a new issue or one of the python
mail lists would be better -- please tell me.]
I notice that argparse.ArgumentParser
New submission from rurpy the second:
The documentation of the hex() builtin function is poor. Specifically it does
not say (directly) that:
1. The resulting string is prefixed with "0x".
2. Any a-f characters used are lower case.
3. Negative integers are converted by prefixing a
14 matches
Mail list logo
