Re: [Python-Dev] Chaining try statements: eltry?
Guido van Rossum [EMAIL PROTECTED] wrote: I also notice that your only example is very repetitive, and would be better written as a loop, using Python's dynamic nature: Sure, that's true for the example given. Getting other stuff into a form which allows for looping may require additional code. But then, the example was intended to illustrate, not persuade. It's fine with me if you're determined that eltry is a bad (or at least not good enough) idea. I do wish for it occasionally, but that's true for a number of things. Thinking about it some more, I find that a symmetry between statements which have an 'else' part would be appealing from an aesthetic point of view, which includes introduction of 'elfor' and 'elwhile' - or allowing for syntax like 'else if ...:' and 'else try:'. (It seems some people favour that anyway. OTOH, I undestand that introducing two-token constructs doesn't necessarily simplify parsing.) But I haven't encountered any use cases for that, so it's probably just idle musing. -- Viele Grüße, Thomas ___ 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] PEP 343 documentation on Sourceforge Patch tracker
I've put the draft documentation on the SF tracker, as Patch ID #1234057 [1]. The version posted there has a few changes from the last draft I mailed to the list, including: - mention try/finally, then describe with statements as a way to eliminate the associated boilerplate - clean up some terminology issues in the opening section that were holdovers from the 'suite management' version - switch to contextmanager as the decorator name - a couple of name changes in the contextmanager sample code - a few minor editiorial fixes It still needs addition of latex formatting codes. I also kept the enter/exit terminology, since that is the only one Guido has given blessing to (by approving PEP 343 using those method names) Cheers, Nick. [1] http://www.python.org/sf/1234057 -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.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)
Neil Hodgson [EMAIL PROTECTED] writes: Guido van Rossum: Ah, sigh. I didn't know that os.listdir() behaves differently when the argument is Unicode. Does os.listdir(.) really behave differently than os.listdir(u.)? Yes: os.listdir(.) ['abc', ''] os.listdir(u.) [u'abc', u'\u0417\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0439\u0442\u0435'] Bah! I don't think that's a very good design (although I see where it comes from). Partly my fault. At the time I was more concerned with making functionality possible rather than convenient. Promoting only those entries that need it seems the right solution -- user code that can't deal with the Unicode entries shouldn't be used around directories containing unicode -- if it needs to work around unicode it should be fixed to support that! I'm sorry but that's not my opinion. Code that can't deal with unicode entries is broken, imo. The programmer does not know where the user runs this code at what he throws at it. I think that this will hide bugs. When I installed the first game written in Python with pygame on my daughter's PC it didn't run, simply because there was a font listed in the registry which contained umlauts somewhere. OTOH, I once had a bug report from a py2exe user who complained that the program didn't start when installed in a path with japanese characters on it. I tried this out, the bug existed (and still exists), but I was astonished how many programs behaved the same: On a PC with english language settings, you cannot start WinZip or Acrobat Reader (to give just some examples) on a .zip or .pdf file contained in such a directory. OK, I'll work on a patch for that but I'd like to see the opinions of the usual unicode guys as this will produce more opportunities for UnicodeDecodeError. The modification will probably work in the opposite way, asking for all the names in unicode and then attempting to convert to the default code page with failures retaining the unicode name. Thomas ___ 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] C bindings calling tmpfile() blocks interrupt signal
I discovered an issue on Mac OS X that seems to relate to signal
handling. I have a C binding in which I call the standard tmpfile()
function. After calling it, I can't break Python anymore with CTRL-C.
Investigating the Darwin source code for tmpfile() (and FreeBSD, they
are the same) , I found that the function is mucking with the signals:
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdio/tmpfile.c?rev=1.9content-type=text/x-cvsweb-markup
Is this considered a Python issue, or an OS issue? I ran a simple test
against the interrupt signal, which didn't show any wrong behavior:
static void intcatcher(int sig) {
printf(Interrupt catched\n);
exit(1);
}
int main(int argc, char **argv) {
signal(SIGINT, intcatcher);
printf(Press CTRL-C to interrupt...\n);
tmpfile();
while (1)
;
return 0;
}
But with my threaded Python code, SIGINT doesn't work anymore after my
binding has called tmpfile().
Florent
--
Florent Pillet http://www.florentpillet.com
Freelance software developer/consultant - Palm OS Mac OS X
ICQ: 117292463Skype: callto://florent.pillet
___
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] 'With' context documentation draft (was Re: Terminology for PEP 343
Barry Warsaw [EMAIL PROTECTED] writes: +1 on @contextmanager On Wed, 2005-07-06 at 19:47, Raymond Hettinger wrote: __enter__(self): __exit__(self, exc_type, exc_value, exc_traceback): These names should be changed to __beginwith__ and __endwith__. -1. -0. My fingers are too hardwired to writing endswith, as in the string method of similar name. ;) Slightly silly alternative: __within__ and __without__ Meh. Otherwise, +0 on __enter__ and __exit__. +1 from me. Cheers, mwh -- 58. Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.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
[Python-Dev] Linux Python linking with G++?
Apparently Python on some linux distros is being linked by g++ rather than gcc, resulting in the C++ runtime library being linked into Python; this has bad consequences for compatibility between C++ extension modules and Pythons that have been built with different versions of GCC. Is this behavior intentional? ---BeginMessage--- Topics: Re: Regressions in your Boost libraries as of 2005-07-06 Re: Regressions in your Boost libraries as of 2005-07-06 ---End Message--- ---BeginMessage--- On Jul 6, 2005, at 9:04 PM, Ralf W. Grosse-Kunstleve wrote: (Newer?) Python executables are linked with g++ (instead of gcc), which brings in libstdc++.so. We had weird crashes when using a Python compiled on a machine with libstdc++.so.5 (Redhat 8.0) for building Boost.Python extensions on another machine which had libstdc++.so.6 (Gentoo 1.6.8 and Fedora core 3, I believe). To check for libstdc++ incompatibilities, run ldd full-path-to/python On eddie (one of the trouble systems), this gives: libstdc++.so.5 = /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/libstdc++.so.5 (0xb7dd8000) for the Python installed on the system. and, e.g., ldd full-path-to/minimal_ext.so ... and this gives (for eddie's GCC 4.0.0): libstdc++.so.6 = /usr/lib/gcc/i686-pc-linux-gnu/4.0.0-alpha20050213/libstdc++.so.6 (0xb7f0d000) It looks like that's the problem, then. We have two libstdc++ versions around, hence the need to build Boost.Python with the same compiler version as Python. Bummer. I wonder... does Python even use C++? Should they just be linking with gcc? Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ---End Message--- ---BeginMessage--- --- David Abrahams [EMAIL PROTECTED] wrote: Doug, I know you've drawn that conclusion, but it really surprises me. Generally speaking, I have been able to use any version of Python with any compiler, provided Python was compiled with something having a compatible 'C' ABI. I dunno what else to say. You're free to play around with things on our Linux machine (eddie); we have various flavors of GCC 3.3 and 3.4 available, with Pythons compiled with those plus the system GCC 3.3.5. GCC 2.95.3 (with or without STLport) works fine with the system Python (compiled with the system's GCC 3.3.5), but Boost.Python tests fail to run properly unless Python is recompiled with the same GCC 3.3.6 or 3.4.4. Well, I've done this numerous times on numerous machines. I wonder what's up with eddie? Ralf, does this sound normal to you? (Newer?) Python executables are linked with g++ (instead of gcc), which brings in libstdc++.so. We had weird crashes when using a Python compiled on a machine with libstdc++.so.5 (Redhat 8.0) for building Boost.Python extensions on another machine which had libstdc++.so.6 (Gentoo 1.6.8 and Fedora core 3, I believe). To check for libstdc++ incompatibilities, run ldd full-path-to/python and, e.g., ldd full-path-to/minimal_ext.so Look for lines like libstdc++.so.6 = /usr/lib64/libstdc++.so.6 (0x002a95689000) HTH, Ralf __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ---End Message--- -- 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] Linux Python linking with G++?
David Abrahams wrote: Apparently Python on some linux distros is being linked by g++ rather than gcc, resulting in the C++ runtime library being linked into Python; this has bad consequences for compatibility between C++ extension modules and Pythons that have been built with different versions of GCC. Is this behavior intentional? Configure with --without-cxx to not use g++. Since there is an option in configure, I assume it is intentional. -- Sjoerd Mullender ___ 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?
On 7/7/05, Thomas Lotze [EMAIL PROTECTED] wrote: Sure, that's true for the example given. Getting other stuff into a form which allows for looping may require additional code. Well, hypothetical illustrations don't carry much value when arguing for something as substantial as new syntax requiring a new keyword. You have to present an actual use case with an indication (even if only anecdotal) of how common the use case is, and an explanation why the existing ways of handling that use case are inadequate. Your illustration doesn't count as a use case because it is easily handled already. Thinking about it some more, I find that a symmetry between statements which have an 'else' part would be appealing from an aesthetic point of view, which includes introduction of 'elfor' and 'elwhile' - or allowing for syntax like 'else if ...:' and 'else try:'. (It seems some people favour that anyway. OTOH, I undestand that introducing two-token constructs doesn't necessarily simplify parsing.) But I haven't encountered any use cases for that, so it's probably just idle musing. The parsing would be easy enough (and in fact I sometimes think it was a mistake to introduce elif just to save typing else if. The problem with the elwhile/elfor/eltry idea (apart from the explosion of new keywords) is that you're just as likely to need e.g. a try in the else clause of a while-loop as another while, so you'd end up having all combinations in the syntax. Since, as you say, the use cases are rare, the syntactic complexity isn't worth it. I even wonder if else-clauses on for/while were a good idea. (The one on try is definitely a good idea since the use case is quite frequent and only clumsily handled otherwise; the use cases for else on for/while are less convincing IMO.) -- --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] List copy and clear (was Re: Inconsistent API forsets.Set and build-in set)
Tim Peters [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Or my personal favorite, while mylist: del mylist[::2] Then the original index positions with the most consecutive trailing 1 bits survive the longest, which is important to avoid ZODB cache bugs wink. This is a joke, hopefully, and in that case, I fell for it. If not, please provide a url with related discussion (for educational purposes :) ___ 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++?
Sjoerd Mullender [EMAIL PROTECTED] writes: David Abrahams wrote: Apparently Python on some linux distros is being linked by g++ rather than gcc, resulting in the C++ runtime library being linked into Python; this has bad consequences for compatibility between C++ extension modules and Pythons that have been built with different versions of GCC. Is this behavior intentional? Configure with --without-cxx to not use g++. Since there is an option in configure, I assume it is intentional. O-kay... any idea what the rationale for this decision might be? -- 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] List copy and clear (was Re: Inconsistent API forsets.Set and build-in set)
[Tim Peters] Or my personal favorite, while mylist: del mylist[::2] Then the original index positions with the most consecutive trailing 1 bits survive the longest, which is important to avoid ZODB cache bugs wink. [Christos Georgiou] This is a joke, hopefully, and in that case, I fell for it. If not, please provide a url with related discussion (for educational purposes :) Fell for what? It's certainly true that the code snippet allows the original index positions with the most consecutive trailing 1 bits to survive the longest (on the first iteration, all even index positions (no trailing 1 bits) are deleted, and you don't really need a URL to figure out what happens on the i'th iteration). The idea that this is helpful in avoiding anything's cache bugs is purely wink-worthy, though. ___ 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++?
Configure with --without-cxx to not use g++. Since there is an option in configure, I assume it is intentional. Dave O-kay... any idea what the rationale for this decision might be? I believe it's so that people can link in libraries written in C++ and have them initialized properly. 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] Chaining try statements: eltry?
[Guido van Rossum] I even wonder if else-clauses on for/while were a good idea. I surely find them useful, and see them as a Python originality (a welcome one). -- François Pinard http://pinard.progiciels-bpi.ca ___ 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] 'With' context documentation draft (was Re: Terminology for PEP 343
+1 on @contextmanager +1. [__enter__, __exit__] These names should be changed to __beginwith__ and __endwith__. -1. The PEP has had an extensive review period and several alternatives were discussed and rejected. These names are clear, they *do* match, and as Fred says the __*__ namespace has lots of room. Also, the PEP was accepted with these names. Now, if it was accepted with a major flaw or some semantics left unspecified, I'd be happy to discuss repairs; but there's nothing broken about this part of the PEP, so I say enough is enough (and none of the proposals sound good to me anyway so I'd be -1 even if the PEP was still under discussion). -- --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] 'With' context documentation draft (was Re: Terminology for PEP 343
At 09:12 PM 7/6/2005 +1000, Nick Coghlan wrote:
Another example is the use of contexts to handle insertion of the
appropriate tags when generating HTML:
with html:
with body:
with h1:
print Some heading
with p:
print This is paragraph 1
with p:
print This is paragraph 2
with h2:
print Another heading
I suggest changing this to something like this:
class tag(object):
def __init__(self,name):
self.name = name
def __enter__(self):
print %s % name
def __exit__(self):
print /%s % name
with tag('html'):
# ... etc.
So that it's obvious where the implementation is coming from. Otherwise,
it looks altogether too magical.
Also, the posted draft doesn't explain what happens to the __enter__ return
value, either in a literal sense or in the sense of where it fits in the
overall concept of context management.
___
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?
Guido van Rossum [EMAIL PROTECTED] wrote: On 7/7/05, François Pinard [EMAIL PROTECTED] wrote: [Guido van Rossum] I even wonder if else-clauses on for/while were a good idea. 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! (data point) I had gotten along for 5 years without knowing/remembering there existed an else clause in for and while loops until the beginnings of the thunk/block/with discussion in February or March. Commercial work puts me at around 30k lines of Python in the last year. In the last 3-4 months, I've used the else clause on for and while around 5 times. In looking at the tutorial, I notice that else clauses on loops is discussed a few sections after discussion on the loops themselves. This seems like a reasonable location to me, though to be sure, we should find some people, get them to learn Python through the tutorial, then ask them what they thought of the tutorial on else clauses in for and while loops, and whether or not they confused them. - Josiah ___ 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?
[Guido, on {for,while}/else]
...
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!
That's what I'm here for. I like loop else clauses, but have to
admit that (a) I rarely use them; (b) most of the time I use them, my
control flow is on the way to becoming so convoluted that I'm going to
rewrite the whole function soon anyway; and, (c) I've often misread
code that uses them, mentally attaching the else to a nearby if
instead.
I also suspect that if they weren't in the language already, a PEP to
introduce them would fail, because
still_looking = True
some loop:
if found it:
still_looking = False
break
if still_looking:
# what would have been in the else clause
is clear and easy to write without it.
___
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?
[Guido, on {for,while}/else]
...
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!
[Tim saves the day]
That's what I'm here for. I like loop else clauses, but have to
admit that (a) I rarely use them; (b) most of the time I use them, my
control flow is on the way to becoming so convoluted that I'm going to
rewrite the whole function soon anyway; and, (c) I've often misread
code that uses them, mentally attaching the else to a nearby if
instead.
I also suspect that if they weren't in the language already, a PEP to
introduce them would fail, because
still_looking = True
some loop:
if found it:
still_looking = False
break
if still_looking:
# what would have been in the else clause
is clear and easy to write without it.
OTOH I don't particularly like code that requires flag variables; they
often make me squirm because the same condition (flag) is tested
multiple times where it could be tested just once if more
sophisticated flow control (e.g. an else clause :) was available.
How would a PEP to *remove* this feature fare today?
Unhelpfully,
--
--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] Chaining try statements: eltry?
Tim Peters [EMAIL PROTECTED] writes: I also suspect that if they weren't in the language already, a PEP to introduce them would fail, because still_looking = True some loop: if found it: still_looking = False break if still_looking: # what would have been in the else clause is clear and easy to write without it. Oh, that's wierd. I didn't know there were else clauses for loops, but I would've expected the other semantics. That is, either the loop terminates normally, else: whatever. -- 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] Linux Python linking with G++?
Skip Montanaro [EMAIL PROTECTED] writes: Configure with --without-cxx to not use g++. Since there is an option in configure, I assume it is intentional. Dave O-kay... any idea what the rationale for this decision might be? I believe it's so that people can link in libraries written in C++ and have them initialized properly. Can you give specifics? What do you mean by link in? Do you mean statically link into the Python interpreter, or something else? Boost.Python is a library written in C++ and I've never had trouble using it with a Python executable... until I ran into a Python that was linked with libstdc++! -- 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] Chaining try statements: eltry?
At 02:48 PM 7/7/2005 -0400, Tim Peters wrote:
[Guido, on {for,while}/else]
...
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!
That's what I'm here for. I like loop else clauses, but have to
admit that (a) I rarely use them; (b) most of the time I use them, my
control flow is on the way to becoming so convoluted that I'm going to
rewrite the whole function soon anyway;
Interesting; I usually intentionally write else clauses intending to
*clarify* the code. That is, I often use it in cases where it's not
strictly necessary, e.g.:
for thing in something:
if blah:
return thing
else:
return None
Because to me this clarifies that 'return None' is what happens if the loop
fails. Compare to:
for thing in something:
if blah:
return thing
return None
This looks to me at first glance like code that always returns None after
looping over 'something'.
Of course, these are trivial examples where reading the whole thing isn't a
big deal; I'm more likely to use it when the loop or surrounding logic are
a bit more complex, but I do also use it for fairly simple cases.
The interesting thing is that I think it *clarifies* the intent of the
code, but I guess maybe that's only true for a small subset of Python
programmers.
I suppose I wouldn't raise much of a fuss if the feature went away in 3.0,
but I think I would miss it.
I also suspect that if they weren't in the language already, a PEP to
introduce them would fail, because
still_looking = True
some loop:
if found it:
still_looking = False
break
if still_looking:
# what would have been in the else clause
is clear and easy to write without it.
*shudder* Okay, you just convinced me. Else should stay, because the
above is much less readable and writable!
___
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?
On Thu, Jul 07, 2005, Guido van Rossum wrote: OTOH I don't particularly like code that requires flag variables; they often make me squirm because the same condition (flag) is tested multiple times where it could be tested just once if more sophisticated flow control (e.g. an else clause :) was available. That's what I use try/except for. ;-) -- 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 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?
[Guido van Rossum] On 7/7/05, François Pinard [EMAIL PROTECTED] wrote: [Guido van Rossum] I even wonder if else-clauses on for/while were a good idea. I surely find them useful, and see them as a Python originality (a welcome one). The question remains whether Python would be easier to learn without them. Some of my co-workers, while being very dedicated and efficient to the production duties, are not especially fond on computer languages, and have only moderate pleasure learning them. They are very good people nevertheless! :-) After PL/I, C, some obscure languages you do not even know, and now Python, they receive it as just yet another in the series, and they accept taming themselves, slowly, around Python. I saw that the `else:' clause to `for' and `while' has been a surprise to them, and observe that they usually do not readily recognise cases where it would be useful. Yet, others in the gang are more enthusiastic, and they do not trip at all over various `else:'s. So, it much depends on the kind of relation between programmers and languages. You know, Python would be easier to learn without all `__xyz__' methods, and without meta-classes :-). [Yet my feeling is that people overdo the difficulty of meta-classes, which do not deserve the prejudice they got.] The learning curve of `else:' is much smoother by comparison. `else:' _are_ useful in my experience, as I know I used stunts for years in other languages for achieving about the same effect. These are for elementary or basic day-to-day algorithms, and I cannot believe common problems are so different between a programmer and another. All hard to assess impartially! Granted. That's why I throw my opinion in this forum. -- François Pinard http://pinard.progiciels-bpi.ca ___ 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?
[Guido] OTOH I don't particularly like code that requires flag variables; Me neither; that's indeed why this one isn't a slam dunk. they often make me squirm because the same condition (flag) is tested multiple times where it could be tested just once if more sophisticated flow control (e.g. an else clause :) was available. What burns me (far) more often in practice is simulating a multi-level `break` or `continue`. Then multiple flag variables get introduced, set, and tested multiple times at multiple logical indent levels too. That can also be viewed as stemming from a lack of more sophisticated flow control. One-loop found-it-or-didn't kinds of flag variables have spatial locality that makes them (IME) quite easy to live with, in comparison. How would a PEP to *remove* this feature fare today? Easy: it would be rejected, but with a note that it should be reconsidered for Python 3000. Unhelpfully, your-opposite-in-oh-so-many-wayswink-ly y'rs - tim ___ 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?
On Thu, 2005-07-07 at 14:54, Guido van Rossum wrote: How would a PEP to *remove* this feature fare today? Not well, I hope, although I suppose everything's up for debate in Py3K. Yes, they're rarely used and there is an alternative, but I do find them useful and succinct when they're needed. Also, I don't think they're really much of a burden on newbies because mostly, they just don't encounter them or need to know about them. -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] Chaining try statements: eltry?
[Josiah Carlson] [Guido van Rossum] I even wonder if else-clauses on for/while were a good idea. I had gotten along for 5 years without knowing/remembering there existed an else clause [...] Just throwing a few more cents in. I have been programming (rather successfully) for a few dozens of years without such `else:' clauses, and for example, nearly as long without integrated object orientation. Such things are not mandatory: we all know how to manage without them. It is just that, when such features are known and available, they alleviate programming work, sometimes a bit, sometimes more, depending. Similarly, for anyone reasonable, there is no real urge nor fundamental necessity (bugs excepted) going from Python 2.0 to 2.4. We may undoubtedly enjoy new features once they happen to be there, but could well continue to live a successful programming life without them. `else:' falls in this category. It is nice and helpful to have, but is only one of the now numerous features of Python which are not essential. The fact that we can go without knowing something does not mean that this something is not welcome. Some priests do not know sex! :-) -- François Pinard http://pinard.progiciels-bpi.ca ___ 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?
[Jeremy Hylton] ... PS Every time I switch between Python and C, I get confused about elif and else if. Mostly goes to show that you don't use Perl much ;-) Of course, in C99, #define elif else if is part of stdlib.h. Or maybe it isn't, and it just should have been? One of those -- or close enough. ___ 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?
On 7/7/05, Tim Peters [EMAIL PROTECTED] wrote: [Guido] OTOH I don't particularly like code that requires flag variables; Me neither; that's indeed why this one isn't a slam dunk. they often make me squirm because the same condition (flag) is tested multiple times where it could be tested just once if more sophisticated flow control (e.g. an else clause :) was available. What burns me (far) more often in practice is simulating a multi-level `break` or `continue`. Then multiple flag variables get introduced, set, and tested multiple times at multiple logical indent levels too. That can also be viewed as stemming from a lack of more sophisticated flow control. One-loop found-it-or-didn't kinds of flag variables have spatial locality that makes them (IME) quite easy to live with, in comparison. How would a PEP to *remove* this feature fare today? Easy: it would be rejected, but with a note that it should be reconsidered for Python 3000. Barry also reiterated this idea and I support removing them in Python 3000. I do use them when I want to know when I break out of a loop prematurely, but I am definitely not a typical use case for experienced users since I basically learned how to program in Python so I didn't have any baggage preventing me from not remembering they existed. Simplifying the basic control flow mechanisms is always good. And as Aahz pointed out, you can use exceptions to break out of a loop easily enough and have code for only when you break out with the exception (maybe we should add a ControlFlowException in Py3000 that all other control flow exceptions, like StopIteration inherit from?). In other words they are not critical and not used frequently from what it sounds like. And even in the cases where they are used they can be reworked to not need them without much hassle. -Brett ___ 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] Another SoC student for CVS access
Floris is working on wrapping Hotshot to replace 'profile' and replacing pstats so that there will be no more need for 'profile' and thus take care of the licensing problem. He also hopes to make pstats faster to use. And if we are really lucky, get threading working for Hotshot. It would be great to give him CVS access so he can work in nondist. His username is sirolf . He knows he is not to touch anything outside of his directory in nondist. -Brett ___ 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] Another SoC student for CVS access
On 7/7/05, Brett Cannon [EMAIL PROTECTED] wrote: Floris is working on wrapping Hotshot to replace 'profile' and replacing pstats so that there will be no more need for 'profile' and thus take care of the licensing problem. He also hopes to make pstats faster to use. And if we are really lucky, get threading working for Hotshot. I don't think we actually want to get rid of profile and replace it with hotshot. We want to have both tools available. Jeremy ___ 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] 'With' context documentation draft (was Re: Terminology for PEP 343
Am 07.07.2005 um 20:00 schrieb Guido van Rossum: +1 on @contextmanager +1. [__enter__, __exit__] These names should be changed to __beginwith__ and __endwith__. -1. The PEP has had an extensive review period and several alternatives were discussed and rejected. These names are clear, they *do* match, and as Fred says the __*__ namespace has lots of room. Also, the PEP was accepted with these names. Now, if it was accepted with a major flaw or some semantics left unspecified, What is still unspecified (or at least not explicitely mentioned) in the PEP is the lifetime of VAR in: with EXPR as VAR: BLOCK Does VAR overwrite or shadow any previous values of VAR? I.e. will VAR still exist after the end of the block with its value the return value of __enter__() or will it revert to the previous value (if any)? I'd prefer the later although interpreting the translation of with EXPR as VAR: BLOCK into abc = EXPR exc = (None, None, None) VAR = abc.__enter__() try: try: BLOCK except: exc = sys.exc_info() raise finally: abc.__exit__(*exc) literally would indicate the former. Bye, Walter Dörwald ___ 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] GCC version compatibility
David Abrahams wrote: I'm wondering if there has been a well-known recent change either in Python or GCC that would account for these new reports. Any relevant information would be appreciated. So what about the theory that it may be that different versions of libstdc++ get linked? Python is linked with g++ if configure thinks this is necessary, and the g++ used to link the extension might be different. I'd like to see a backtrace of one such mysterious crash. 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] Chaining try statements: eltry?
How would a PEP to *remove* this feature fare today? I hope not well, since I use them quite often. Barry also reiterated this idea and I support removing them in Python 3000. I do use them when I want to know when I break out of a loop prematurely, but I am definitely not a typical use case for experienced users since I basically learned how to program in Python so I didn't have any baggage preventing me from not remembering they existed. So you're indeed an example that learning them might not be an issue, even when no previous programming experience exists. For the case of an experienced programmer getting into Python as a new language, most of us have been there, and I remember that, when I understood what it was about, I was actually amazed rather than confused. I started wondering why it's not available in other languages. Simplifying the basic control flow mechanisms is always good. [...] Of course, it largely depends on what simplifying means to you. As a side comment, I belive that talking often and at regular intervals about builtins and syntax which may disappear from the language in the next major version is not something good. I understand that the next major is being seen as the place to break legacy compatibility, but that's the kind of thing that you (Guido) are aware that no comments besides personal likes and dislikes will be raised. If you *really* want to remove them (even though I strongly dislike the idea ;-), decide it and get just half of the complaints, rather than getting all of them and spreading FUD. -- Gustavo Niemeyer http://niemeyer.net ___ 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] GCC version compatibility
Martin v. Löwis [EMAIL PROTECTED] writes: David Abrahams wrote: I'm wondering if there has been a well-known recent change either in Python or GCC that would account for these new reports. Any relevant information would be appreciated. So what about the theory that it may be that different versions of libstdc++ get linked? That's been confirmed. Python is linked with g++ if configure thinks this is necessary Right. The question is, when should configure think it's necessary? and the g++ used to link the extension might be different. I'd like to see a backtrace of one such mysterious crash. I don't have it, but ldd confirms that the crash happens when the versions of libstdc++ in python and in the extension module are different. A C++ exception thrown from the extension module into the Boost.Python library to which it is linked (both compiled and linked with the same g++) without passing through any of Python's code (of course) will cause a crash unless Python is using the same libstdc++ as everything else, or unless Python isn't linked with libstdc++. -- 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] Linux Python linking with G++?
Skip Montanaro [EMAIL PROTECTED] writes: I believe it's so that people can link in libraries written in C++ and have them initialized properly. Dave Can you give specifics? What do you mean by link in? Do you Dave mean statically link into the Python interpreter, or something Dave else? Probably not. I'm not a C++ guy. My understanding is that global (maybe static?) C++ objects need the help of C++'s version of crt0 to get properly initialized at program start. Yes. If there is some library with such objects that happens to get wrapped and dynamically linked into a Python interpreter Whoa there. How would that ever happen under ordinary circumstances? Doesn't Python's makefile control what gets linked to Python? that was linked with a regular C linker (and thus had a C crt0), that initialization wouldn't happen. Right, and linking would fail, IIRC. It seems to me that if someone decides to build a wacky Python executable that links in C++ code directly, they can afford to use a configure option. There's no need to punish all the other writers of C++ extension modules out there by tying the default build of Python to a particular version of libstdc++. Dave Boost.Python is a library written in C++ and I've never had Dave trouble using it with a Python executable... until I ran into a Dave Python that was linked with libstdc++! Sorry, I can't help. I'm just recounting my remembering of the reasons for C++ linkage. Personally, I avoid C++ as much as I can... If there's someone around here who is responsible for this change and knows its real rationale, can (s)he please tell me what it is? If not, can we please change things back so Python doesn't get linked to the C++ runtime by default? Thanks, -- 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] Another SoC student for CVS access
On 7/7/05, Jeremy Hylton [EMAIL PROTECTED] wrote: On 7/7/05, Brett Cannon [EMAIL PROTECTED] wrote: Floris is working on wrapping Hotshot to replace 'profile' and replacing pstats so that there will be no more need for 'profile' and thus take care of the licensing problem. He also hopes to make pstats faster to use. And if we are really lucky, get threading working for Hotshot. I don't think we actually want to get rid of profile and replace it with hotshot. We want to have both tools available. This is mainly for backup if the original 'profile' is not available. Debian, for instance, leaves out 'profile' because of its licensing. I don't plan on removing 'profile' from CVS or anything. -Brett ___ 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?
On Thu, Jul 07, 2005 at 03:03:35PM -0400, Phillip J. Eby wrote:
At 02:48 PM 7/7/2005 -0400, Tim Peters wrote:
[Guido, on {for,while}/else]
...
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!
That's what I'm here for. I like loop else clauses, but have to
admit that (a) I rarely use them; (b) most of the time I use them, my
control flow is on the way to becoming so convoluted that I'm going to
rewrite the whole function soon anyway;
Interesting; I usually intentionally write else clauses intending to
*clarify* the code. That is, I often use it in cases where it's not
strictly necessary, e.g.:
for thing in something:
if blah:
return thing
else:
return None
Because to me this clarifies that 'return None' is what happens if the loop
fails.
I use else similarly, for defensive programming.
for (thing) in searchlist:
if (matches(thing)):
keeper = thing
break
else:
raise ValueError(No thing matches())
I can't say I use it for much else, if I really want a default I do
found = None
for (thing) in searchlist:
if (matches(thing)):
found = None
break
That could end with 'else: found = None' to assign a default but I like
the default to come first for readability.
-Jack
___
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] Another SoC student for CVS access
On Thu, 2005-07-07 at 16:30, Brett Cannon wrote: Floris is working on wrapping Hotshot to replace 'profile' and replacing pstats so that there will be no more need for 'profile' and thus take care of the licensing problem. He also hopes to make pstats faster to use. And if we are really lucky, get threading working for Hotshot. Speaking of hotshot, I think we may have fixed SF bug #900092. I'm going to upload a patch to that tracker item momentarily -- anyone care to proof read it? If so, let me know and I'll assign the issue to you (or you can just take it). We fixed it about 10 minutes ago and have only done minimal testing so far, but I'm going to upload it anyway. -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: David Abrahams wrote: Apparently Python on some linux distros is being linked by g++ rather than gcc, resulting in the C++ runtime library being linked into Python; this has bad consequences for compatibility between C++ extension modules and Pythons that have been built with different versions of GCC. Is this behavior intentional? It's as Skip says. According to the C++ standard, a C++ program is one where all translation units are written in C++. While most platforms offer interoperability between C and C++ in the sense that C libraries can be linked into C++ programs, interoperability in the other direction is not always supported, i.e. C programs may not be able to use C++ libraries. This is the specific case you are talking about: Python is written in C, yet the extension might be written in C++. The C++ standard doesn't cover interoperability with 'C', or dynamic linking (we on the C++ committee are working to fix that, but for now that is the case) and it doesn't cover dynamic loading without linking, which is what happens when Python loads an extension written in C++. You can't appeal to the standard for the rules about what needs to be done. All this stuff is entirely implementation-dependent. Now, on some of these implementations, things can be fixed by writing main() as a C++ translation unit, and compiling it with the C++ compiler. Then, Python itself is a C library to this C++ program, and the extension modules are C++ libraries. Then everything works fine. C++ extension modules work fine even when main() is a 'C' program on Linux/GCC. The only reason that main would have to be a C++ program on this platform and compiler is if there were C++ translation units _linked_ into it (not loaded as in with dlopen). Since whoever writes the Makefile for Python also controls what's being linked into it, there's no reason to speculate and make Python a C++ program based on what might be linked in. To support this, main() must be a C++ program. Python compiles main using the C++ compiler if configure thinks this is necessary. Doing so is necessary for example on systems using the G++ collect2 mechanism for static initializers: compiling main with g++ leads to a call to __main(), which is then created by collect2. Extension modules that get loaded with dlopen don't get their static initializers run by __main() anyway. configure thinks that using CXX for linking is necessary if compiling a program using CXX and linking it using CC fails. That might be the right thing to do for some programs, but AFAICT that's the wrong logic to use for Python. -- 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] Linux Python linking with G++?
Jeff Epler [EMAIL PROTECTED] writes: If we change the linker back to gcc, not g++, will it work if extension module 1 gets linked with libstdc++ A and ABI Q, and extension module 2 gets linked with libstdc++ B and ABI Z? Yes, unless they are using sys.setdlopenflags to force symbols to be shared across these extension modules. That's a very intentional act and should (obviously?) only be undertaken when the extension modules share an ABI. What if a built-in module is written in C++, as it might be for some people embedding C++? Embedding usually refers to embedding a _Python_ interpreter in a program written in some language other than Python. But I think that's what you meant (just correct me if I'm wrong). (this will force use of g++ as the linker, right?) Yes. Don't these cases matter too? Yes. But the 2nd case is not one in which the Python executable is being built. The person building a program that embeds Python can control how (s)he does linking. Assuming they can fail now, how will changing the use of CXX as the linker fix them? I don't understand the question. Jeff PS The Python 2.3 and Python 2.4 binaries installed on my Fedora Core machine don't list libstdc++ in `rpm -q --requires python' or `ldd /usr/bin/python'. I don't see a patch that would change Python's behavior in the SRPM, though. I wonder what the difference is between my FC2 and the other systems... I don't know; the ones we happen to be testing are Debian (sarge, I think). -- 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] checklist for filing a bug
In order to lower the barrier for reporting bugs, writing patches, and handling CVS commits, I am writing up checklists for each and I will put them up on python.org. The first checklist is for bug reports. All comments welcome. Keep in mind the list is supposed to be short and straight-forward; too wordy and people won't read it. Reporting a Bug +++ For technical question for any step listed, refer to the `dev FAQ`_. #. Make sure the bug is reproducible The bug cannot be a freak occurence and must be reproducible so developers can test against it. #. Isolate bug Come up with a code snippet that is as succinct as possible that triggers the bug consistently. Coding it as a unit test is the best. #. Gather important information Info such as Python version, operating system version, etc.; anything that might have influenced the code that lead to the bug. #. Report the bug on SourceForge_ Create a new tracker item, filling out the ``Category`` and ``Group`` fields. Do not set the ``Assigned To`` or ``Priority`` fields. Upload your code snippet as a file and make sure to click the ``Upload`` button! .. _dev FAQ: http://www.python.org/dev/devfaq.html .. _SourceForge: http://sourceforge.net/tracker/?group_id=5470atid=105470 ___ 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++?
Jeff Epler wrote: If we change the linker back to gcc, not g++, will it work if extension module 1 gets linked with libstdc++ A and ABI Q, and extension module 2 gets linked with libstdc++ B and ABI Z? The problem is that it won't link at all. Compiling Modules/ccpython.o using g++ creates (in some installations) a reference to libgcc functions that won't be resolved unless you also link using g++. This is because libgcc was split into two libraries, and only one of them gets automatically linked when linking with gcc; the missing symbol is in the other library which only gets linked automatically when linking with g++. What if a built-in module is written in C++, as it might be for some people embedding C++? (this will force use of g++ as the linker, right?) Right. If those people also use dynamic extensions, they should make sure that those link against the same libstdc++. PS The Python 2.3 and Python 2.4 binaries installed on my Fedora Core machine don't list libstdc++ in `rpm -q --requires python' or `ldd /usr/bin/python'. I don't see a patch that would change Python's behavior in the SRPM, though. I wonder what the difference is between my FC2 and the other systems... One solution/work-around is to configure Python with --without-cxx. Then ccpython.cc won't be used, and all compiling and linking is done using gcc. Whether or not this would still allow for extension modules to use C++ depends on the platform; on Linux, it will. I believe Linux distributors normally build Python with --without-cxx. 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
