>> 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 wa
On Wed, May 14, 2014 at 11:08 PM, Steven D'Aprano
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 shouldn't
> condone writing module
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
> 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
>
> a
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_nam
> 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 hap
On Wed, May 14, 2014 at 2:59 AM, Joseph L. Casale
wrote:
> During handling of the above exception, another exception occurred:
>
> File "C:/dir/test.py", line 12, in
> except a_new_name as exc:
> TypeError: catching classes that do not inherit from BaseException is not
> allowed
Best woul
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,
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 tra
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.
>>
>>
On Jun 28, 10:13 am, 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, as I suspected that *SOME* exception
> was being thrown, but had no idea what one
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
alwa
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
wrote:
Only thing is, this whole mess started when I was trying to trace dow
(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
wrote:
> Only thing is, this whole mess started when I was trying to trace down and
> expected error. (Which turned out t
On Tue, Jun 26, 2012 at 1:14 AM, Charles Hixson
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 jump (and also
> executio
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 th
On Mon, Jun 25, 2012 at 5:49 PM, Steven D'Aprano
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 that every programmer should
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 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 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 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
: exception problem
On 24/06/2012 23:26, Charles Hixson wrote:
> The code:
> print("pre-chunkLine")
> chunks=[]
> try:
> chunks=self.chunkLine (l)
> except:
&
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
wrote:
The code:
finally:
print ("at finally")
print ("chunks =")
produces this result:
path 3...
C
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:
>>>
>>>
>>>
>> 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.
On Mon, Jun 25, 2012 at 9:16 AM, Charles Hixson
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 I ran it without th
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 24/06/2012 23:36, Chris Angelico wrote:
On Mon, Jun 25, 2012 at 8:26 AM, Charles Hixson
wrote:
The code:
finally:
print ("at finally")
print ("chunks =")
produces this result:
path 3...
Can you state more clearly the problem, please? I'm se
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:
>>
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 Mon, Jun 25, 2012 at 8:26 AM, Charles Hixson
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
can't have come fr
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:
The code:
print("pre-chunkLine")
chunks=[]
try:
chunks=self.chunkLine (l)
except:
print("caught exception")
print (sys.exc_info()[:2])
"Barak, Ron" 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 this is
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 Metaclas
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 scr
En Mon, 23 Feb 2009 07:32:52 -0200, Barak, Ron
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 ListControl(wx.Frame):
$ 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, max_list
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 (metaclass_test01.p
38 matches
Mail list logo
