Re: Awsome Python - chained exceptions

[rurpy]

On 02/20/2013 04:50 AM, Steven D'Aprano wrote:
>[...]
> 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.

I think very few ISPs provide Usenet access these days.  
All the local ISPs in my area dropped Usenet years ago.  
Which leaves most people in the position of paying for 
Usenet access or finding a free Usenet server.  And there
is not much motivation to do either since Usenet itself
seems headed towards extinction (or as close as it gets 
in an era of infinite internet memory.)
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: Awsome Python - chained exceptions

[J. Marc Edwards]

Mark:

I finished the fingerprinting this morning at the local crime bureau here in
Raleigh.  You don't have to wait for Judy Yost to mail the FD-258 FBI form
to you.  Your local crime bureau should have these available.  Judy has to
have the fingerprints in order to open up your electronic application.

Regards, Marc

J. Marc Edwards, Lead Architect

Semiconductor Design Portals

Nimbis Services, Inc.

Cell  - (919) 345-1021

Fax   - (919) 882-8602

Skype - (919) 747-3775

jmarcedwa...@gmail.com

marc.edwa...@nimbisservices.com

 


-Original Message-
From: Python-list
[mailto:python-list-bounces+marc.edwards=nimbisservices@python.org] On
Behalf Of Rotwang
Sent: Wednesday, February 20, 2013 11:01 AM
To: python-list@python.org
Subject: Re: Awsome Python - chained exceptions

On 20/02/2013 11:50, Steven D'Aprano wrote:
>
> [...alternatives to Google...]
>
> 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.

And if it doesn't, you can get free Usenet access that includes most of the
text-only groups (including c.l.p) from eternal-september.org.

   http://www.eternal-september.org/


--
I have made a thing that superficially resembles music:

http://soundcloud.com/eroneity/we-berated-our-own-crapiness
--
http://mail.python.org/mailman/listinfo/python-list


smime.p7s
Description: S/MIME cryptographic signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Awsome Python - chained exceptions

[Rotwang]

On 20/02/2013 11:50, Steven D'Aprano wrote:


[...alternatives to Google...]

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.


And if it doesn't, you can get free Usenet access that includes most of 
the text-only groups (including c.l.p) from eternal-september.org.


  http://www.eternal-september.org/


--
I have made a thing that superficially resembles music:

http://soundcloud.com/eroneity/we-berated-our-own-crapiness
--
http://mail.python.org/mailman/listinfo/python-list

Re: Awsome Python - chained exceptions

[Steven D'Aprano]

alex23 wrote:

> On Feb 20, 3:14 am, rusi  wrote:
>> How do you "revert to old interface"?
>> So far I have managed to keep to the old by
>> - logging out of gmail
>> - reload GG -- now the choice to revert should appear
>>
>> It seems everyone does not get that option
> 
> In an amazing piece of software engineering, you need to accept the
> new interface _before_ the revert to old interface option appears.
> 
> I have to do this at irregular intervals, not entirely sure what
> triggers its decision to foist the new crap onto me. Now I mostly use
> the feedback box to vent my spleen :)

You know, you could always *stop* using their crap. You can easily subscribe
to this as a mailing list. It will work anywhere you have email, in your
familiar mail client.

http://mail.python.org/mailman/listinfo/python-list

If access on any computer with an internet connection is important to you,
the mailing list works fine with Gmail, Hotmail or Yahoo mail.

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.


-- 
Steven

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Awsome Python - chained exceptions

[alex23]

On Feb 20, 3:14 am, rusi  wrote:
> How do you "revert to old interface"?
> So far I have managed to keep to the old by
> - logging out of gmail
> - reload GG -- now the choice to revert should appear
>
> It seems everyone does not get that option

In an amazing piece of software engineering, you need to accept the
new interface _before_ the revert to old interface option appears.

I have to do this at irregular intervals, not entirely sure what
triggers its decision to foist the new crap onto me. Now I mostly use
the feedback box to vent my spleen :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Awsome Python - chained exceptions

[rusi]

On Feb 19, 7:18 am, alex23  wrote:
> On Feb 18, 3:51 pm, Rick Johnson  wrote:
>
> > I apologize for this doubling of my messages and i can assure you i
> > don't do this intentionally. Proper netiquette is very important to me.
> > These double posts are another unfortunate side-effect of using the
> > buggy Google Groups web-face to read/write Usenet. I've sent feedback
> > to the Google Groups long ago and have yet to see any changes or even
> > get any replys.
>
> Weird, I'm using GG too and not seeing any doubling of my messages. I
> have reverted to using the old interface, though, so it might be a
> side-effect of the new version they're hyping, which does seem to have
> been designed by Satan himself (the way they've separated thread view
> from article view is a huge WTF). I've sent a heap of feedback to them
> as well with no response. Google don't really seem to want to hype
> Usenet as anything other than a target for blogspot spam, it appears.

