On Sat, 06 Jul 2013 10:25:19 +0200, ronald.oussoren <python-checkins(a)python.org> wrote:
> changeset: 84453:a2c2ffa1a41c
> branch: 3.3
> parent: 84449:df79735b21c1
> user: Ronald Oussoren <ronaldoussoren(a)mac.com>
> date: Sat Jul 06 10:23:59 2013 +0200
> Issue #17860: explicitly mention that std* streams are opened in binary mode by default.
> The documentation does mention that the streams are opened in text mode
> when univeral_newlines is true, but not that that they are opened in
> binary mode when that argument is false and that seems to confuse at
> least some users.
> Doc/library/subprocess.rst | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
> diff --git a/Doc/library/subprocess.rst b/Doc/library/subprocess.rst
> --- a/Doc/library/subprocess.rst
> +++ b/Doc/library/subprocess.rst
> @@ -293,7 +293,8 @@
> If *universal_newlines* is ``True``, the file objects *stdin*, *stdout* and
> *stderr* will be opened as text streams in :term:`universal newlines` mode
> using the encoding returned by :func:`locale.getpreferredencoding(False)
> - <locale.getpreferredencoding>`. For *stdin*, line ending characters
> + <locale.getpreferredencoding>`, otherwise these streams will be opened
> + as binary streams. For *stdin*, line ending characters
> ``'\n'`` in the input will be converted to the default line separator
> :data:`os.linesep`. For *stdout* and *stderr*, all line endings in the
> output will be converted to ``'\n'``. For more information see the
IMO, either the default should be mentioned first, or the default
should be mentioned in a parenthetical. Otherwise it sounds like
newline translation is being done in both modes. Logically that makes
no sense, so the above construction will likely lead to, at a minimum,
an interruption in the flow for the reader, and at worse even more
confusion than not mentioning it at all.
I'd like to bring your attention to this issue, since it touches the
fundamentals of python's import workflow:
/I've tried to post it on the python-import ML for weeks, but it must
still be blocked somewhere in a moderation queue, so here I come ^^/
TLDR version: because of the way import current works, if importing a
package "temporarily" fails whereas importing one of its children
succeeded, we reach an unusable state, all subsequent attempts at
importing that package will fail if a "from...import" is used somewhere.
Typically, it makes a web worker broken, even though the typical
behaviour of such process woudl be to retry loading, again and again,
the failing view.
I agree that a module loading should be, as much as possible, "side
effects free", and thus shouldn't have temporary errors. But well, in
practice, module loading is typically the time where process-wide
initialization are done (modifying sys.path, os.environ, instantiating
connection or thread pools, registering atexit handler, starting
maintenance threads...), so that case has chances to happen at a moment
or another, especially if accesses to filesystem or network (SQL...) are
done at module loading, due to the lack of initialization system at
That's why I propose modifying the behaviour of module import, so that
submodules are deleted as well when a parent module import fails. True,
it means they will be reloaded as well when importing the parent will
start again, but anyway we already have a "double execution" problem
with the reloading of the parent module, so it shouldn't make a big
The only other solution I'd see would be to SYSTEMATICALLY perform name
(re)binding when processing a from...import statement, to recover from
the previously failed initialization. Dunno if it's a good idea.
On a (separate but related) topic, to be safer on module reimports or
reloadings, it could be interesting to add some "idempotency" to common
initialization tasks ; for example the "atexit" registration system,
wouldn't it be worth adding a boolean flag to explicitely skip
registration if a callable with same fully qualified name is already
Do you have opinions on these subjects ?
I wrote my own assembler for Python bytecode called "Maynard". I had to
statically compute the stack effects for each bytecode instruction by
hand; what I did was copied and pasted opcode_stack_effect() (which is
static) out of Python/compile.c and into my own driver program, then I
probed it with test values to produce a table. I then coded up a
function using that table, but hand-calculating the value sometimes as
there are some opcodes whose stack effect varies based on the oparg.
It sure would be nice if this information was simply available to the
Python interpreter; theoretically it can change between point releases.
Would anybody mind if I added it somewhere? I'd probably just expose
opcode_stack_effect to Python, then add all this other junk to the dis
module and make it available there.
I'm not sure how my change broke the buildbots, but apparently it did. I
need to run to a meeting now, but I can roll this back in the next few
If someone else wants to roll it back before I get to it, feel free.
Sorry about the problem. I tested it locally, I'm not sure how the
buildbots are affected.
I'm trying to understand how CPython implements closure variable capture
and there is one minor point I can't understand.
When a local is captured it gets allocated in co_cellvars and is accessed
with (LOAD|STORE)_DEREF, and this is clear.
However when a local is coming from a parameter it gets ALSO allocated in
co_varnames even if the local slot apparently is not accesible because
*_FAST opcodes are not generated.
Is there a technical reason for this? It happens in CPython 2, 3 and even
One month ago, unit tests were added to IDLE (cool!) with a file
called @README.txt. The @ was used to see the name on top in a listing
of the directory.
Some developers began to get strange Mercurial errors like:
"abort: data/Lib/idlelib/idle_test/(a)README.txt.i at 7573717b9e6f: no match"
" 83941: empty or missing Lib/idlelib/idle_test/(a)README.txt "
Senthil reported the issue on python-committers mailing list:
The @ character was discussed. Replacing it with "_" was proposed.
Guido asked to simply rename the name "README.txt", he wrote:
"I think we have a zen rule about this: Special cases aren't special
enough to break the rules."
Senthil was asked to upgrade its Mercurial version. Someone supposed
that it is a disk issue. Anyway, the issue disappeared with a fresh
I also had the issue on 3 different computers, and so I reported the
I discussed with a Mercurial developer, Matt, on IRC. He asked how the
server is managed, if we are using only one physical server, if
repositories are copied with rsync, etc. I was unable to answer, I
don't have access to hg.python.org server.
The issue was closed, but 20 days later (today) I reproduced the issue again.
I cloned the repository at a specific revision, tried to update to
another specific revision: no bug.
I also played with with hg bisect, because I suspected a bug in bisect: no bug.
I tried to update at each revision between 83900 and 84348 to check if
@README.txt disappears from .hg/store: still no bug.
I also ran fsck: no error (but the disk is mounted, so I don't know if
the report is reliable).
And then I ran "make distclean"...