IIRC, there was a decision to not implement phase C and to keep the
trailing L in representations of long integers.
If so, I believe the PEP can be marked as final. We've done all we're
going to do.
raymond> Log Message:
raymond> Brett requests that Flovis's permissions be dropped.
Not to put too fine a spin on things, but I think it was more like Brett got
tired of waiting for Flovis's permissions to be increased and retracted his
Floris is working on wrapping Hotshot to replace 'profile' and
replacing pstats so that there will be no more need for 'profile' and
thus take care of the licensing problem. He also hopes to make pstats
faster to use. And if we are really lucky, get threading working for
It would be great to give him CVS access so he can work in nondist.
His username is sirolf . He knows he is not to touch anything outside
of his directory in nondist.
Apparently Python on some linux distros is being linked by g++ rather
than gcc, resulting in the C++ runtime library being linked into
Python; this has bad consequences for compatibility between C++
extension modules and Pythons that have been built with different
versions of GCC. Is this behavior intentional?
James Y Knight writes:
> It is a really bad idea to codify the practice of modifying non-
> threadlocal global state like sys.std[in|out|err] and current
> directory with a context manager.
Barry Warsaw responds:
> Thinking about the types of code I write over and over again, I think I
> disagree (slightly) with James about the global state thing. While I
> agree that 'with redirected_stdio' isn't too useful in the face of
> print>>, I very often have to write try/finally protections around
> temporary settings of the cwd, the umask, and other global process
> values. I'd love to see cm's for those constructs in the stdlib.
I agree with Barry. Not only should they be in the stdlib, but they
should have very clear warnings in their docstrings and other documentation
that state that they are ONLY safe to use in single-threaded programs.
This achieves two things: it makes them available to those who need
them (not everyone uses threads!), and it rather forcefully makes the
point that it's NOT usually a good idea to modify global state info in
a context manager because doing so is not generally threadsafe.
-- Michael Chermside
Probably late in the game, esp. for an outsider, but I read the
terminology discussion with interest.
FWIW, I do like Philip's use of context, though I feel that it is a
very generic word that may clash with many application-level
classes... For that reason, I also liked "scope" a lot, though it was
an... expension of that term's usual meaning beyond namespaces.
Anyway, what really struck me all along is that, when reading the
keyword "with", I always felt that I would replace it with "within",
which imho fits the context/scope terminology better. Thus "within" a
"context", we do certain actions... which are fenced with
__begincontext and __endcontext.
(Oh, yes, fences... What was the original precise computer science
meaning of that word, again?)
M A Lemburg writes:
> we should use strings and Unicode
> like they are supposed to be used (in the context of text
> * strings are fine for text data that is encoded using
> the default encoding
> * Unicode should be used for all text data that is not
> or cannot be encoded in the default encoding
> Later on in Py3k, all text data should be stored in Unicode
> and all binary data in some new binary type.
Wow. That is the most succinct and clear explanation of how to
use unicode in Python that I think I've ever heard. It might
even be simple enough for _me_ to understand it! I think I'm
going to go frame this and have it posted in my cubical.
-- Michael Chermside
> I agree with Barry. Not only should they be in the stdlib, but they
> should have very clear warnings in their docstrings and other documentation
> that state that they are ONLY safe to use in single-threaded programs.
> This achieves two things: it makes them available to those who need
> them (not everyone uses threads!), and it rather forcefully makes the
> point that it's NOT usually a good idea to modify global state info in
> a context manager because doing so is not generally threadsafe.
Nick Coghlan replies:
> Wouldn't they be able to actually emit a warning at run-time if they're used
> in a multi-threaded program? That would be even better motivation for
> including them, IMO.
I don't think that would be desirable. These things CAN be useful in a
multi-threaded program if you know what you're doing. One common example
would be to use them only from the main thread.
-- Michael Chermside