>
> 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 some
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 ja
>
> 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 __del__(se
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
pr
>
> 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.
I don
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. It's like those illusion pictur
>
> 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 29, 2016 at 1:41 PM Cesar
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
> potentially be invalid by pa
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 a
>
> 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 prevent
@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 ema
On docstrings, here are some considerations to make.
1. Is there a convention I need to follow? (e.g. within the company,
previous or related code you have written etc.)
2. Do I need/want automatic generation of documentation?
On 2, if you write your docstring in a particular way, then t
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. I
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
> happening in the run_dialog func
>
>
>> 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 Valu
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
>
> @Justin
> Thanks for the c
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 s
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 info
@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 question
On Thu, Oct 27, 2016 at 5:42 AM likage wrote:
> 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):
>
Looks perfectly reasonable to me!
Things I *like*:
1. Your logic is kept separate from your GUI code; it makes me warm
inside knowing that I could use the very same GUI, regardless of its
complexity, for any number of my own logical needs, without having to think
about the internal co
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):
QtGui
23 matches
Mail list logo