>
> if you are totally closed to the idea of doing something different:
> well... there's no much benefit coming out of a discussion on the subject.
Hey Cesar, au contraire! I very much like the idea of exploration. In fact,
the only reason of carrying on like a broken record :) is to elicit
True, you don't need to enclose the instantiation in a try except if you
don't need to keep executing the program after a bad input, it's fair
enough if that's your goal (although I guess you can see my point when I
mention it in the first place)
Look, It's ok to disagree on styles and all that
>
> It forces the user to enclose any instantiation on a try except
Actually, it doesn't, the try except block was just for demonstration
purposes. The demo will still work without it.
class A(object):
def __init__(self):
raise ValueError('Something bad happened!')
def
Sure you can (although it forces the user to enclose any instantiation on a
try except, but it works). I guess my point is that validation is usually
done in the constructor and not initialisation, creating an instance just
to destroy it later on without doing any work (contributing to solve the
On Sat, Oct 29, 2016 at 2:51 PM Alok Gandhi
wrote:
> What's the "dounder init method"? Did I miss some code somewhere?
>
> I think Cesar is referring to the 'double-underscore' aka 'dunder ' aka
> 'magic methods' aka 'special methods'- def __init__()
>
Oh right.
>
> What's the "dounder init method"? Did I miss some code somewhere?
I think Cesar is referring to the 'double-underscore' aka 'dunder ' aka
'magic methods' aka 'special methods'- def __init__()
On Sat, Oct 29, 2016 at 9:30 AM, Justin Israel
wrote:
>
>
> On Sat, Oct
On Sat, Oct 29, 2016 at 1:41 PM Cesar Saez wrote:
> There's a fundamental problem with this in my view, the dounder init
> method of a class gets executed _after_ the instance (aka self) get
> created, doing checks there means you basically create an object that can
>
There's a fundamental problem with this in my view, the dounder init method
of a class gets executed _after_ the instance (aka self) get created, doing
checks there means you basically create an object that can potentially be
invalid by passing the wrong thing and that's a problem.
You could use
>
> I am not very familiar with using the underscores, in this case, public
> and private variables, as a matter of fact. If you read my code, pretty
> much everything is not of private variables.
Sure, I understand. Please note that nothing is really private in python. There
is nothing to
@Justin
Truth be told, initially I wrote it as:
if self.state == self.STATE_ROOT_SELS:
# Run function_A()
if self.state == self.STATE_USER_SELS:
# Run function_B()
There was no `else` and then before posting my thread, I rewrote it to
using `if...elif...` but am unsure whether if I should
Sorry about the slight typo in the last code I posted, should be
super(HierarchyDialog, self).__init__(parent=parent)
--
You received this message because you are subscribed to the Google Groups
"Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving
Most of what I wanted to comment is already covered by Justin and Marcus.
Here are my very very minor comments (consider them as extras):
1. self._state instead self.state (~ by convention, self.state should be
used only if `state` is public. From your code, and I presume, `state` is
not public.
On Thu, Oct 27, 2016 at 2:16 PM likage wrote:
>
> 2. Is there any chance that I will need to add in an `else` statement
> should the self.state not conform to either `self.STATE_ROOT_SELS` or
> `self.STATE_USER_SELS`? Otherwise, I suppose I can stopped such from
>
>
>
>> 2. Is there any chance that I will need to add in an `else` statement
>> should the self.state not conform to either `self.STATE_ROOT_SELS` or
>> `self.STATE_USER_SELS`? Otherwise, I suppose I can stopped such from
>> happening in the run_dialog function, right?
>
>
Can you raise a
On Thu, 27 Oct 2016, 1:29 PM likage wrote:
> I re-post my message...
>
> @Marcus
> Thanks for the information! Glad to know that I am on track, to be honest,
> I was not able to find much info online, perhaps my searching skill was not
> that great in this aspect :p
>
>
I re-post my message...
@Marcus
Thanks for the information! Glad to know that I am on track, to be honest,
I was not able to find much info online, perhaps my searching skill was not
that great in this aspect :p
@Justin
Thanks for the code. I have decided to use your format for my code.
Even
Slight typo in the doc string, but STACK_SELECTION should be STATE_ROOT_SELS
and USER_SELECTION should be STATE_USER_SELS
On Wednesday, October 26, 2016 at 4:36:05 PM UTC-7, likage wrote:
>
> @Marcus
> Glad to know that I am somewhat on the right track! To be honest, I could
> not find much
@Marcus
Glad to know that I am somewhat on the right track! To be honest, I could
not find much info online, either that or I must have been typing it
wrongly, unable to get a decent result
@Justin
Thanks for the code, decided to implement the way that you have mentioned.
Another quick
I would like some opinions on the way I am using instance variables in my
class as I am not so sure if I am doing it right.. To be honest, this is my
first time using parameters in my class __init__..
class HierarchyDialog(QtGui.QDialog):
def __init__(self, state, parent=None):
19 matches
Mail list logo