How do you "revert to old interface"?
So far I have managed to keep to the old by
- logging out of gmail
- reload GG -- now the choice to revert should appear

It seems everyone does not get that option
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Awsome Python - chained exceptions

[rurpy]

On 02/18/2013 07:18 PM, alex23 wrote:
>[...]
> Weird, I'm using GG too and not seeing any doubling of my messages. I
> have reverted to using the old interface, though, so it might be a
> side-effect of the new version they're hyping, which does seem to have
> been designed by Satan himself (the way they've separated thread view
> from article view is a huge WTF). I've sent a heap of feedback to them
> as well with no response. Google don't really seem to want to hype
> Usenet as anything other than a target for blogspot spam, it appears.

In their new interface, GG presents a checkbox for cc: addresses in 
the post being replied to.  Unchecking the "cc: pytho...@python.org"
box will prevent the double posts.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Awsome Python - chained exceptions

[alex23]

On Feb 18, 3:51 pm, Rick Johnson  wrote:
> I apologize for this doubling of my messages and i can assure you i
> don't do this intentionally. Proper netiquette is very important to me.
> These double posts are another unfortunate side-effect of using the
> buggy Google Groups web-face to read/write Usenet. I've sent feedback
> to the Google Groups long ago and have yet to see any changes or even
> get any replys.

