Re: [Python-Dev] Linux Python linking with G++?
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 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 (alone). However, the decision to use CXX for linking is independent on whether --with-cxx was given. - the configure test is extended to better match current g++ behaviour. What do you have in mind? Somebody reported that the test works better for g++ if the function is marked extern C. This should be done for 2.4 regardless of any other change. I just checked, and it seems that the logic in use is still somewhat different. If the configure test determines that a C++ main() must be linked with CXX, it unconditionally changes the linker to CXX. The test, in turn, is run always if a C++ compiler was found, i.e. independently of whether --with-cxx was provided. That doesn't match up with reports from my testers who say they can run with C++ extension modules from many different GCC versions if they just configure their Python --without-cxx. If what you were saying were true, wouldn't --without-cxx be ignored on ELF/Linux? Ok, it's still different. I see three cases now: 1. --without-cxx or --with-cxx=no specified. configure does not look for a C++ compiler, and does not check whether linking needs to be done with a C++ compiler, and decides to use Modules/python.c. 2. --with-cxx not given. configure does look for a C++ compiler, and does check whether linking with the C++ compiler is necessary, and still uses Modules/python.c 3. --with-cxx is given. configure requires it to point to a C++ compiler, performs the linking check, and uses Modules/ccpython.cc. It would help discussion if you would use the actual code, too, instead of just using reports from your testers. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Triple-quoted strings and indentation
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 extraction tool to do the dedenting based on the common whitespace prefix found in lines 2 - n of the string. And that works on all sorts of string literals. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 11 2005) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Chaining try statements: eltry?
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 easier to learn without them. And if so, the question would remain whether that's offset by their utility for experienced developers. All hard to assess impartially! I dislike them because I can never read looping constructs with else: without thinking hard about what it does. Like: for x in alist: if x == foo: break else: print foo was not found. Is a better way of doing: found = False for x in alist: if x == foo: found = True break if not found: print foo was not found. So the else: is taken if the break wasn't executed. I think that is hard to grasp because it makes the for and break into a kind of conditional statement where break makes it evalute to true. But I think the best way to code this silly example is to write: def finder(): for x in alist: if x == foo: return True return False if not finder(): print foo was not found. Which is how I write when someone else might had used a else. So IMHO, the use cases are weak. It's also confusing that try: has a different kind of else. else in try is a good thing - no exception occured. else in a for/while is (usually) a bad thing - as item was not found. -- mvh Björn ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C bindings calling tmpfile() blocks interrupt signal
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 OS X 10.4. I have a 2.4.x install somewhere, I'll give it a go. Please do. If my guess as to what's going on is right, you won't have the problem. But you're right, it's probably because of threads. You *may* be able to work around this by only calling tmpfile on the main thread (just a guess). Now I'm trying to determine whether this is a Python bug or a Mac OS X bug... 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. Python 2.4 is much less vulnerable to such cock ups. Cheers, mwh -- we're already scrubbing the face of intuition with steel wool, setting it on fire, then putting it out with an axe wink. -- Tim Peters, on comparing recursive structures ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C bindings calling tmpfile() blocks interrupt signal
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, despair, horror and madness. Python 2.4 is much less vulnerable to such cock ups. Note that the underlying platform issues are still there, it's just that Python itself is much less likely to lose on these issues. This is also probably only true for mainstream operating systems - for the more niche ones like HP/UX or Irix, there's quite probably still issues hanging around. These are unlikely to get fixed unless someone who cares about these platforms is willing to spend a lot of time working on it. At one point, I was spending some time on this (using the DEC^WCompaq^WHP testdrive systems), but I stopped caring about them quite a while ago now. Too much pain, for zero gain for me. -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible context managers in stdlib
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 week or so). Cheers, mwh -- dash i am trying to get Asterisk to work dash it is stabbing me in the face dreid yes ... i seem to recall that feature in the documentation -- from Twisted.Quotes ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linux Python linking with G++?
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? Inquiring minds want to know. Cheers, mwh -- I think perhaps we should have electoral collages and construct our representatives entirely of little bits of cloth and papier mache. -- Owen Dunn, ucam.chat, from his review of the year ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Triple-quoted strings and indentation
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 string prefix means doubling the total number of prefix combinations. The potential for this getting out of hand was the primary reason that string templates were implemented as a library function instead of as a string prefix. Personally, I'm not convinced that string literals need to change in any way. Dedentation should be handled (is handled?!) in the stdlib. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linux Python linking with G++?
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 (alone). However, the decision to use CXX for linking is independent on whether --with-cxx was given. Is the above a description of existing behavior or a behavior you're proposing? - the configure test is extended to better match current g++ behaviour. What do you have in mind? Somebody reported that the test works better for g++ if the function is marked extern C. Which function? What does works better mean? This should be done for 2.4 regardless of any other change. I just checked, and it seems that the logic in use is still somewhat different. If the configure test determines that a C++ main() must be linked with CXX, it unconditionally changes the linker to CXX. The test, in turn, is run always if a C++ compiler was found, i.e. independently of whether --with-cxx was provided. That doesn't match up with reports from my testers who say they can run with C++ extension modules from many different GCC versions if they just configure their Python --without-cxx. If what you were saying were true, wouldn't --without-cxx be ignored on ELF/Linux? Ok, it's still different. I see three cases now: 1. --without-cxx or --with-cxx=no specified. configure does not look for a C++ compiler, and does not check whether linking needs to be done with a C++ compiler, and decides to use Modules/python.c. 2. --with-cxx not given. configure does look for a C++ compiler, and does check whether linking with the C++ compiler is necessary, and still uses Modules/python.c 3. --with-cxx is given. configure requires it to point to a C++ compiler, performs the linking check, and uses Modules/ccpython.cc. Is the above a description of existing behavior or is it a behavior you're proposing? It would help discussion if you would use the actual code, too, instead of just using reports from your testers. I don't know what you mean by use the actual code. Do you mean, refer to the actual code in the discussion, or do you mean actually building and running Python --without-cxx myself? If the latter, I don't see a reason to repeat what people I trust have already done. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)
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 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 choice would change the behaviour of existing code too much and so produce much unhappiness. 2) Return unicode when the text can not be represented in ASCII. This will cause a change of behaviour for existing code which deals with non-ASCII data. 3) Return unicode when the text can not be represented in the default code page. While this change can lead to breakage because of combining byte string and unicode strings, it is reasonably safe from the point of view of data integrity as current code is returning garbage strings that look like '?'. 4) Provide two versions of the attribute, one with the current name returning byte strings and a second with a u suffix returning unicode. This is the least intrusive, requiring explicit changes to code to receive unicode data. For patch #1231336 I chose this approach producing sys.argvu and os.environu. For os.listdir the current behaviour of returning unicode when its argument is unicode can be retained but that is not extensible to, for example, sys.argv. Since this issue may affect many attributes a common approach should be chosen. For experimenting with os.listdir, there is a patch for posixmodule.c at http://www.scintilla.org/difft.txt which implements (2). To specify the US-ASCII code page, the number 20127 is used as there is no definition for this in the system headers. To change to (3) comment out the line with 20127 and uncomment the line with CP_ACP. Unicode arguments produce unicode results. Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible context managers in stdlib
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, if not quite death, in the last week or so). After seeing so many messages about with statements my eyes began to glaze over, so I stopped following that thread. Then I saw mention of context manager with no reference to any PEPs or to the with statement to provide context. None of the context-providing messages seemed to have been indexed by Google when I checked, so searching for Python context manager failed to return anything useful. Hence the post. BTW, context manager seems fine to me in that context... Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)
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 choice would change the behaviour of existing code too much and so produce much unhappiness. Would be nice, but will likely break too much code - if you let Unicode object enter non-Unicode aware code, it is likely that you'll end up getting stuck in tons of UnicodeErrors. If you want to get a feeling for this, try running Python with -U command line switch. 2) Return unicode when the text can not be represented in ASCII. This will cause a change of behaviour for existing code which deals with non-ASCII data. +1 on this one (s/ASCII/Python's default encoding). 3) Return unicode when the text can not be represented in the default code page. While this change can lead to breakage because of combining byte string and unicode strings, it is reasonably safe from the point of view of data integrity as current code is returning garbage strings that look like '?'. -1: code pages are evil and the reason why Unicode was invented in the first place. This would be a step back in history. 4) Provide two versions of the attribute, one with the current name returning byte strings and a second with a u suffix returning unicode. This is the least intrusive, requiring explicit changes to code to receive unicode data. For patch #1231336 I chose this approach producing sys.argvu and os.environu. -1 - this is what Microsoft did for many of their APIs. The result is two parallel universes with two sets of features, bugs, documentation, etc. For os.listdir the current behaviour of returning unicode when its argument is unicode can be retained but that is not extensible to, for example, sys.argv. I don't think that using the parameter type as parameter to function is a good idea. However, accepting both strings and Unicode will make it easier to maintain backwards compatibility. Since this issue may affect many attributes a common approach should be chosen. Indeed. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 11 2005) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)
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, M.-A. Lemburg [EMAIL PROTECTED] wrote: 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 choice would change the behaviour of existing code too much and so produce much unhappiness. Would be nice, but will likely break too much code - if you let Unicode object enter non-Unicode aware code, it is likely that you'll end up getting stuck in tons of UnicodeErrors. If you want to get a feeling for this, try running Python with -U command line switch. 2) Return unicode when the text can not be represented in ASCII. This will cause a change of behaviour for existing code which deals with non-ASCII data. +1 on this one (s/ASCII/Python's default encoding). 3) Return unicode when the text can not be represented in the default code page. While this change can lead to breakage because of combining byte string and unicode strings, it is reasonably safe from the point of view of data integrity as current code is returning garbage strings that look like '?'. -1: code pages are evil and the reason why Unicode was invented in the first place. This would be a step back in history. 4) Provide two versions of the attribute, one with the current name returning byte strings and a second with a u suffix returning unicode. This is the least intrusive, requiring explicit changes to code to receive unicode data. For patch #1231336 I chose this approach producing sys.argvu and os.environu. -1 - this is what Microsoft did for many of their APIs. The result is two parallel universes with two sets of features, bugs, documentation, etc. For os.listdir the current behaviour of returning unicode when its argument is unicode can be retained but that is not extensible to, for example, sys.argv. I don't think that using the parameter type as parameter to function is a good idea. However, accepting both strings and Unicode will make it easier to maintain backwards compatibility. Since this issue may affect many attributes a common approach should be chosen. Indeed. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 11 2005) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible context managers in stdlib
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 in the stdlib, you make it look like it'd be a local modification when it is not. I can only see confusion resulting from this. Users will inevitably try to use it like with sys.redirected_stderr(f): Which is of course a bug -- print doesn't go to stderr. Not sure if you meant this as an illustration of a typical bug or whether you meant sys.redirect_stdout(f). print hello print there instead of explicitly writing to f with print or write(). And that is just a terribly bad idea. It looks pretty, yes, but unless stdinouterr are made thread-local, it's just asking for trouble. Boy, do you have Java (or multi-threading) on your mind. A lot of Python programs are single-threaded, and this idiom has been promoted by examples for many years; I see nothing wrong with it in single-threaded code. I sure hope the world doesn't evolve to one where most programs have to be multi-threaded to be useful! Multi-threading is such a nightmare to program that we should really look for paradigms that hide it completely rather than trying to raise programmers who will write correct multi-threaded programs naturally; the latter just ain't gonna happen. A major use case for this, BTW, is to take *existing* Python code that was written using print statements and wrap it in something that captures its output. The f.write() or printf solutions won't work there... -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible context managers in stdlib
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 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [C++-sig] GCC version compatibility
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 here is tries
Any such test would only try: to really determine whether this is
necessary for all possible programs, one would have to test all possible
programs. Since there is an infinite number of programs, this test could
take a while.
Sure. You cannot write a test that gives the correct result for all platforms
you can think of, covering every compiler / linker quirk. I never claimed that
is possible.
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.
The original test, on the original system, would cause __main to be
undefined, and then decide to use C++. For a long time, on systems
that don't use collect2, the test *correctly* determined that linking
with g++ was not necessary.
It is only recent changes to g++ that break the test, namely the
introduction of this __gxx_personality_v0 thing.
The test broke due to a change in GCC 4.0, but the __gxx_personality_v0
thing was introduced long before. It is merely a symptom. I ran the tests
with GCC 3.3.1, 3.4.2, and 4.0.0. Here are the results:
GCC version 1 TU2 TUs
3.3.1g++ g++
3.4.2g++ g++
4.0.0gcc g++
(1 TU: test with one translation unit, as in Python 2.4.1.
2 TUs: test with two translation units, as in my last posting.
g++ / gcc: test indicates linking the executable requires g++ / gcc,
respectively.)
With GCC 3.3.1 and 3.4.2, linking of the executable conftest in the 1 TU test
fails because of an unresolved symbol __gxx_personality_v0. Therefore, python
is linked with g++.
The change that makes GCC 4.0.0 break the 1 TU test is that the compiler
apparently does a better job eliminating unreachable code. In the 1 TU test,
it recognizes __gxx_personality_v0 (or the code that refers to this symbol) is
unreachable and removes it. It seems there are no other symbols left that
depend on libstdc++ so suddenly conftest can be linked with gcc.
- my bug report #1189330 exihibts that the test
fails to do its job. And looking at the test that's certainly no surprise:
However, it *is* a surprise that your modified test fixes the problem.
Note that there is *no* reference to any symbol in another TU. The compiler
can detect that foo() won't throw any exceptions, that there is no need for
RTTI
and whatever else the C++ runtime provides. Consequently, the object file
produced by g++ does not contain any reference to symbols in libstdc++.
You are assuming implementation details here. I have seen
implementations of C++ (eg. g++ with collect2) where the test determines
that linking with C++ is necessary (because __main was undefined), as
well as systems where the test decides *correctly* that linking with
C++ is not necessary (e.g. gcc 2.x on an ELF system). That some C++
compiler introduces the C++ runtime if some C function may throw an
exception is a very specific detail of this C++ compiler.
I am not aware of any rule that makes the following program ill-formed:
// in a.cc:
extern C void foo();
int main() {
foo();
}
// in b.cc
extern C void foo() {
throw 1;
}
Provided the compiler does not do optimizations across translation units, it
has no way to determine in a.cc whether foo() is really a C function (i.e.,
compiled by a C compiler) or a C++ function with C linkage. I think a
conforming C++ compiler has to provide for the case that foo() might throw. It
was a very specific detail of gcc 2.x if it failed to do so. (A venial
omission, I admit.)
But I digress. It's not that important for our discussion whether a C++
compiler must / should / is allowed to add exception handling code to the
call of an extern C function. The point is that some do *unless* they see
the function definition. I contend the test involving two TUs matches more
closely the situation with ccpython.cc than the current test.
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 track down.
Of course, if you insist on this dependency optimization then you can try
to
fix Python's configure.in by using the second test above. But I would still
not trust it to cover all configurations on all platforms supported by
Python.
Of couse not. This is just autoconf: it does not allow magical porting
to all possible future operating systems. Instead, from time to time,
explicit porting activity is necessary. This is not just about
Re: [Python-Dev] [C++-sig] GCC version compatibility
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 then the user is left with a linker error that is time-consuming to track down. However, at least by the usual hierarchy of values, the sort of runtime error that results from the current needless linking with C++ on ELF/Linux is even worse. 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. We learned that there are indeed platforms that require --with-cxx. There is not much we can do for user on platforms that that also require the final executable to be linked with the C++ compiler. They have to live with the dependency on the C++ runtime and the likely runtime errors if the import extension modules built with a different C++ compiler. What about the platforms that require compilation of main() with a C++ compiler but allow you to link with the C compiler - can you import a C++ extension module built with C++ compiler version X if the main() function of the Python interpreter was compiled with C++ compiler version Y, X != Y? If not, then we are back to the runtime error, no matter whether there is a dependency on the C++ runtime library or not. So the automated test in configure could spare users runtime errors if they must configure --with-cxx and if they can link with the C compiler and if the C++ compiler versions used for building the Python interpreter and the extension module do not need to coincide. I don't know how large the subset of platforms is that satisfy these conditions. Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [C++-sig] GCC version compatibility
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. Some users will complain about this. Specifying --without-cxx also causes configure not to look for a C++ compiler, meaning that distutils won't know what the C++ compiler is, meaning that it will link extension modules with the C compiler instead. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linux Python linking with G++?
[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 traps; if any of those traps trigger, raise the C-level SIGFPE signal; and convert SIGFPE to a Python-level FloatingPointError exception. The comments in pyfpe.h explain this best. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Linux Python linking with G++?
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 have been more precisely phrased as, Do you mean to say whatever? Since your statements about the code have not always been accurate (not blaming you; everyone makes mistakes) I'd still need to know how you intend your statements to be interpreted, not only how they correlate with the code. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Weekly Python Patch/Bug Summary
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 draft documentation (2005-07-07) http://python.org/sf/1234057 opened by Nick Coghlan PEP 343 implementation (2005-07-11) http://python.org/sf/1235943 opened by Michael Hudson Patches Closed __ Allow weak referencing of classic classes (2005-04-03) http://python.org/sf/1175850 closed by glchapman New / Reopened Bugs ___ Pickle protocols 1, 2 can't handle inf floats. (2005-07-06) CLOSED http://python.org/sf/1233578 opened by Charles getpass.getpass() performs differently on Windows vs *nix (2005-07-07) http://python.org/sf/1233785 opened by Darryl Dixon tkFileDialog.askopen... fails when dir= (2005-07-06) http://python.org/sf/1233799 opened by Russell Owen datetime.strftime %s (2005-07-07) http://python.org/sf/1234123 opened by Peter Kleiweg 'insufficient disk space' message wrong (msi on win xp pro) (2005-07-07) http://python.org/sf/1234328 opened by Patrick Vrijlandt configure: error: cannot compute sizeof (int), 77 (2005-07-07) http://python.org/sf/1234473 opened by Tekhne filecmp.cmp's shallow option (2005-07-08) http://python.org/sf/1234674 opened by Mendez Admin privs required for Windows? (2005-07-08) CLOSED http://python.org/sf/1234850 opened by Tim Peters Tutorial Section 6.3 example wrong (2005-07-08) CLOSED http://python.org/sf/1234956 opened by Phoebus Chen ConfigParser generating strings I can't compare (2005-07-08) CLOSED http://python.org/sf/1234965 opened by Robert Guico Lock.acquire treats only 1 as True (2005-07-08) CLOSED http://python.org/sf/1234979 opened by Chris Perkins using some_re.sub() often imports sre.__doc__ (2005-07-09) http://python.org/sf/1234985 opened by Steve Alexander debug info file descriptor of tarfile is inconsistent (2005-07-10) http://python.org/sf/1235266 opened by George Yoshida Inconsistent singleton constructor messages (2005-07-10) CLOSED http://python.org/sf/1235569 opened by Pavel Pergamenshchik codecs.StreamRecoder.next doesn't encode (2005-07-10) http://python.org/sf/1235646 opened by Sebastian Wangnick crashes in bgen wrappers (2005-07-11) http://python.org/sf/1236090 opened by Michael Hudson Bugs Closed ___ openssl-0.9.8 requires _ssl.mak change (2005-07-06) http://python.org/sf/1233049 closed by loewis chr() returns ? when input 127 in OS X (2005-07-02) http://python.org/sf/1231488 closed by loewis Build failure (2005-06-30) http://python.org/sf/1230161 closed by ceramond Pickle protocols 1, 2 can't handle inf floats. (2005-07-06) http://python.org/sf/1233578 closed by mwh Admin privs required for Windows? (2005-07-08) http://python.org/sf/1234850 closed by loewis Tutorial Section 6.3 example wrong (2005-07-08) http://python.org/sf/1234956 closed by birkenfeld ConfigParser generating strings I can't compare (2005-07-08) http://python.org/sf/1234965 closed by tim_one Lock.acquire treats only 1 as True (2005-07-08) http://python.org/sf/1234979 closed by birkenfeld function and method objects confounded in Tutorial (2004-06-09) http://python.org/sf/969757 closed by birkenfeld Inconsistent singleton constructor messages (2005-07-10) http://python.org/sf/1235569 closed by rhettinger PyObject_Realloc bug in obmalloc.c (2005-04-19) http://python.org/sf/1185883 closed by tim_one Need locale arg to strftime() (2005-06-13) http://python.org/sf/1219840 closed by bcannon ``from sys import stdin,`` doesn't raise a SyntaxError (2005-04-25) http://python.org/sf/1190012 closed by bcannon [AST] distinct code objects not created (2005-04-25) http://python.org/sf/1190011 closed by bcannon [AST] automatic unpacking of arguments broken (2005-04-19) http://python.org/sf/1186353 closed by bcannon [AST] genexps get scoping wrong (2005-04-19) http://python.org/sf/1186195 closed by bcannon ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
