David Abrahams wrote:
Yes, and that becomes important in programs that have constructors.
I.e., C++ programs. The Python executable is not such a program,
except for one C++ file: ccpython.cc.
That is not true. ccpython was introduced to support builds of
the Python interpreter where some
On 7/6/05, Nick Coghlan [EMAIL PROTECTED] wrote:
However, while I prefer what you describe to Python's current
behaviour, I am not yet convinced the backward compatibility pain is
worth it. Adding yet-another-kind-of-string-literal (when we already
have bytestrings on the horizon) is also
On 7/7/05, Guido van Rossum [EMAIL PROTECTED] wrote:
I don't think so. It smells too much of DWIM, which is very unpythonic. EIBTI.
In what way? The scheme described is explicit, and consistently
applied to all triple-quoted strings[*] -- although the rules are
different to the current
On 7/7/05, Terry Reedy [EMAIL PROTECTED] wrote:
I believe there were some current alternatives and concerns already
expressed that have not been included yet that maybe should be.
Yes; Nick pointed me to one, and I'll be looking at that and the
related discussions before redrafting; I'll also
Guido van Rossum wrote:
On 7/5/05, Andrew Durdin [EMAIL PROTECTED] wrote:
I have written a patch that changes the way triple-quoted strings are
scanned so that leading whitespace is ignored in much the same way
that pep 257 handles it for docstrings. Largely this was for a
learning experience
Martin v. Löwis [EMAIL PROTECTED] writes:
I don't believe any systems require it. I realize you have said
otherwise, but after years of working with Boost.Python I'm very
familiar with the issues of dynamic linking and C/C++ interoperability
on a wide variety of platforms, and I'm not
On 7/10/05, David Abrahams [EMAIL PROTECTED] wrote:
Martin v. Löwis [EMAIL PROTECTED] writes:
I well remember that gcc 2.5.8 on Linux a.out required this sort of
setup.
Sorry, a.out? Isn't that the default name a C compiler gives to the
executable it builds on Unix? Is it also (part of)
Martin v. Löwis [EMAIL PROTECTED] writes:
David Abrahams wrote:
Not entirely. By extending Modules/Setup
You mean
http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Modules/Setup.dist?view=markup
?
I mean Modules/Setup. It is generated from Modules/Setup.dist
(plus some
Christoph Ludwig [EMAIL PROTECTED] writes:
--with-cxx=compiler: If you plan to use C++ extension modules, then on some
platform you need to compile python's main() function with the C++
compiler. With this option, make will use compiler to compile main()
*and* to link
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 then the user is left with a linker error that is
time-consuming to
--- David Abrahams [EMAIL PROTECTED] 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 then the user is left
Andrew Durdin [EMAIL PROTECTED] wrote:
On 7/7/05, Guido van Rossum [EMAIL PROTECTED] wrote:
I don't think so. It smells too much of DWIM, which is very unpythonic.
EIBTI.
In what way? The scheme described is explicit, and consistently
applied to all triple-quoted strings[*] --
Christoph Ludwig wrote:
My point is: The test implemented in the 2.4.1 configure script gives a wrong
result if your platform happens to be x86 Linux with ELF binaries and
g++ 4.0.
Point well taken.
It is only recent changes to g++ that break the test, namely the
introduction of this
David Abrahams wrote:
I well remember that gcc 2.5.8 on Linux a.out required this sort of
setup.
Sorry, a.out? Isn't that the default name a C compiler gives to the
executable it builds on Unix? Is it also (part of) the name of an OS?
Yes, and somewhat. It is also the name of a binary
David Abrahams wrote:
- we add a configure test that runs after the existing test
determines that --with-cxx is needed (but not when --with-cxx is
explicitly specified on the command line)
- This test runs a 'C' executable that tries to load a C++ dynamic
library with
On 7/10/05, Andrew Durdin [EMAIL PROTECTED] wrote:
On 7/7/05, Guido van Rossum [EMAIL PROTECTED] wrote:
I don't think so. It smells too much of DWIM, which is very unpythonic.
EIBTI.
In what way? The scheme described is explicit, and consistently
applied to all triple-quoted strings[*]
Martin v. Löwis [EMAIL PROTECTED] writes:
David Abrahams wrote:
- we add a configure test that runs after the existing test
determines that --with-cxx is needed (but not when --with-cxx is
explicitly specified on the command line)
- This test runs a 'C' executable that tries to
On 7/11/05, Josiah Carlson [EMAIL PROTECTED] wrote:
You are wrong. Current string literals are explicit. They are what you
type.
No they are not:
I typed \x41, but got this!
'I typed A, but got this!'
What we have are not explicit string literals but *explicit rules*,
forming part
Andrew Durdin [EMAIL PROTECTED] wrote:
On 7/11/05, Josiah Carlson [EMAIL PROTECTED] wrote:
You are wrong. Current string literals are explicit. They are what you
type.
No they are not:
Apparently my disclaimer of except in the case of the decades-old
string escapes that were
On Jul 10, 2005, at 6:39 PM, Josiah Carlson wrote:
Andrew Durdin [EMAIL PROTECTED] wrote:
On 7/11/05, Josiah Carlson [EMAIL PROTECTED] wrote:
You are wrong. Current string literals are explicit. They are
what you
type.
No they are not:
Apparently my disclaimer of except in
Andrew Durdin [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Very likely. But given the number of times that similar proposals have
been put forth in the past, it is reasonable to expect that they will
be brought up again in the future by others, if this is rejected--and
in that
21 matches
Mail list logo