Weird, I'm using GG too and not seeing any doubling of my messages. I
have reverted to using the old interface, though, so it might be a
side-effect of the new version they're hyping, which does seem to have
been designed by Satan himself (the way they've separated thread view
from article view is a huge WTF). I've sent a heap of feedback to them
as well with no response. Google don't really seem to want to hype
Usenet as anything other than a target for blogspot spam, it appears.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: news.gmane.org (was Re: Awsome Python - chained exceptions

[Terry Reedy]

On 2/18/2013 1:32 PM, Rick Johnson wrote:


2. When positing a new message i must enter my email address and username each
time. The forms are auto-filled for replys but not for new messages. Go figure!


Using the newsreader interface, I get 1 email message per list to verify 
the email address. After that, it is as if I were subscribed. (Some 
mirrored email lists require a subscription at their site, but most 
python.org lists seems not to.) And, of course, Thunderbird fills in 
data for both new messages and replies. I do not know why it would be 
different through the web interface.



3. There is no method to sort the topics by either: "last reply first" or "date
of thread composition". This is probably more suited to a personal newsreader
though.


The monthly archives, which include the current month,
can be accessed by thread, subject, author, or date.
http://mail.python.org/pipermail/python-list/

--
Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

Re: news.gmane.org (was Re: Awsome Python - chained exceptions

[Rick Johnson]

  yahoo.com> writes:
> On 02/17/2013 11:10 PM, Terry Reedy wrote:
> > For at least the 10th time [...]
> 
> And for at least the 11th time, you are wrong.  There are reasons
> (not applicable to everyone but applicable to many) for using
> Google Groups, among others it is more accessible and easier to 
> use for many than a news reader with Gmane.

I will admit that GG's is easier in this respect. 

However, you /can/ read gmane /without/ a newsreader using the "frames and
threads"  or "flat (blog-like)" web-interface. Although, there are a few issues
that are annoying me:

1. When viewing in the "flat" interface style, the text of the messages is so
small i need to squint whilst reading. Of course i can zoom my web browser,
however, then i get a horizontal scroll bar and some of the post text is
unreachable without scrolling (I really hate horizontal scroll bars!). Not to
mention that i will need to adjust the zoom level back to normal when leaving
the site. 

2. When positing a new message i must enter my email address and username each
time. The forms are auto-filled for replys but not for new messages. Go figure!

3. There is no method to sort the topics by either: "last reply first" or "date
of thread composition". This is probably more suited to a personal newsreader
though.

4. (In the blog style interface) the menu of threads uses a font with
insufficient vertical spacing and everything becomes so jammed together that it
is completely unreadable. I will try to change my browsers' font and see if that
solves the issue; although i am quite fond of my current settings!

> There are ways of mitigating some of the worst characteristics of
> GG posts, see 
> 
>   http://wiki.python.org/moin/GoogleGroupsPython

Thanks for this link!



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: news.gmane.org (was Re: Awsome Python - chained exceptions

[rurpy]

On 02/17/2013 11:10 PM, Terry Reedy wrote:
> On 2/18/2013 12:51 AM, Rick Johnson wrote:
>  > if you (or anyone else) would be kind enough to recommend an
>  > alternative to this gawd awful software [google groups],
> ?  i'm all ears. My expectations at minimum are:
> 
> For at least the 10th time, there is little to no excuse for reading and 
> writing python-list thru google-groups. The news.gmane.org mirror has 
> multiple interfaces:

And for at least the 11th time, you are wrong.  There are reasons
(not applicable to everyone but applicable to many) for using
Google Groups, among others it is more accessible and easier to 
use for many than a news reader with Gmane.

That you don't like aspects of the posts produced by GG is fine
(I don't either) but it does not justify posting BS claims -- if 
you want people to use Gmane because *you* don't like reading GG
posts then say so but don't claim that doing so is just as easy 
as GG -- it is not.

There are ways of mitigating some of the worst characteristics of
GG posts, see 

  http://wiki.python.org/moin/GoogleGroupsPython



 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: news.gmane.org (was Re: Awsome Python - chained exceptions

[Kwpolska]

On Mon, Feb 18, 2013 at 7:30 AM, Rick Johnson
 wrote:
> Terry Reedy  udel.edu> writes:
>> For at least the 10th time, there is little to no excuse for reading and
>> writing python-list thru google-groups. The news.gmane.org mirror has
>> multiple interfaces:
>
> [Sent from gmane.comp.python.general]
>
> Yes you have mentioned this before and for some reason i failed to follow your
> advice. I must have fallen into the trap of familiarity. In any event, if this
> message works i shall use gmane from now on. Thanks Terry!
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list

Or something even better: use the Mailman mailing list,
http://mail.python.org/mailman/listinfo/python-list (mirrored to
Usenet).
--
Kwpolska  | GPG KEY: 5EAAEA16
stop html mail| always bottom-post
http://asciiribbon.org| http://caliburn.nl/topposting.html
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: news.gmane.org (was Re: Awsome Python - chained exceptions

[Rick Johnson]

Terry Reedy  udel.edu> writes:
> For at least the 10th time, there is little to no excuse for reading and 
> writing python-list thru google-groups. The news.gmane.org mirror has 
> multiple interfaces:

[Sent from gmane.comp.python.general]

Yes you have mentioned this before and for some reason i failed to follow your
advice. I must have fallen into the trap of familiarity. In any event, if this
message works i shall use gmane from now on. Thanks Terry!


-- 
http://mail.python.org/mailman/listinfo/python-list

news.gmane.org (was Re: Awsome Python - chained exceptions

[Terry Reedy]

On 2/18/2013 12:51 AM, Rick Johnson wrote:
> if you (or anyone else) would be kind enough to recommend an
> alternative to this gawd awful software [google groups],
?  i'm all ears. My expectations at minimum are:

For at least the 10th time, there is little to no excuse for reading and 
writing python-list thru google-groups. The news.gmane.org mirror has 
multiple interfaces:

'''
Information about gmane.comp.python.general
The archive for this list can be read the following ways:

On the web, using frames and threads.
On the web, using a blog-like, flat interface.
Using an NNTP newsreader.
RSS feeds:
All messages from the list, with excerpted texts.
Topics from the list, with excerpted texts.
All messages from the list, with complete texts.
Topics from the list, with complete texts.
'''


* I only like to read the list from the web, i just hate getting
thousands of emails in my inbox.


A newsreader interface does the same. That is what I use.


* I MUST have mono-spaced font (at least as an option).


That is what I have with Thunderbird. I may have told it once to use 
monospace for newsgroups. You might be able to do the same with a web 
browser.



--
Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

Re: Awsome Python - chained exceptions

[Rick Johnson]

On Sunday, February 17, 2013 7:35:24 PM UTC-6, alex23 wrote:

> Any chance you can stop sending to both comp.lang.python _and_ the 
> python-list, given the former is a mirror of the later?

I apologize for this doubling of my messages and i can assure you i don't do 
this intentionally. Proper netiquette is very important to me. These double 
posts are another unfortunate side-effect of using the buggy Google Groups 
web-face to read/write Usenet. I've sent feedback to the Google Groups long ago 
and have yet to see any changes or even get any replys. 

You know, i try to support Google because (for the most part) they are the only 
option to M$ and they "give-back". However, sustaining the last few years of 
them cramming (this and other) buggy software down my throat is starting to 
wear on my patience. 

Not only does this software post the same message twice, it also inserts 
superfluous newlines in quoted text, does not support mono-spaced fonts 
_anymore_, and wraps lines at well over 150 chars! The old groups interface was 
simple, had mono-spaced font, and wrapped lines at reasonable lengths. I am a 
simple kinda guy, and so i really liked the old group interface. :-(

Alex, if you (or anyone else) would be kind enough to recommend an alternative 
to this gawd awful software, i'm all ears. My expectations at minimum are:

 * I only like to read the list from the web, i just hate
   getting thousands of emails in my inbox.

 * I MUST have mono-spaced font (at least as an option).

That's about it. Anything else is just icing really.

PS: To all of you that use the buggy GoogleGroups, please send them feedback 
detailing all of these bugs (and any more that you have experienced!)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Awsome Python - chained exceptions

[Dave Angel]

On 02/17/2013 08:35 PM, alex23 wrote:

On Feb 15, 5:51 pm, Rick Johnson  wrote:
[Ranting nonsense that's appearing in duplicate on usenet]

Any chance you can stop sending to both comp.lang.python _and_ the
python-list, given the former is a mirror of the later?



It might be easier to just tell everyone not to use GoogleGroups.  I 
think it's them that double-up the messages.  The way I control it on my 
end is with a rule that discards all emails addressed to 
comp.lang.pyt...@googlegroups.com


That way I only see the other copy.  There are a few other people who 
double-post, but this gets rid of the vast majority.


--
DaveA
--
http://mail.python.org/mailman/listinfo/python-list

Re: Awsome Python - chained exceptions

[alex23]

On Feb 15, 5:51 pm, Rick Johnson  wrote:
[Ranting nonsense that's appearing in duplicate on usenet]

Any chance you can stop sending to both comp.lang.python _and_ the
python-list, given the former is a mirror of the later?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Awsome Python - chained exceptions

[Serhiy Storchaka]

On 14.02.13 08:39, Steven D'Aprano wrote:

Here is one example of using raise to re-raise an exception you have just
caught:

import errno
paths = ["here", "there", "somewhere else"]
for location in paths:
 filename = os.path.join(location, "prefs.ini")
 try:
 f = open(filename)
 except IOError as e:
 if e.errno != errno.ENOENT:  # File not found.
 raise



In Python 3.3:

try:
f = open(filename)
except FileNotFound:
pass

But not all errnos have special OSError subclasses.


--
http://mail.python.org/mailman/listinfo/python-list

Re: Awsome Python - chained exceptions

[Ulrich Eckhardt]

Am 15.02.2013 08:51, schrieb Rick Johnson:

  "How could a line in the "try" block ever be considered offensive?"

My suggestion of "offensive" does not imply ignorance on /my/ part[...]


Well, it seems to imply that you are not aware of the subtle difference 
between "offending" and "offensive". The irony on that was probably lost 
in my last posting, since you are still repeating this mistake.


Now, concerning the rest, you are relying on too many implications that 
others should draw from what you wrote that are not clear. This doesn't 
help you getting across what you want to say.


Further, you wrote "Which (by showing the offensive line) is quite clear 
to me.", i.e. that there can be "offensive" lines, then you go on to 
"/i/ never suggested that ANY line in ANY block was "offensive"". Those 
two statements just don't fit together, see for yourself which of them 
you want to clarify or not, but please stop blaming others for your slips!


You're welcome.

Uli

--
http://mail.python.org/mailman/listinfo/python-list

Re: Awsome Python - chained exceptions

[Rick Johnson]

On Friday, February 15, 2013 12:18:17 AM UTC-6, Chris Angelico wrote:
> And yet it is still a perfect example of how a line of
> code inside a 'try' block can indeed be offensive.

Oh nice try, but we are not fooled by your straw-man. My exact statement that 
provoked this whole thing was:

"""
Q1: How could a line in the "try" block ever be considered offensive? Because 
it throws an error? Are you serious?
""" 

If you notice, the first sentence is rhetorical. 

 "How could a line in the "try" block ever be considered offensive?"
 
My suggestion of "offensive" does not imply ignorance on /my/ part, but it does 
not necessarily imply ignorance on your part either. Then, in the second 
sentence, I offer a possible answer to the first question in the form of 
another question (asked on your behalf): 

 "Because it throws and error?"
 
Then in my last sentence, i ask another question (in a sarcastic manner) that 
negates the answer you might have given, 

 "Are you serious?"
 
This negation means that /i/ do not find ANY line in a try block to be 
"offensive". In effect, you could reduce the paragraph to this:

 "A line of code in the try block that throws an error is NOT offensive (to 
me)."
 
As you can see from this break-down, /i/ never suggested that ANY line in ANY 
block was "offensive", it was /you/ (by proxy) who suggested it. Now ain't that 
just a pickle! ;-).

> This has nothing to do with exceptions, and everything to
> do with societal practices and acceptable language.

But "offensive" is very subjective my friend! 

I curse quite frequently (especially when i am frustrated). To me, words are 
merely expressions, and when i'm angry i will express myself accordingly. 
However, there are many people who cannot deal with the feelings and images 
that they experience when hearing certain words. And a good argument could be 
made for "limiting strong emotional expressions in the company of strangers" -- 
even /if/ for nothing more than "good manners".

It was for the later reason that i edited this word. And besides, i could toss 
out curse words all day if my only intent was to sensationalize the moment for 
the sake of a few rubber-neckers. Anybody can employ the curse for quick 
attention of fellow fools, however, /real/ intelligence is required to draw a 
witty abstract relationship between two superficially unrelated entities or 
ideas (especially when one entity is tangible and the other is intangible).

> The fact that you edited it out of your quote shows just
> how offensive the expression is. :)

So you present "a curse word that i edited" versus "a rhetorical question i 
made on your behalf", and you claim to have defeated me? Ha, classic straw-man!

> May I ring your schoolbell?

Sure, but only if you use your head as the hammer.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Awsome Python - chained exceptions

[Chris Angelico]

On Fri, Feb 15, 2013 at 1:56 PM, Rick Johnson
 wrote:
> On Thursday, February 14, 2013 6:01:51 AM UTC-6, Ulrich Eckhardt wrote:
>> [...]
>>
>> try:
>>  rrick.go_and_[edit]_yourself()
>> finally:
>>  rrick.get_lost()
>
> Oops, you forgot to catch "FloatingPointError" and so your code choked in the 
> try block -- typical newbie mistake.

And yet it is still a perfect example of how a line of code inside a
'try' block can indeed be offensive. This has nothing to do with
exceptions, and everything to do with societal practices and
acceptable language. The fact that you edited it out of your quote
shows just how offensive the expression is. :)

May I ring your schoolbell?

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Awsome Python - chained exceptions

[Rick Johnson]

On Thursday, February 14, 2013 6:01:51 AM UTC-6, Ulrich Eckhardt wrote:
> [...]
> 
> try:
>  rrick.go_and_[edit]_yourself()
> finally:
>  rrick.get_lost()

Oops, you forgot to catch "FloatingPointError" and so your code choked in the 
try block -- typical newbie mistake.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Awsome Python - chained exceptions

[alex23]

On Feb 14, 5:00 pm, Ian Kelly  wrote:
> 2. If you're going to criticize someone for their spelling, at least
> be sure to spell correctly the name of the person you are addressing.
> You've consistently misspelled Steven's surname in several posts that
> I've noticed.

The correct spelling conflicts with his intuition of how it should be
spelled. Expect a DeApranoWart post any day now.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Awsome Python - chained exceptions

[Ulrich Eckhardt]

Am 13.02.2013 um 17:14 schrieb Rick Johnson:

   Q1: How could a line in the "try" block ever be considered
   offensive? Because it throws an error?


try:
rrick.go_and_fuck_yourself()
finally:
rrick.get_lost()


See, wasn't that difficult, was it? :D



Are you serious?


No, I just couldn't resist this invitation even though I'm making a fool 
of myself responding to flamers/trolls...


*le sigh*

Uli

--
http://mail.python.org/mailman/listinfo/python-list

Re: Awsome Python - chained exceptions

[Ian Kelly]

On Tue, Feb 12, 2013 at 8:01 PM, Rick Johnson
 wrote:
> On Tuesday, February 12, 2013 12:01:45 PM UTC-6, Zero Piraeus wrote:
>
>> You could call them PyW00ts.
>
> +1 on the name
> -INFINITY on the execution
>
> Actually i am happy that DeAprano used the unintuitive tag now. Bad enough to 
> use an unintuitive tag. Worse to misspell it. But it would been a crime to 
> tarnish such an intuitive tag as "PyW00ts" with the clumsy teachings provided.

1. Subject lines are not tags.  If you want to categorize the post
with a tag for later reference, then by all means do so; any halfway
decent reader will let you do this.  It's not up to the post author to
tag posts for you.

2. If you're going to criticize someone for their spelling, at least
be sure to spell correctly the name of the person you are addressing.
You've consistently misspelled Steven's surname in several posts that
I've noticed.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Awsome Python - chained exceptions

[Steven D'Aprano]

On Thu, 14 Feb 2013 09:10:42 +1100, Chris Angelico wrote:

Quoting Rick Johnson:
>>   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!?

Here is one example of using raise to re-raise an exception you have just 
caught:

import errno
paths = ["here", "there", "somewhere else"]
for location in paths:
filename = os.path.join(location, "prefs.ini")
try:
f = open(filename)
except IOError as e:
if e.errno != errno.ENOENT:  # File not found.
raise


> You seriously need to get into the real world and do some actual
> debugging work.

Amen to that brother. What is it that they say?

"Those who can, do. Those who can't, teach. Those who can't teach, write 
rants on the Internet criticising others."


[...]
>>> 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
> 
 import __future__
 __future__.print_function
> _Feature((2, 6, 0, 'alpha', 2), (3, 0, 0, 'alpha', 0), 65536)
> 
> Which works back as far as 2.6 but that's all. Simply putting parens
> around the argument works all the way back to... hmm. Further back than
> I've ever had to support, but then, I only started using Python
> seriously a few years ago. Steven?

Putting parens around the argument to print works going back to at least 
Python 0.9.1, which is before Python had "" delimiters:


steve@runes:~$ ./python0.9.1 
>>> s = "string"
Parsing error: file , line 1:
s = "string"
 ^
Unhandled exception: run-time error: syntax error
>>> s = 'string'
>>> print s
string
>>> print (s)
string

You can always wrap any expression with an extra pair of round brackets.

Of course, the correct way of doing this is with "from __future__ import 
print_function", but really, who cares? It's just a trivial example. If 
the worst criticism someone can make of my example is that I took a short-
cut when printing, I can live with that.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Awsome Python - chained exceptions

[Chris Angelico]

On Thu, Feb 14, 2013 at 3:14 AM, Rick Johnson
 wrote:
> On Wednesday, February 13, 2013 12:58:46 AM UTC-6, Chris Angelico wrote:
>> 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.

I knew who I was quoting.

>   Q1: How could a line in the "try" block ever be considered
>   offensive? Because it throws an error? Are you serious?

You're the one who said offensive. I specifically corrected you to
"offending", which is the appropriate word in that situation.

>   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!?

You seriously need to get into the real world and do some actual
debugging work. Here, let me give you an example of what you might
come across in the real world:

1) The program doesn't exhibit the failure symptoms until it's been
running for a couple of days.
2) Sending the program a SIGHUP influences the symptoms in peculiar ways.
3) The main symptom visible is that something that ought to have 2-3
threads actually has several hundred.
4) Your boss is paranoid about security, so the script files on the
running nodes have all been minified - no comments, no linebreaks,
short variable names, etc.
5) The exact nature of the bug depends on the interactions of up to 12
computers, all running similar code but doing different tasks.

Now tell me, what's the first thing you do? There are many right
answers to this question, but most of them involve one thing: Get more
information. Turn on verbose logging, add a monitoring wrapper, insert
output statements in various places... and make sure your exception
tracebacks give ALL the information.

> 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.

D'Aprano (note, that's a 39 not a 101) and I both happen to have some
real-world experience. A bit of a rough teacher, and the tuition fees
are ridiculously high, but you learn things that aren't taught
anywhere else.

