Well I am not sure what advantage this has for the user, not my code as
I don't advocate the import to begin with it, its fine spelled as it was
from where it was...
The advantage for the user is:
/snip
Hey Steven,
Sorry for the late reply (travelling). My comment wasn't clear, I was
I see that you've solved your immediate problem, but you shouldn't call
__setattr__ directly. That should actually be written
setattr(bar, 'a_new_name', MyError)
But really, since bar is (apparently) a module, and it is *bar itself*
setting the attribute, the better way is
On Wed, 14 May 2014 09:21:50 +, Joseph L. Casale wrote:
I see that you've solved your immediate problem, but you shouldn't call
__setattr__ directly. That should actually be written
setattr(bar, 'a_new_name', MyError)
But really, since bar is (apparently) a module, and it is *bar
On Wed, May 14, 2014 at 11:08 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
One should code as if the next person who reads your program is an easily
upset psychotic axe-murderer who knows where you live. You wouldn't
condone writing y = x.__add__(1) instead of y = x + 1, you
I am working with a module that I am seeing some odd behavior.
A module.foo builds a custom exception, module.foo.MyError, its done right
afaict.
Another module, module.bar imports this and calls bar.__setattr__('a_new_name',
MyError).
Now, not in all but in some cases when I catch a_new_name,
On Wed, May 14, 2014 at 2:59 AM, Joseph L. Casale
jcas...@activenetwerx.com wrote:
During handling of the above exception, another exception occurred:
File C:/dir/test.py, line 12, in module
except a_new_name as exc:
TypeError: catching classes that do not inherit from BaseException is
Best would be to print out what's in a_new_name to see if it really is
what you think it is. If you think it is what you think it is, have a
look at its __mro__ (method resolution order, it's an attribute of
every class), to see what it's really inheriting. That should show you
what's
On Tue, 13 May 2014 16:59:46 +, Joseph L. Casale wrote:
I am working with a module that I am seeing some odd behavior.
A module.foo builds a custom exception, module.foo.MyError, its done
right afaict.
Another module, module.bar imports this and calls
bar.__setattr__('a_new_name',
Charles Hixson wrote:
On 06/25/2012 12:48 AM, Steven D'Aprano wrote:
Catch any exception is almost certainly the wrong thing to do, almost
always.
This time it was the right thing
No, it wasn't. If you hadn't caught it, Python would have printed it
out for you, along with the full
On 06/25/2012 12:48 AM, Steven D'Aprano wrote:
On Sun, 24 Jun 2012 16:16:25 -0700, Charles Hixson wrote:
But what I wanted was to catch any exception.
Be careful of what you ask for, since you might get it.
Catch any exception is almost certainly the wrong thing to do, almost
On Jun 28, 10:13 am, Charles Hixson charleshi...@earthlink.net
wrote:
On 06/25/2012 12:48 AM, Steven D'Aprano wrote:
Catch any exception is almost certainly the wrong thing to do, almost
always.
This time it was the right thing, as I suspected that *SOME* exception
was being thrown, but
On Wed, 27 Jun 2012 17:13:00 -0700, Charles Hixson wrote:
On 06/25/2012 12:48 AM, Steven D'Aprano wrote:
On Sun, 24 Jun 2012 16:16:25 -0700, Charles Hixson wrote:
But what I wanted was to catch any exception.
Be careful of what you ask for, since you might get it.
Catch any
(You posted privately to me again; I hope you don't mind my responding
on-list as this appears to have been merely oversight.)
On Wed, Jun 27, 2012 at 5:25 AM, Charles Hixson
charleshi...@earthlink.net wrote:
Only thing is, this whole mess started when I was trying to trace down and
expected
On 26/06/2012 22:36, Chris Angelico wrote:
(You posted privately to me again; I hope you don't mind my responding
on-list as this appears to have been merely oversight.)
On Wed, Jun 27, 2012 at 5:25 AM, Charles Hixson
charleshi...@earthlink.net wrote:
Only thing is, this whole mess started
On 6/25/2012 12:27 AM, Charles Hixson wrote:
The documentation section covering the except statement could stand to
be a *LOT* clearer. I read the sections on the except statement and
exception handlers several times and couldn't figure out was the as
argument of the except statement was
On Sun, 24 Jun 2012 18:45:45 -0400, Dave Angel wrote:
Bare exceptions are the bane of
programming; Using it is like trying to learn to drive while
blindfolded.
+1 QOTW
I really wish bare exceptions were removed from Python 3. There's no
point to try...except any longer, and it's just an
On Sun, 24 Jun 2012 16:16:25 -0700, Charles Hixson wrote:
But what I wanted was to catch any exception.
Be careful of what you ask for, since you might get it.
Catch any exception is almost certainly the wrong thing to do, almost
always. The one good reason I've seen for a bare except is to
On Mon, 25 Jun 2012 09:51:15 +1000, Chris Angelico wrote:
Mind you, I think every programmer should spend some time debugging
blind.
You're a cruel, cruel man.
I suppose next you're going to say that every programmer should spend
some time programming using Notepad as their only editor.
On Mon, Jun 25, 2012 at 5:49 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info wrote:
On Mon, 25 Jun 2012 09:51:15 +1000, Chris Angelico wrote:
Mind you, I think every programmer should spend some time debugging
blind.
You're a cruel, cruel man.
I suppose next you're going to say
On 06/24/2012 11:23 PM, Andrew Berg wrote:
On 6/25/2012 12:27 AM, Charles Hixson wrote:
The documentation section covering the except statement could stand to
be a *LOT* clearer. I read the sections on the except statement and
exception handlers several times and couldn't figure out was
On Tue, Jun 26, 2012 at 1:14 AM, Charles Hixson
charleshi...@earthlink.net wrote:
I read that that would happen, but print (sys.exc_info()[:2]) didn't
even yield a blank line. It must have executed, because the print statement
on the line before it executed, and there wasn't a loop or a
The code:
print(pre-chunkLine)
chunks=[]
try:
chunks=self.chunkLine (l)
except:
print(caught exception)
print (sys.exc_info()[:2])
Sorry, I left out:
er$ python3 --version
Python 3.2.3rc1
On 06/24/2012 03:26 PM, Charles Hixson wrote:
The code:
print(pre-chunkLine)
chunks=[]
try:
chunks=self.chunkLine (l)
except:
On Mon, Jun 25, 2012 at 8:26 AM, Charles Hixson
charleshi...@earthlink.net wrote:
The code:
finally:
print (at finally)
print (chunks =)
produces this result:
path 3...
Can you state more clearly the problem, please? I'm seeing output that
On 24/06/2012 23:26, Charles Hixson wrote:
The code:
print(pre-chunkLine)
chunks=[]
try:
chunks=self.chunkLine (l)
except:
print(caught exception)
On 06/24/2012 06:30 PM, Charles Hixson wrote:
Sorry, I left out:
er$ python3 --version
Python 3.2.3rc1
On 06/24/2012 03:26 PM, Charles Hixson wrote:
The code:
print(pre-chunkLine)
chunks=[]
try:
chunks=
On 24/06/2012 23:36, Chris Angelico wrote:
On Mon, Jun 25, 2012 at 8:26 AM, Charles Hixson
charleshi...@earthlink.net wrote:
The code:
finally:
print (at finally)
print (chunks =)
produces this result:
path 3...
Can you state more clearly the
On 06/24/2012 03:43 PM, MRAB wrote:
On 24/06/2012 23:26, Charles Hixson wrote:
The code:
print(pre-chunkLine)
chunks=[]
try:
chunks=self.chunkLine (l)
except:
On Mon, Jun 25, 2012 at 9:16 AM, Charles Hixson
charleshi...@earthlink.net wrote:
But what I wanted was to catch any exception. A problem was happening and I
had no clue as to what it was. (It turned out to be self is not defined.
A silly mistake, but a real one.)
The odd thing was that if
On 06/24/2012 07:16 PM, Charles Hixson wrote:
On 06/24/2012 03:43 PM, MRAB wrote:
On 24/06/2012 23:26, Charles Hixson wrote:
SNIP
Don't use a bare except; it'll catch _any__exception. Catch only what
you expect.
For all I know, it could be that the name l doesn't exist.
But what I wanted
On 06/24/2012 03:43 PM, Charles Hixson wrote:
On 06/24/2012 03:36 PM, Chris Angelico wrote:
On Mon, Jun 25, 2012 at 8:26 AM, Charles Hixson
charleshi...@earthlink.net wrote:
The code:
finally:
print (at finally)
print (chunks =)
produces
: exception problem
On 24/06/2012 23:26, Charles Hixson wrote:
The code:
print(pre-chunkLine)
chunks=[]
try:
chunks=self.chunkLine (l)
except:
print
Barak, Ron ron.ba...@lsi.com writes:
However, when line 7 is in effect (with line 8 commented out), viz.:
$ cat -n metaclass_test01.py | head
1 #!/usr/bin/env python
2
3 import sys
4 import wx
5 import CopyAndPaste
6
7 class ListControl(wx.Frame, CopyAndPaste):
If
Hi Guys,
Thanks to Michele, Chris, Hrvoje et. al. who helped me trying to resolve the
metaclass exception when a class has two parents problem.
This post tries to unify all the metaclasses exception threads, in an attempt
to reach a solution.
I've created a short demo script
$ cat -n metaclass_test01.py | head
1 #!/usr/bin/env python
2
3 import sys
4 import wx
5 import CopyAndPaste
6
7 class ListControl(wx.Frame, CopyAndPaste):
8 #class ListControl(wx.Frame):
9 def __init__(self, parent, id, title, list,
En Mon, 23 Feb 2009 07:32:52 -0200, Barak, Ron ron.ba...@lsi.com
escribió:
$ cat -n metaclass_test01.py | head
1 #!/usr/bin/env python
2
3 import sys
4 import wx
5 import CopyAndPaste
6
7 class ListControl(wx.Frame, CopyAndPaste):
8 #class
Hi,
-Original Message-
From: Tim Golden [mailto:m...@timgolden.me.uk]
Sent: Monday, February 23, 2009 11:37
Cc: python-list@python.org; wxpython-us...@lists.wxwidgets.org
Subject: Re: Metaclass conflict TypeError exception: problem
demonstration script
$ cat -n metaclass_test01
Barak, Ron wrote:
That's it.
Once I changed my class header to:
$ cat -n metaclass_test01.py
1 #!/usr/bin/env python
2
3 import sys
4 import wx
5 import CopyAndPaste
6
7 class ListControl(wx.Frame, CopyAndPaste.CopyAndPaste):
I'm getting no more
38 matches
Mail list logo
