David Abrahams wrote:
- ccpython.cc and linking with g++ is removed entirely. or,
That would be bad for C++ users on HP/UX. Is that acceptable?
I hadn't read that far in the threads when I wrote this - I
guess the answer is no, and we must continue to support ccpython.cc.
- the logic is
Bob Ippolito wrote:
A better proposal would probably be another string prefix that means
dedent, but I'm still not sold. doc processing software is clearly
going to have to know how to dedent anyway in order to support
existing code.
Agreed.
It is easy enough for any doc-string
I surely find them useful, and see them as a Python originality (a
welcome one).
They are indeed an original invention. (One day I looked at the
similarity between if and while and noticed that there was a use case
for else after while too.)
The question remains whether Python would be
Florent Pillet [EMAIL PROTECTED] writes:
On 07/07/05, Michael Hudson [EMAIL PROTECTED] wrote:
But with my threaded Python code, SIGINT doesn't work anymore after my
binding has called tmpfile().
Oh, threads.
Which version of Python are you using?
2.3.5, the one that ships with Mac
On Monday 11 July 2005 19:32, Michael Hudson wrote:
Well, again assuming my guess is right, it's probably an OS X bug, but
really threads vs signals issues are enormously subtle and frequently
messed up.
I think mwh meant to say threads vs signals is a platform-dependant
trail of misery,
Skip Montanaro [EMAIL PROTECTED] writes:
Ummm... What's a context manager?
Something that goes
with ... as var:
^ here
If you have a better name, feel free to suggest it, but please catch
up on python-dev first (it's been discussed to unconsciousness, if not
quite death, in the last
Martin v. Löwis [EMAIL PROTECTED] writes:
However, you will find that with a), people will still pass --with-cxx,
because they tend to enable all features they can find.
--with-fpectl, for example. Does anyone lurking here actually use
that, know what it does and require the functionality?
On Mon, 2005-07-11 at 01:08, Bob Ippolito wrote:
A better proposal would probably be another string prefix that means
dedent, but I'm still not sold. doc processing software is clearly
going to have to know how to dedent anyway in order to support
existing code.
OTOH, adding another
Martin v. Löwis [EMAIL PROTECTED] writes:
- the logic is fixed so that linking with g++ is only done if
main is in ccpython.o
I don't see how that works. Somehow we need to decide whether to put
main in ccpython.o in the first place, don't we?
Yes, that is done through --with-cxx
Guido van Rossum:
In some sense the safest approach from this POV would be to return
Unicode as soon as it can't be encoded using the global default
encoding. IOW normally this would return Unicode for all names
containing non-ASCII characters.
On unicode versions of Windows, for
Ummm... What's a context manager?
Michael Something that goes
Michael with ... as var:
Michael ^ here
Michael If you have a better name, feel free to suggest it, but please
Michael catch up on python-dev first (it's been discussed to
Michael unconsciousness,
Neil Hodgson wrote:
On unicode versions of Windows, for attributes like os.listdir,
os.getcwd, sys.argv, and os.environ, which can usefully return unicode
strings, there are 4 options I see:
1) Always return unicode. This is the option I'd be happiest to use,
myself, but expect this
I'm in full agreement with Marc-Andre below, except I don't like (1)
at all -- having used other APIs that always return Unicode (like the
Python XML parsers) it bothers me to get Unicode for no reason at all.
OTOH I think Python 3.0 should be using a Unicode model closer to
Java's.
On 7/11/05,
On 7/8/05, James Y Knight [EMAIL PROTECTED] wrote:
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. A user can do it to themselves now,
true, but by putting a context manager for it
I wrote:
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
On Sun, Jul 10, 2005 at 09:45:25AM +0200, Martin v. Löwis wrote:
Christoph Ludwig wrote:
I'll describe it once more: *If* a program is compiled with the C++
compiler, is it *then* possible to still link it with the C compiler?
This is the question this test tries to answer.
The keyword
On Sun, Jul 10, 2005 at 09:35:33AM -0400, David Abrahams wrote:
Christoph Ludwig [EMAIL PROTECTED] writes:
I do not claim the 2 TUs test will cover all possible scenarios. I am not
even
sure this decision should be left to an automated test. Because if the test
breaks for some reason
Christoph Ludwig wrote:
Yes, but on ELF/Linux the default configuration should be --without-cxx
in the first place. If the build instructions make it sufficiently clear that
you should prefer this configuration whenever possible then this should be a
non-issue on platforms like ELF/Linux.
[Michael Hudson]
--with-fpectl, for example. Does anyone lurking here actually use
that, know what it does and require the functionality? Inquiring
minds want to know.
I know what it intends to do: fpectlmodule.c intends to enable the HW
FPU divide-by-0, overflow, and invalid operation
Martin v. Löwis [EMAIL PROTECTED] writes:
David Abrahams wrote:
I don't see how that works. Somehow we need to decide whether to put
main in ccpython.o in the first place, don't we?
You wouldn't have to ask these questions if you had investigated the
answers yourself.
The questions should
Patch / Bug Summary
___
Patches : 349 open ( +1) / 2880 closed ( +1) / 3229 total ( +2)
Bugs: 897 open ( -1) / 5119 closed (+16) / 6016 total (+15)
RFE : 194 open ( +1) / 170 closed ( +0) / 364 total ( +1)
New / Reopened Patches
__
PEP 343
21 matches
Mail list logo