>> 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

>>> import __future__
>>> __future__.print_function
_Feature((2, 6, 0, 'alpha', 2), (3, 0, 0, 'alpha', 0), 65536)

Which works back as far as 2.6 but that's all. Simply putting parens
around the argument works all the way back to... hmm. Further back
than I've ever had to support, but then, I only started using Python
seriously a few years ago. Steven?

>> 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?

Percent interpolation is plenty obvious, it's simple, it's clean, and
you're welcome to hate it if you like. Doesn't bother me.

> ...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')
>
> ...e yuck! String.format() to the rescue!
>
> print "Chris is a {0} who is very {0}-ish".format('troll')

Yeah, in Pike I'd just use %desc;++row)
printf("%-15s%4d%11.2f\n",row->desc,row->count,row->load);

//Pike, direct translation
foreach (data,array row)
write("%-15s%4d%11.2f\n",@row);

//Pike, making use of array-output feature
write("%{%-15s%4d%11.2f\n%}",data);

Note how easily tabulated data can be produced, *across languages*,
with the exact same syntax. Actually, str.format borrows heavily from
printf notation, and I was able to make it look almost the same; all
it does is replace the percent sign with {:}. (Oh, and it defaults to
left-justifying strings, so I don't need the minus sign to do that.
Big deal.)

