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
Terry Reedy wrote:
> "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 t
"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
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:
>>
>
> Appar
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 th
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*,
for
"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
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-quot
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 d
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 bi
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
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 stri
--- 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 u
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
Christoph Ludwig <[EMAIL PROTECTED]> writes:
> --with-cxx=: 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 to compile main()
> *and* to link the python
"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.d
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 a
"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
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
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
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 beha
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 a
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 OS X 10.4. I have a 2.4.x install
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 here is "tries"
Any such test would only "try": to really dete
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 additional information) in the build proces
David Abrahams 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.
>
>
> Okay, I understand that. What I have never understood is why that
> should b
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
27 matches
Mail list logo
