Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #38732 > unrolled thread
| Started by | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| First post | 2013-02-12 06:15 +0000 |
| Last post | 2013-02-13 00:22 -0700 |
| Articles | 4 on this page of 44 — 18 participants |
Back to article view | Back to comp.lang.python
Awsome Python - chained exceptions Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-12 06:15 +0000
Re: Awsome Python - chained exceptions Terry Reedy <tjreedy@udel.edu> - 2013-02-12 10:13 -0500
Re: Awsome Python - chained exceptions Zero Piraeus <schesis@gmail.com> - 2013-02-12 14:01 -0400
Re: Awsome Python - chained exceptions Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-12 19:01 -0800
Re: Awsome Python - chained exceptions Ian Kelly <ian.g.kelly@gmail.com> - 2013-02-14 00:00 -0700
Re: Awsome Python - chained exceptions alex23 <wuwei23@gmail.com> - 2013-02-14 16:10 -0800
Re: Awsome Python - chained exceptions Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-12 19:01 -0800
Re: Awsome Python - chained exceptions Ethan Furman <ethan@stoneleaf.us> - 2013-02-12 10:15 -0800
Re: Awsome Python - chained exceptions Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-12 18:47 -0800
Re: Awsome Python - chained exceptions Michael Torrie <torriem@gmail.com> - 2013-02-12 21:18 -0700
Re: Awsome Python - chained exceptions Chris Angelico <rosuav@gmail.com> - 2013-02-13 17:58 +1100
Re: Awsome Python - chained exceptions Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-13 08:14 -0800
Re: Awsome Python - chained exceptions Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-13 08:19 -0800
Re: Awsome Python - chained exceptions Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-13 08:19 -0800
Re: Awsome Python - chained exceptions Chris Angelico <rosuav@gmail.com> - 2013-02-14 09:10 +1100
Re: Awsome Python - chained exceptions Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-14 06:39 +0000
Re: Awsome Python - chained exceptions Serhiy Storchaka <storchaka@gmail.com> - 2013-02-15 20:51 +0200
Re: Awsome Python - chained exceptions Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2013-02-14 13:01 +0100
Re: Awsome Python - chained exceptions Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-14 18:56 -0800
Re: Awsome Python - chained exceptions Chris Angelico <rosuav@gmail.com> - 2013-02-15 17:18 +1100
Re: Awsome Python - chained exceptions Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-14 23:51 -0800
Re: Awsome Python - chained exceptions Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2013-02-15 10:00 +0100
Re: Awsome Python - chained exceptions Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-14 23:51 -0800
Re: Awsome Python - chained exceptions alex23 <wuwei23@gmail.com> - 2013-02-17 17:35 -0800
Re: Awsome Python - chained exceptions Dave Angel <davea@davea.name> - 2013-02-17 20:48 -0500
Re: Awsome Python - chained exceptions Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-17 21:51 -0800
news.gmane.org (was Re: Awsome Python - chained exceptions Terry Reedy <tjreedy@udel.edu> - 2013-02-18 01:10 -0500
Re: news.gmane.org (was Re: Awsome Python - chained exceptions rurpy@yahoo.com - 2013-02-18 09:12 -0800
Re: news.gmane.org (was Re: Awsome Python - chained exceptions Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-18 18:32 +0000
Re: news.gmane.org (was Re: Awsome Python - chained exceptions Terry Reedy <tjreedy@udel.edu> - 2013-02-18 17:45 -0500
Re: news.gmane.org (was Re: Awsome Python - chained exceptions Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-18 06:30 +0000
Re: news.gmane.org (was Re: Awsome Python - chained exceptions Kwpolska <kwpolska@gmail.com> - 2013-02-18 16:27 +0100
Re: Awsome Python - chained exceptions alex23 <wuwei23@gmail.com> - 2013-02-18 18:18 -0800
Re: Awsome Python - chained exceptions rurpy@yahoo.com - 2013-02-19 07:52 -0800
Re: Awsome Python - chained exceptions rusi <rustompmody@gmail.com> - 2013-02-19 09:14 -0800
Re: Awsome Python - chained exceptions alex23 <wuwei23@gmail.com> - 2013-02-19 22:57 -0800
Re: Awsome Python - chained exceptions Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-02-20 22:50 +1100
Re: Awsome Python - chained exceptions Rotwang <sg552@hotmail.co.uk> - 2013-02-20 16:00 +0000
RE: Awsome Python - chained exceptions "J. Marc Edwards" <marc.edwards@nimbisservices.com> - 2013-02-20 11:08 -0500
Re: Awsome Python - chained exceptions rurpy@yahoo.com - 2013-02-20 08:13 -0800
Re: Awsome Python - chained exceptions Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-02-20 18:49 -0500
Re: Awsome Python - chained exceptions Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-02-20 18:47 -0500
Re: Awsome Python - chained exceptions Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-13 08:14 -0800
Re: Awsome Python - chained exceptions Michael Torrie <torriem@gmail.com> - 2013-02-13 00:22 -0700
Page 3 of 3 — ← Prev page 1 2 [3]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2013-02-20 18:49 -0500 |
| Message-ID | <mailman.2133.1361404189.2939.python-list@python.org> |
| In reply to | #39366 |
On Wed, 20 Feb 2013 08:13:22 -0800 (PST), rurpy@yahoo.com declaimed the
following in gmane.comp.python.general:
>
> I think very few ISPs provide Usenet access these days.
One of the two main reasons I stick with Earthlink DSL (though since
the DSL path is provided by AT&T hardware, it is very flaky and slow)
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2013-02-20 18:47 -0500 |
| Message-ID | <mailman.2132.1361404058.2939.python-list@python.org> |
| In reply to | #39353 |
On Wed, 20 Feb 2013 22:50:18 +1100, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> declaimed the following in
gmane.comp.python.general:
> Or if your ISP provides Usenet access, you can use a News client to read it
> via comp.lang.python, or gmane.comp.python.general. If you don't have a
> News client, there are various free ones available, starting with
> Thunderbird.
>
Even if the ISP doesn't have Usenet servers itself, the gmane
newsgroups are available from the gmane NNTP server: news.gmane.org
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/
[toc] | [prev] | [next] | [standalone]
| From | Rick Johnson <rantingrickjohnson@gmail.com> |
|---|---|
| Date | 2013-02-13 08:14 -0800 |
| Message-ID | <mailman.1747.1360777232.2939.python-list@python.org> |
| In reply to | #38812 |
On Wednesday, February 13, 2013 12:58:46 AM UTC-6, Chris Angelico wrote:
> On Wed, Feb 13, 2013 at 1:47 PM, Rick Johnson wrote:
> >On Tuesday, February 12, 2013 12:15:29 AM UTC-6, Steven D'Aprano wrote:
> >> If you've ever written an exception handler, you've probably written a
> >> *buggy* exception handler:
> >>
> >> def getitem(items, index):
> >> # One-based indexing.
> >> try:
> >> return items[index-1]
> >> except IndexError:
> >> print ("Item at index %d is missing" % index - 1) # Oops!
> >>
> >>
> >> Unfortunately, when an exception occurs inside an except or finally
> >> block, the second exception masks the first, and the reason for the
> >> original exception is lost:
> >>
> >> py> getitem(['one', 'two', 'three'], 5) # Python 2.6
> >> Traceback (most recent call last):
> >> File "<stdin>", line 1, in <module>
> >> File "<stdin>", line 6, in getitem
> >> TypeError: unsupported operand type(s) for -: 'str' and 'int'
> >
> > Which (by showing the offensive line) is quite clear to me.
>
> No, the offending (not offensive) line is "return items[index-1]",
> which doesn't feature in your traceback at all.
Do you realize that you are quoting DeAprano and not me? Whether you realize this fact or not, consider the next two questions.
Q1: How could a line in the "try" block ever be considered
offensive? Because it throws an error? Are you serious?
Q2: Why would the line in the try block be shown as
a "feature" of the traceback when the whole intent of
exception handling is to hide the error in the try
block! If you want to raise the exception in the try block
then you place a naked raise statement in the exception
block, BUT THEN, why even wrap the code in a try/except
in the first damn place!?
Man, you and DeAprano must be cut from the same block; or more correctly, carved by the same shaky hand of a creator suffering the late-stage effects of Alzheimers disease.
> It DOES, however,
> feature in the Py3.1 double traceback (it's listed as line 4)..
>
> > 1. You are using the print function (so we can assume you are using Python 3.x)
>
> He is? Could just as easily be the print statement with a single
> argument, with unnecessary parentheses around that argument. Which, if
> I recall correctly, is one of the recommended approaches for making
> 2/3 bi-compatible code.
Really?
Because if he did in-fact write the print statement using parenthesis (in some foolish attempt to make his code forward-compatible) that would mean i should add /another/ coding abomination to my earlier list of abominations. The proper method of using a forward compatible print function is by /importing/ the feature.
from future import print_function
> No. Definitely not. Percent interpolation isn't going anywhere - core
> devs have said so - and there are many occasions when it is at least
> as well suited to the task as .format() is.
In other words: Screw consistency and to hell with the zen?
> Also, it's a notation
> that's well understood *across languages* and in a variety of message
> interpolation systems. Anyone who's worked with *any* of them will
> understand that %s inserts a string, %d a number (in decimal), etc,
Oh yes, because indexing the list of arguments in the format method is SO much more overhead! Heck, Python>=2.7 (read the docs for exact release number) will allow you to implicitly pass the index:
print "{} is one more than {}".format("five", "four") # 3.something
...is equivalent to:
print "{0} is one more than {1}".format("five", "four")
...but what about when you need to substitute the /same/ substring in more than one location? Using the old nasty interpolation you are foced to write this:
print "Chris is a %s who is very %s-ish"%('troll', 'troll')
...ewwww yuck! String.format() to the rescue!
print "Chris is a {0} who is very {0}-ish".format('troll')
In fact all of these posted examples work in Python>=2.7.
So the moral is: You can pass no indexes and the format method will intuit the indexes from their linear position in the string, or you can pass indexes and be explicit (plus you can reference a value more than once!), or you can choose one of the many other great options available of the format method.
http://docs.python.org/2/library/string.html#format-string-syntax
> etc. Granted, the exact details after that may change (eg Python has
> %r to emit the representation, while Pike uses %O for "any object",
> with similar notation), but the format specifiers and modifiers that
> came from C are fairly stable, readable, and compact.
The fact is that "str.format(args)" beats the pants off string interpolation any day and anybody arguing for keeping string interpolation is not thinking clearly (especially when they first claim consistency between languages and them expose that claim as a lie) and is also anti-pythonic! To continue to propagate foolish language designs simply because other people have been brainwashed by them is, well, foolish. Would you propagate propaganda using the same excuse?
> In what way is a trivial example like this improved by the use of
> format()? The ONLY thing I can think of is that, by forcing you to put
> parentheses around the argument,
You think the only difference between string.format() and string interpolation is parenthesis? Chris, just because you don't understand how to use str.format() (or interpolation!) correctly does not mean other python programmers are unable too.
> it avoids the issue from the original
> post, which is one of operator precedence - but that's something
> that's fairly easy to spot when you know what you're looking for, and
> is definitely not specific to string formatting.
So as you say: str.format() solves a bug in the code, but that is not enough excuse to stop using the old cryptic and bug inducing interpolation syntax. I see[1].
[1] Read as: "I see that you are a lost cause". Hopefully you will grow a brain and read the format docs, and then try to apply it in your code, then MAYBE you will understand why i support str.format as the only method to format a string.
PS: Why do keep posting email addresses on the list? Does your client not trim, or at least warn, about these?
[toc] | [prev] | [next] | [standalone]
| From | Michael Torrie <torriem@gmail.com> |
|---|---|
| Date | 2013-02-13 00:22 -0700 |
| Message-ID | <mailman.1741.1360740139.2939.python-list@python.org> |
| In reply to | #38800 |
[Multipart message — attachments visible in raw view] — view raw
On Feb 13, 2013 12:00 AM, "Chris Angelico" <rosuav@gmail.com> wrote: > Which word? "we"? I'm not entirely sure, given that non-monospaced > fonts get in the way. Normally people would put exactly as many > carets/tildes as there are letters in the word, but aligning the text > in a mono font puts the carets under "we", so that clue isn't there. Sorry I assumed that on a technical list like this one folks would be viewing emails as the internet gods intended, in a nice monospace font. I don't see how leading carets would help in a proportional font; it just doesn't work well for quoting emails I think. Maybe that's why email from html clients seem to do a lot of top posting and ditch quoting (and I fear reading) emails all together. Apologies if the quoted stuff is messed up in this email. Darn phones are not good at doing proper emailing.
[toc] | [prev] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | comp.lang.python
csiph-web