> (especially when they first claim consistency between languages and them 
> expose that claim as a lie)

I think the comparison above shows 

Re: Awsome Python - chained exceptions

[Rick Johnson]

On Wednesday, February 13, 2013 10:14:34 AM UTC-6, Rick Johnson wrote:
> The proper method of using a forward compatible print
> function is by /importing/ the feature.
> 
>from future import print_function

Urm... of course the proper /PROPER/ way would be to NOT throw an import error! 

from __future__ import print_function

O:-)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Awsome Python - chained exceptions

[Rick Johnson]

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 "", line 1, in 
> >>   File "", 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')

...e 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 peopl

Re: Awsome Python - chained exceptions

[Michael Torrie]

On Feb 13, 2013 12:00 AM, "Chris Angelico"  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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Awsome Python - chained exceptions

[Chris Angelico]

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 "", line 1, in 
>>   File "", 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. 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.

> but then you go and use that old ugly "%" string interpolation syntax crap! 
> when you should have used the format method of strings.
>
> print("Item at index {0} is missing".format(index-1)) # Oops!
>
> ...Oh Steven, if you only knew how we interpreted the "Oops!", more like 
> "Doh!".

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. 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,
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.

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, 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.

ChrisA
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Awsome Python - chained exceptions

[Michael Torrie]

