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 [email protected] 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 [email protected] 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
Reinhold Birkenfeld wrote:
> 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 in hacking the parser, but it would be very nice
>>>IMO if something of this sort could be implemented in a future version
>>>of Python.
>>
>>I don't think so. It smells too much of DWIM, which is very unpythonic. EIBTI.
>
>
> Another idea, which is much more conservative: textwrap.dedent is highly
> under-
> rated and hidden. Why not make it builtin or a string method?
>
> Reinhold
>
Using Andrew's examples from the PEP:
def usage(outfile):
outfile.write(
"""Usage: %s [OPTIONS] [ARGS]
Meta-options:
--helpDisplay this help then exit.
--version Output version information then exit.
""".dedent() % sys.argv[0])
self.runcommand("""\
if 1:
import sys as _sys
_sys.path = %r
del _sys
\n""".dedent() % (sys.path,))
class WrapTestCase(BaseTestCase):
def test_subsequent_indent(self):
# Test subsequent_indent parameter
expect = '''\
* This paragraph will be filled, first
without any indentation, and then
with some (including a hanging
indent).
'''.dedent().rstrip()
result = fill(self.text, 40,
initial_indent=" * ",
subsequent_indent="")
self.check(result, expect)
And if the loading of the textwrap module is deferred to the first call to
dedent(), then it wouldn't even need to incur any extra start up overhead.
Although that last example is a bad one, since you end up testing textwrap
against itself ;)
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.blogspot.com
___
Python-Dev mailing list
[email protected]
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 . -- Tim Peters, on comparing recursive structures ___ Python-Dev mailing list [email protected] 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 [email protected] 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 -- i am trying to get Asterisk to work it is stabbing me in the face yes ... i seem to recall that feature in the documentation -- from Twisted.Quotes ___ Python-Dev mailing list [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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)
M.-A. Lemburg: > It's naive to assume that all people in Germany using the German > locale have German names ;-) That is not an assumption I would make. The assumption I would make is that if it is important to you to have your account name in a particular character set then you will normally set your locale to enable easy use of that account. > I'm not sure why you bring up an administration tool: isn't > the discussion about being able to load Python modules from > directories with Unicode path components ? The discussion has moved between various aspects of unicode support in Python. There are many areas of the Python library which are not compatible with unicode and having an idea of the incidence of particular situations helps define where effort is most effectively spent. My experience has been that because of the way Windows handles character set conversions, problems are less common on individual's machines than they are on servers. Neil ___ Python-Dev mailing list [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 print>>f solutions won't work there... -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] 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 [email protected] 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, fro
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 [email protected] 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++?
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? >> >>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? This is the current behaviour. See the code to see for yourself. >>Somebody reported that the test works better for g++ if the >>function is marked extern "C". > > > Which function? foo(). > What does "works better" mean? It correctly detects that linking with g++ is necessary on the specific system in question (see bug report #1205568) >>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? This is existing behaviour (or what I believe existing behaviour to be). > 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. You wouldn't have to ask these questions if you had investigated the answers yourself. Regards, Martin ___ Python-Dev mailing list [email protected] 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 [email protected] 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 [email protected] 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 ?" 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 [email protected] 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 [email protected] 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)
M.-A. Lemburg:
> > 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).
I assume you mean the result of sys.getdefaultencoding() here.
Unless much of the Python library is modified to use the default
encoding, this will break. The problem is that different implicit
encodings are being used for reading data and for accessing files.
When calling a function, such as open, with a byte string, Python
passes that byte string through to Windows which interprets it as
being encoded in CP_ACP. When this differs from
sys.getdefaultencoding() there will be a mismatch.
Say I have been working on a machine set up for Australian English
(or other Western European locale) but am working with Russian data so
have set Python's default encoding to cp1251. With this simple script,
g.py:
import sys
print file(sys.argv[1]).read()
I process a file called '€.txt' with contents "European Euro" to produce
C:\zed>python_d g.py €.txt
European Euro
With the proposed modification, sys.argv[1] u'\u20ac.txt' is
converted through cp1251 to '\x88.txt' as the Euro is located at 0x88
in CP1251. The operating system is then asked to open '\x88.txt' which
it interprets through CP_ACP to be u'\u02c6.txt' ('ˆ.txt') which then
fails. If you are very unlucky there will be a file called 'ˆ.txt' so
the call will succeed and produce bad data.
Simulating with str(sys.argvu[1]):
C:\zed>python_d g.py €.txt
Traceback (most recent call last):
File "g.py", line 2, in ?
print file(str(sys.argvu[1])).read()
IOError: [Errno 2] No such file or directory: '\x88.txt'
> -1: code pages are evil and the reason why Unicode was invented
> in the first place. This would be a step back in history.
Features used to specify files (sys.argv, os.environ, ...) should
match functions used to open and perform other operations with files
as they do currently. This means their encodings should match.
Neil
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
