Re: [Python-Dev] Chaining try statements: eltry?
Greg Ewing wrote: > Guido van Rossum wrote: > > >>I sometimes think it was >>a mistake to introduce elif just to save typing "else if". >> >>The problem with the elwhile/elfor/eltry idea > > > is that you're just as likely to need e.g. > >>a "try" in the else clause of a while-loop as another while, > > > Here's an idea for Python 3000 which addresses both of > these: Split 'elif' back up into 'else if', but also > generalise it so that any 'else' can be followed by any > suite-introducing statement. Then you get all possible > combinations for free. I don't think that's a good idea. What would the following monstrosity mean?: if 0: print "Ran the if" else for item in (1, 2, 3): print item else try: print "No exception here!" except: pass else: print "Who's else is this, anyway?" The use-case of 'elif' or 'else if' to avoid nested if statements is strong, but the use cases for the ability to mix compound statements together is significantly weaker. 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] Linux Python linking with G++?
David Abrahams schrieb: >"Martin v. Löwis" <[EMAIL PROTECTED]> writes: > > > >>David Abrahams wrote: >> >> >>>Unless, of course, I'm missing something. So if I am missing >>>something, what is it? >>> >>> >>You are missing something, and I can only repeat myself. Some systems >>require main() to be compiled as C++, or else constructors may not work >>(and perhaps other things fail as well). >> >> > >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. There is no reason that file >couldn't be rewritten as a pure 'C' file and any need for Python to be >linked with G++ would disappear. > > > >>The configure option --with-cxx (documented as "enable C++ support") >>make Python C++ options >> >> > >What are "Python C++ options?" > > > >>work on such systems. It is automatically enabled if a C++ compiler >>is found. >> >>There is configure auto-detection for what linker is used when >>ccpython.o becomes main(). >> >>This is the state of the things as it is. In what way would you like to >>see that state changed? >> >> > >I would like the Python executable never to be linked (or compiled >either) by g++ unless that is explicitly requested by the person >invoking configure or make. > > > >>I could personally accept if ccpython and --with-cxx would be dropped >>entirely (i.e. deliberately breaking systems which require it); >> >> > >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 convinced by your >assertion. If such a system exists, it should be easy for someone to >point me at it, and show that something breaks. > > > If you build C++ extensions on HP-UX with aCC, Python must be compiled and linked as a C++ program. This is documented. It will not work if Python is compiled and linked as a normal C program (I have tried it). I haven't tried gcc on this platform, but I guess it is the same (compile and link with g++). Ulli ___ 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] __autoinit__
For those who didn't like my proposal a week ago, please have another look: http://mail.python.org/pipermail/python-list/2005-July/289446.html Please reply only to python-list. Cheers, Ralf ___ 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: > Thomas Heller: > > >>But adding u'\u5b66\u6821\u30c7\u30fc' to sys.path won't allow to import >>this file as module. Internally Python\import.c converts everything to >>strings. I started to refactor import.c to work with PyStringObjects >>instead of char buffers as a first step - PyUnicodeObjects could have >>been added later, but I gave up because there seems absolute zero >>interest in it. > >Well, most people when confronted with this will rename the > directory to something simple like "ulib" and continue. I don't really buy this "trick": what if you happen to have a home directory with Unicode characters in it ? >>I can't judge on this - but it's easy to experiment with it, even in >>current Python releases since sys.argvu, os.environu can also be >>provided by extension modules. > > >It is the effect of this on the non-unicode-savvy that is > important: if os.environu goes into prereleases of 2.5 then the only > people that will use it are likely to be those who already try to keep > their code unicode compliant. There is only likely to be (negative) > feedback if existing features are made unicode-only or use unicode for > non-ASCII. I don't like the idea of creating a parallel universe for Unicode - OSes are starting to integrate Unicode filenames rather quickly (UTF-8 on Unix, UTF-16-LE on Windows), so it's much better to follow them and start accepting Unicode in sys.path. Wouldn't it be easy to have the import logic convert Unicode entries in sys.path to whatever the OS uses internally (UTF-8 or UTF-16-LE) and then keep the char buffers in place ? >>But thanks that you care about this stuff - I'm a little bit worried >>because all the other folks seem to think everything's ok (?). > >Unicode is becoming more of an issue: many Linux distributions now > install by default with a UTF8 locale and other tools are starting to > use this: GCC 4 now delivers error messages using Unicode quote > characters like 'these' rather than `these'. There are 131 threads > found by Google Groups for (UnicodeEncodeError OR UnicodeDecodeError) > and 21 of these were in this June. A large proportion of the threads > are in language-specific groups so are not as visible to core > developers. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 09 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] __autoinit__
On Sat, Jul 09, 2005, Ralf W. Grosse-Kunstleve wrote: > > For those who didn't like my proposal a week ago, please have another > look: > > http://mail.python.org/pipermail/python-list/2005-July/289446.html > > Please reply only to python-list. Looks like you mis-sent this to python-dev; you probably want to resend. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ f u cn rd ths, u cn gt a gd jb n nx prgrmmng. ___ 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++?
Ulrich Berning <[EMAIL PROTECTED]> writes: > If you build C++ extensions on HP-UX with aCC, Python must be compiled > and linked as a C++ program. This is documented. You mean dynamically loaded C++ extensions, or the kind that are linked into the Python executable? I'm willing to believe almost anything about HP-UX. Until recently, aCC was so broken as a C++ compiler that there was little point in trying to get Boost.Python to work on it, and I don't have much data for that system. > It will not work if Python is compiled and linked as a normal C > program (I have tried it). Even if you take out the use of C++ constructs in ccpython.cc? I just need to check all the obvious angles. > I haven't tried gcc on this platform, but I guess it is the same > (compile and link with g++). Okay, but -- at the very least -- we don't need this behavior on ELF/Linux. -- 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)
M.-A. Lemburg: > I don't really buy this "trick": what if you happen to have > a home directory with Unicode characters in it ? Most people choose account names and thus home directory names that are compatible with their preferred locale settings: German users are unlikely to choose an account name that uses Japanese characters. Unicode is only necessary for file names that are outside your default locale. An administration utility may need to visit multiple user's home directories and so is more likely to encounter files with names that can not be represented in its default locale. I think it would be better if sys.path could include unicode entries but expect the code will rarely be exercised. 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] Chaining try statements: eltry?
Nick Coghlan wrote: > I don't think that's a good idea. What would the following monstrosity > mean?: > >if 0: >print "Ran the if" >else for item in (1, 2, 3): >print item >else try: >print "No exception here!" >except: >pass >else: >print "Who's else is this, anyway?" It is unambiguous. But: > The use-case of 'elif' or 'else if' to avoid nested if statements is > strong, but the use cases for the ability to mix compound statements > together is significantly weaker. This is not even about use cases anymore, it's about usability. Indentation (by indicating nesting) serves well to recognize at first sight what belongs together, and what doesn't. Mixing compound statements breaks this, as it requires the reader to think about it twice, if that's even enough. -- Thomas ___ 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
--- David Abrahams <[EMAIL PROTECTED]> wrote: > Yes, all the tests are passing that way. > > > (On ELF based Linux/x86, at least.) That leaves me wondering > > > > * when is --with-cxx really necessary? > > I think it's plausible that if you set sys.dlopenflags to share > symbols it *might* end up being necessary, but IIRC Ralf does use > sys.dlopenflags with a standard build of Python (no > --with-cxx)... right, Ralf? Yes, I am using sys.setdlopenflags like this: if (sys.platform == "linux2"): sys.setdlopenflags(0x100|0x2) /usr/include/bits/dlfcn.h:#define RTLD_GLOBAL 0x00100 /usr/include/bits/dlfcn.h:#define RTLD_NOW 0x2 Note that the default Python 2.4.1 installation links python with g++. I've never had any problems with this configuration under any Linux version, at least: Redhat 7.3, 8.0, 9.0, WS3, SuSE 9.2, Fedora Core 3, and some other versions I am not sure about. Specifically for this posting I've installed Python 2.4.1 --without-cxx. All of our 50 Boost.Python extensions still work without a problem. Cheers, Ralf Sell on Yahoo! Auctions no fees. Bid on great items. http://auctions.yahoo.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++-sig] GCC version compatibility
On Sat, Jul 09, 2005 at 12:08:08AM +0200, "Martin v. Löwis" wrote:
> David Abrahams wrote:
> >>When I looked into this problem I saw that configure in fact builds a test
> >>executable that included an object file compiled with g++. If the link step
> >>with gcc succeeds then LINKCC is set as above, otherwise CXX is
> >>used. Obviously, on my system this test was successful so configure decided
> >>to link with gcc. However, minimal changes to the source of the test program
> >>caused the link step to fail. It was not obvious to me at all why the latter
> >>source code should cause a dependency on the C++ runtime if the original
> >>code does not. My conclusion was that this test is fragile and should be
> >>skipped.
> >
> >
> > Sounds like it. I have never understood what the test was really
> > checking for since the moment it was first described to me, FWIW.
>
> 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" - my bug report #1189330 exihibts that the test
fails to do its job. And looking at the test that's certainly no surprise:
configure writes the following conftest.cc on the disk (whitespaces added for
better readability):
[EMAIL PROTECTED]:~/tmp/python-config> cat conftest.cc
void foo();
int main() {
foo();
}
void foo() {
}
This TU is compiled with the C++ compiler and then linked with the C compiler:
[EMAIL PROTECTED]:~/tmp/python-config> g++ -o conftest.o -c conftest.cc
[EMAIL PROTECTED]:~/tmp/python-config> gcc -o conftest conftest.o
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++.
However, python.c does reference a function from other TUs, in particular
extern "C" int Py_Main(int, char**). The following test shows that in this
situation you must link with g++:
[EMAIL PROTECTED]:~/tmp/python-config> cat conftest_a.cc
extern "C" void foo();
int main() {
foo();
}
[EMAIL PROTECTED]:~/tmp/python-config> cat conftest_b.c
void foo() {
}
[EMAIL PROTECTED]:~/tmp/python-config> g++ -o conftest_a.o -c conftest_a.cc
[EMAIL PROTECTED]:~/tmp/python-config> gcc -o conftest_b.o -c conftest_b.c
[EMAIL PROTECTED]:~/tmp/python-config> gcc -o conftest conftest_a.o
conftest_b.o
conftest_a.o(.eh_frame+0x11): undefined reference to `__gxx_personality_v0'
collect2: ld gab 1 als Ende-Status zurück
(I ran this test with g++ 3.3.1, 3.4.2, and 4.0.0 with identical results.) The
reason is, I guess, that even though foo() is delared to have "C" linkage, it
still can throw a C++ exception.
> >>If Python is built with --with-cxx then it should be linked with CXX
> >>as well.
> >
> >
> > U betcha.
>
> Wrong. The test was introduced in response to complaints that Python
> unnecessarily links with libstdc++ on some Linux systems. On these
> Linux systems, it was well possible to build main() with a C++ compiler,
> and still link the entire thing with gcc. Since main() doesn't use
> any libstdc++ functionality, and since collect2/__main isn't used,
> one would indeed expect that linking with CXX is not necessary.
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.
> >>(On ELF based Linux/x86, at least.) That leaves me wondering
> >>
> >> * when is --with-cxx really necessary?
> >
> >
> > I think it's plausible that if you set sys.dlopenflags
>
> This has no relationship at all. --with-cxx is much older than
> sys.dlopenflags. It is used on systems where main() must be a
> C++ program for C++ extension modules to work (e.g. some Linux
> systems).
Can you provide a concrete examples of such systems? The explanation of
--with-cxx in the README mentions a.out. Are there other systems?
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] Adding the 'path' module (was Re: Some RFEfor review)
>> Well, most people when confronted with this will rename the >> directory to something simple like "ulib" and continue. > > I don't really buy this "trick": what if you happen to have > a home directory with Unicode characters in it ? I think this is one of the most common places, too. Whenever I've come across unicode filenames it has been because the user has a unicode Windows username, so their 'home directory' (and temp directory, desktop folder, etc) does too. Convincing people to either change their username or to go through the fairly complicated process of moving these directories elsewhere generally isn't feasible. =Tony.Meyer ___ 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: > M.-A. Lemburg: > > >>I don't really buy this "trick": what if you happen to have >>a home directory with Unicode characters in it ? > > >Most people choose account names and thus home directory names that > are compatible with their preferred locale settings: German users are > unlikely to choose an account name that uses Japanese characters. It's naive to assume that all people in Germany using the German locale have German names ;-) E.g. we have a large Japanese community living here in Düsseldorf. If that example does not convince you, just have a look at all the Chinese restaurants in cities around the world - I'm sure that quite a few of the owners will want to use their correctly written name as account name. Unicode makes this possible and while it may not be in wide-spread use nowadays, things will definitely change over the next few years as more and more OSes and platforms will introduce native Unicode support. > Unicode is only necessary for file names that are outside your default > locale. An administration utility may need to visit multiple user's > home directories and so is more likely to encounter files with names > that can not be represented in its default locale. 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 ? >I think it would be better if sys.path could include unicode > entries but expect the code will rarely be exercised. I think that sys.path should always use Unicode for non-ASCII path names - this would make it locale setting independent, which is what we should strive for in Py3k: locales are much easier to handle at the application level and only introduce portability problems if used at the OS or C lib level. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source >>> 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)
On 7/9/05, Neil Hodgson <[EMAIL PROTECTED]> wrote: > M.-A. Lemburg: > > > I don't really buy this "trick": what if you happen to have > > a home directory with Unicode characters in it ? > >Most people choose account names and thus home directory names that > are compatible with their preferred locale settings: German users are > unlikely to choose an account name that uses Japanese characters. > Unicode is only necessary for file names that are outside your default > locale. An administration utility may need to visit multiple user's > home directories and so is more likely to encounter files with names > that can not be represented in its default locale. > >I think it would be better if sys.path could include unicode > entries but expect the code will rarely be exercised. Another problem is that if you can return 8-bit strings encoded in the local code page, and also Unicode, combining the two using string operations (e.g. a directory using the local code page containing a file using Unicode, and then combining the two using os.path.join()) will fail unless the local code page is also Python's global default encoding (which it usually isn't -- we really try hard to keep the default encoding 'ascii' at all times). 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. The problem is of course that while the I/O functions will handle this fine, *printing* Unicode still doesn't work by default. :-( I can't wait until we switch everything to Unicode and have encoding on all streams... -- --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] Linux Python linking with G++?
David Abrahams schrieb: >Ulrich Berning <[EMAIL PROTECTED]> writes: > > > >>If you build C++ extensions on HP-UX with aCC, Python must be compiled >>and linked as a C++ program. This is documented. >> >> > >You mean dynamically loaded C++ extensions, or the kind that are >linked into the Python executable? > > > Dynamically loaded extensions, especially SIP/PyQt (http://www.riverbankcomputing.co.uk). >I'm willing to believe almost anything about HP-UX. Until recently, >aCC was so broken as a C++ compiler that there was little point in >trying to get Boost.Python to work on it, and I don't have much data >for that system. > > > I'm using the HP aC++ Compiler C.03.50 together with the patches PHSS_29483 and PHSS_30967 on HP-UX B.11.00 and had no problems to build Python (2.3.5), Qt, SIP and PyQt and all other extensions with it. >>It will not work if Python is compiled and linked as a normal C >>program (I have tried it). >> >> > >Even if you take out the use of C++ constructs in ccpython.cc? I just >need to check all the obvious angles. > > > What do you mean? The only C++ construct in ccpython.cc is the extern "C" declaration of Py_Main() and this is necessary if a C++ program references symbols from a C library. HP says, that a C++ shared library or a C++ shared object can only be loaded by a C++ main program. I can't remember the error message/symptoms, but I tried to build Python using python.c and couldn't load any C++ extensions. Because I'm going on vacation for the next three weeks, I can't try anything on HP-UX at the moment. ___ 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++?
Ulrich Berning <[EMAIL PROTECTED]> writes: > David Abrahams schrieb: > >>Ulrich Berning <[EMAIL PROTECTED]> writes: >> >> >> >>> If you build C++ extensions on HP-UX with aCC, Python must be >>> compiled and linked as a C++ program. This is documented. >>> >>> >> >>You mean dynamically loaded C++ extensions, or the kind that are >>linked into the Python executable? >> >> >> > Dynamically loaded extensions, especially SIP/PyQt > (http://www.riverbankcomputing.co.uk). I see. >>I'm willing to believe almost anything about HP-UX. Until recently, >>aCC was so broken as a C++ compiler that there was little point in >>trying to get Boost.Python to work on it, and I don't have much data >>for that system. >> >> >> > I'm using the HP aC++ Compiler C.03.50 together with the patches > PHSS_29483 and PHSS_30967 on HP-UX B.11.00 and had no problems to build > Python (2.3.5), Qt, SIP and PyQt and all other extensions with it. Yeah, but Boost tends to stress a C++ compiler's correctness much more than Qt. >>>It will not work if Python is compiled and linked as a normal C >>>program (I have tried it). >> >>Even if you take out the use of C++ constructs in ccpython.cc? I just >>need to check all the obvious angles. > > What do you mean? The only C++ construct in ccpython.cc is the extern > "C" declaration of Py_Main() That's what I mean. > and this is necessary if a C++ program > references symbols from a C library. HP says, that a C++ shared library > or a C++ shared object can only be loaded by a C++ main program. Well, that's dumb, but I believe it. > I can't remember the error message/symptoms, but I tried to build > Python using python.c and couldn't load any C++ extensions. Because > I'm going on vacation for the next three weeks, I can't try anything > on HP-UX at the moment. Okay, I'm convinced that on HP/UX, Python needs to be a C++ program. -- 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