On 02/12/2013 07:47 PM, Rick Johnson wrote:
> ...Oh Steven, if you only knew how we interpreted the "Oops!", more like 
> "Doh!".

"You keep using that word. I do not think it means what you think it means."

> Got any more bright ideas DeAprano? (Oh gawd that felt good!)

Ummm...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Awsome Python - chained exceptions

[Rick Johnson]

On Tuesday, February 12, 2013 12:01:45 PM UTC-6, Zero Piraeus wrote:

> You could call them PyW00ts.

+1 on the name
-INFINITY on the execution

Actually i am happy that DeAprano used the unintuitive tag now. Bad enough to 
use an unintuitive tag. Worse to misspell it. But it would been a crime to 
tarnish such an intuitive tag as "PyW00ts" with the clumsy teachings provided. 
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Awsome Python - chained exceptions

[Rick Johnson]

On Tuesday, February 12, 2013 12:15:29 AM UTC-6, Steven D'Aprano wrote:
> [snip inflammatory remarks]
> I thought I'd present a few of Python's more
> awesome features, starting with exception contexts.

Well that's great idea, however, in order to find this very "valuable" 
information the searcher must not only remember an unintuitive search tag, he 
must also remember /exactly/ how you misspelled the unintuitive search tag! I 
sure hope you have more of these "Awsome Python"'s to share because i fear this 
one will surely be forgotten in 2 days. 

> 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 "", line 1, in 
>   File "", line 6, in getitem
> TypeError: unsupported operand type(s) for -: 'str' and 'int'

But that's exactly what any sane person wants to happen. And i don't know why 
your error messages are so vague because i got this message (using IDLE):

py> getitem([1,2,3], 5)
Traceback (most recent call last):
  File "", line 1, in 
getitem([1,2,3], 5)
  File "", line 5, in getitem
print ("Item at index %d is missing" % index - 1)  # Oops!
TypeError: unsupported operand type(s) for -: 'str' and 'int'

Which (by showing the offensive line) is quite clear to me. I even tried a 
simplified version on the command line (to make sure IDLE was not injecting 
anything) and got a better exception message, but sadly without the offending 
line:

py> try:
... l[10]
... except IndexError:
... "{0}".format(blah)
...
Traceback (most recent call last):
  File "", line 4, in 
NameError: name 'blah' is not defined

But in either case, both forms of the message i got are far more helpful than 
the exception you posted. Did you trim the exception in an attempt to 
sensationalize the problem?

But who cares about the exception message python returned when there are /so/ 
many abominations in this code sample. I mean, i know this is an example, but 
it should not be an example of "how not to code"+"ANYTHING"+"!"*10

Some of the problems include:

1. You are using the print function (so we can assume you are using Python 3.x) 
but then you go and use that old ugly "%" string interpolation syntax crap! 
when you should have used the format method of strings.

print("Item at index {0} is missing".format(index-1)) # Oops!

...Oh Steven, if you only knew how we interpreted the "Oops!", more like "Doh!".

2. Your stdout message is not only confusing, it's a freaking lie! 

"Item at index %d is missing". 

...Steven, i can assure you that if "list[index]" raises an IndexError, the 
item is NOT /missing/. Neither the item OR the index even /exist/ as far as the 
sequence is concerned. Contrary to your naive beliefs, Python sequences are not 
initialized with every possible integer index (that the current machine can 
represent) just sitting around twiddling their thumbs complaining of boredom 
whilst waiting for a value to come along they can point to; can you imagine the 
memory usage of such a design (flaw)?

3. Your claim that the broken code in the "exception block" masks the exception 
that would have been raised by the code in the "try block" is false, because if 
it's true, then you'd better find the fool who told Python to mask the try 
block in the first place!

Got any more bright ideas DeAprano? (Oh gawd that felt good!)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Awsome Python - chained exceptions

[Ethan Furman]

On 02/12/2013 10:01 AM, Zero Piraeus wrote:

On 12 February 2013 02:15, Steven D'Aprano wrote:

As an antidote to the ill-informed negativity of Ranting Rick's
illusionary "PyWarts", I thought I'd present a few of Python's more
awesome features [...]


You could call them PyW00ts.


+1 QOTW

--
http://mail.python.org/mailman/listinfo/python-list

Re: Awsome Python - chained exceptions

[Zero Piraeus]

:

On 12 February 2013 02:15, Steven D'Aprano
 wrote:
> As an antidote to the ill-informed negativity of Ranting Rick's
> illusionary "PyWarts", I thought I'd present a few of Python's more
> awesome features [...]

You could call them PyW00ts.

 -[]z.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Awsome Python - chained exceptions

[Terry Reedy]

On 2/12/2013 1:15 AM, Steven D'Aprano wrote:

As an antidote to the ill-informed negativity of Ranting Rick's
illusionary "PyWarts", I thought I'd present a few of Python's more
awesome features, starting with exception contexts.


You do not need Rick to justify such an informative post.


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 "", line 1, in 
   File "", line 6, in getitem
TypeError: unsupported operand type(s) for -: 'str' and 'int'


But never fear! In Python 3.1 and better, Python now shows you the full
chain of multiple exceptions, and exceptions grow two new special
attributes: __cause__ and __context__.


Some thought was given to having only one special attribute, but in the 
end it was decided to have __context__ be the actual context and 
__cause__ be the programmer set and displayed 'context'.



If an exception occurs while handling another exception, Python sets the
exception's __context__ and displays an extended error message:

py> getitem(['one', 'two', 'three'], 5)  # Python 3.1
Traceback (most recent call last):
   File "", line 4, in getitem
IndexError: list index out of range

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
   File "", line 1, in 
   File "", line 6, in getitem
TypeError: unsupported operand type(s) for -: 'str' and 'int'

Python 3 also allows you to explicitly set the exception's __cause__
using "raise...from" syntax:

py> try:
... len(None)
... except TypeError as e:
... raise ValueError('bad value') from e
...
Traceback (most recent call last):
   File "", line 2, in 
TypeError: object of type 'NoneType' has no len()

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
   File "", line 4, in 
ValueError: bad value

Note the slight difference in error message. If both __cause__ and
__context__ are set, the __cause__ takes priority.

Sometimes you actually want to deliberately catch one exception and raise
another, without showing the first exception. A very common idiom in
Python 2:

try:
 do_work()
except SomeInternalError:
 raise PublicError(error_message)

Starting with Python 3.3, there is now support from intentionally
suppressing the __context__:

py> try:
... len(None)
... except TypeError:
... raise ValueError('bad value') from None  # Python 3.3
...
Traceback (most recent call last):
   File "", line 4, in 
ValueError: bad value

The new features are explained in the Library manual, Ch. 5, Exceptions, 
but without so many clear examples. The 'from None' option has not yet 
been added to the Language reference section on raise statements (an 
issue on the tracker), so it is easy to miss if one does not also read 
the Library chapter.


You can read more about exception chaining here:

http://www.python.org/dev/peps/pep-3134/
http://www.python.org/dev/peps/pep-0409/


--
Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

Awsome Python - chained exceptions

[Steven D'Aprano]

As an antidote to the ill-informed negativity of Ranting Rick's 
illusionary "PyWarts", I thought I'd present a few of Python's more 
awesome features, starting with exception contexts.

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 "", line 1, in 
  File "", line 6, in getitem
TypeError: unsupported operand type(s) for -: 'str' and 'int'


But never fear! In Python 3.1 and better, Python now shows you the full 
chain of multiple exceptions, and exceptions grow two new special 
attributes: __cause__ and __context__.

If an exception occurs while handling another exception, Python sets the 
exception's __context__ and displays an extended error message:


py> getitem(['one', 'two', 'three'], 5)  # Python 3.1
Traceback (most recent call last):
  File "", line 4, in getitem
IndexError: list index out of range

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "", line 1, in 
  File "", line 6, in getitem
TypeError: unsupported operand type(s) for -: 'str' and 'int'



Python 3 also allows you to explicitly set the exception's __cause__ 
using "raise...from" syntax:

py> try:
... len(None)
... except TypeError as e:
... raise ValueError('bad value') from e
... 
Traceback (most recent call last):
  File "", line 2, in 
TypeError: object of type 'NoneType' has no len()

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "", line 4, in 
ValueError: bad value



Note the slight difference in error message. If both __cause__ and 
__context__ are set, the __cause__ takes priority.


Sometimes you actually want to deliberately catch one exception and raise 
another, without showing the first exception. A very common idiom in 
Python 2:


try:
do_work()
except SomeInternalError:
raise PublicError(error_message)


Starting with Python 3.3, there is now support from intentionally 
suppressing the __context__:


py> try:
... len(None)
... except TypeError:
... raise ValueError('bad value') from None  # Python 3.3
... 
Traceback (most recent call last):
  File "", line 4, in 
ValueError: bad value



You can read more about exception chaining here:

http://www.python.org/dev/peps/pep-3134/
http://www.python.org/dev/peps/pep-0409/



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list