pep 8 nameing convention for packages and modules

[Rudi Hammad]

Hi,
so I guess that in the end every one has his one logical way for the nomenclature. pep 8 says that packages should always be lowercase with no underscore, and module lowercase with underscore if needed.
I have a package call rbskeleton, "rb" stands for rig builder. And the module is name skeleton. and the class inside the module is Skeleton .(or  I could also name the class BuildSkeleton to add som variety , I don´t know)
I have then

import rbskeleton.skeleton as rbs
mySkeleton = rbs.Skeleton()

I don´t like repeating all the time skeleton, but there is no other way to describe it. what do you thing? Do you follow pep 8 convention on packages and modules

[yury nedelin]

You could use Build instead of Skeleton.
This would make sense since you already have skeleton in the rbskeleton, then you will have rbs.Build()
It would also work well with other functions like rbs.Destroy()

--
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 emails from it, send an email to python_inside_maya+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/f6a528d2-d2ee-4cfa-9c9c-dbe8beda6bf6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Rudi Hammad]

hmmm, interesting.
But a class named Skeleton is more descriptive than Build.
I might be overthinking all that, but I am curious about it.

[Alok Gandhi]

But a class named Skeleton is more descriptive than Build.

Of ourse it is, but only if you do not have a namespace context. 

I totally agree with Yury here. Your namespace already qualifies what Build class is, so you do not have to worry about the context.

Always remeber - Namespaces are one honking great idea. And PEP 8, should be followed whenever it is possible.

I would recommend a great talk by Brandon Rhodes on this very topic, who succintly and efficiently covers most of the naming methodologies. I think this talk also covers what you are trying to solve.

I do not know how are modules are setup or what your code does, but from what I can read, I would suggest something like this:

package name : rigbuilder

module name : skeleton

class name : Build

Also you can put in the __init__.py of top directory of the package

 __all__ = [skeleton, ...... etc.]

for the all modules that you want to expose.

So now there are few options for the client code, depending on how they want to use:

import rigbuilder

mySkeleton = rigbuilder.skeleton.Build()

or

from rigbuilder import skeleton

mySkeleton = skeleton.Build()

or

from rigbuilder.skeleton import Build as SkeletonBuilder

mySkeleton = SkeletonBuilder()

and lastly, though not recommended

from rigbuilder import *

mySkeleton = skeleton.Build()

On Sun, Sep 25, 2016 at 2:58 AM, Rudi Hammad <rudih...@gmail.com> wrote:

hmmm, interesting.
But a class named Skeleton is more descriptive than Build.
I might be overthinking all that, but I am curious about it.

El sábado, 24 de septiembre de 2016, 19:47:28 (UTC+1), ynedelin escribió:

You could use Build instead of Skeleton.
This would make sense since you already have skeleton in the rbskeleton, then you will have rbs.Build()
It would also work well with other functions like rbs.Destroy()

On Sep 24, 2016 12:20 PM, "Rudi Hammad" <rudih...@gmail.com> wrote:

Hi,
so I guess that in the end every one has his one logical way for the nomenclature. pep 8 says that packages should always be lowercase with no underscore, and module lowercase with underscore if needed.
I have a package call rbskeleton, "rb" stands for rig builder. And the module is name skeleton. and the class inside the module is Skeleton .(or  I could also name the class BuildSkeleton to add som variety , I don´t know)
I have then

import rbskeleton.skeleton as rbs
mySkeleton = rbs.Skeleton()

I don´t like repeating all the time skeleton, but there is no other way to describe it. what do you thing? Do you follow pep 8 convention on packages and modules

--
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 emails from it, send an email to python_inside_maya+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/f6a528d2-d2ee-4cfa-9c9c-dbe8beda6bf6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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 emails from it, send an email to python_inside_maya+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/1ca75171-3b86-4dc1-939f-ad35c0337ad2%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

[Justin Israel]

I think "Build" is a strange name for a class though, since it implies an action such as something a function should do. But calling a class means calling its contructor. Would a more appropriate name be "Builder" since a class would be a collection of logic that can be used to build a Skeleton? Because... once you make an instance of your Build class...you have a... Build instance?

To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/f6a528d2-d2ee-4cfa-9c9c-dbe8beda6bf6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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 emails from it, send an email to python_inside_m...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/1ca75171-3b86-4dc1-939f-ad35c0337ad2%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

--

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 emails from it, send an email to python_inside_m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPaTLMTagdxQr2cMtbh8YUVTat%3D0f0%3Dsskkz4A_rwvb9-JAWQg%40mail.gmail.com.

[Alok Gandhi]

I think "Build" is a strange name for a class

@justin: I agree 100%, taking my word back, Builder is anyday a better name that Build for a class, I think I was focussing more on the package naming conventions as whole not just the class.

And here's the more precise rule -

"Class names should nouns, method names should be verbs". This should work in almost all cases, though there be a corner case where this is not possible, but I think mostly it is. 

@rudi: Ask these questions before naming:

• What does the package do - Provides functionality only for creating a skeleton object or it does more than that. Is there an expectation for the package to grow in future, will it provide more functionality etc. 
  
• 
  
• What does the module `skeleton` contains - Does it contain only one class for building the skeleton object or it has some other interface fucntions, other classes etc. for doing some other stuff. If yes, then what could be collectively those utilities called.
  
• 
  
• And more importantly - What does the class `Skeleton` actually do. Does it serve to build or construct a `Skeleton` object, which might be another class - if so then this class is factory, name it `SkeletonBuilder`. If this class is the skeleton object itself, then you have named it correctly. It's name SHOULD be `Skeleton`. So Skeleton(), creates a Skeleton object and that is fine. If the class has other alternate constructors (other than __init__()), probably implemented as @classmethods than you can name them either starting with 'from....' or 'create' whatever you want to.
  

- Alok

To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/f6a528d2-d2ee-4cfa-9c9c-dbe8beda6bf6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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 emails from it, send an email to python_inside_maya+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/1ca75171-3b86-4dc1-939f-ad35c0337ad2%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

--
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 emails from it, send an email to python_inside_maya+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPaTLMTagdxQr2cMtbh8YUVTat%3D0f0%3Dsskkz4A_rwvb9-JAWQg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

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 emails from it, send an email to python_inside_maya+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA2JRo0v0OB-F-TNbvCyGrzfnqZna4tws4juB82YG3BYFQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

[Marcus Ottosson]

I agree too.

Based on limited knowledge of what you’re up to, here’s how I might have expected it to look.

from rigbuilder import skeleton
skeleton.build()

• No acronyms
• package and modules are included in how you read the code
• functions for verbs (classes for names of things)

Personally, I might name my package something more interesting and less generic than “rigbuilder”. Like “flame” or “panzar”.

from panzar import skeleton
skeleton.build()

Putting a name on it adds personality and flavour but perhaps more importantly enables other rig builders with different personalities and flavours to coexist with yours. Just a thought!

​

[Rudi Hammad]

wow, I am so glad I asked. It very interesting your points of view, and very clarifying.
Let me be a little more specific, because that might change some things.
I set my maya environment root to a folder called --> rigbuilder. So this is just a folder, no package.
Then inside, I have 3 packages: rbguides, rbskeleton and rbsolutions. Basically I did that because I thought that there are different "themes", but all being part of the rigbuilder. That is with I started al the folder with rb

rbguides has inside a module called guides, with a class called Guides too ( I know, it is not beautifull), and the methods called buildArm(), buildLeg(). All that is to create a primitive locator skeleton reference that would be the first step.

rbskeleton has inside a module called skeleton, with a class called BuildSkeleton and no other methods. I called the class BuildSkeleton because that is what is does. So I would have something like:
import rbskeleton.skeleton as rbs
arm = rbs.BuildSkeleton('....the guides locators arguments here...")

So at this point I have an object arm, that has a lot of attributoes, so I can do arm.fullDist, arm.side, arm.vectors, arm.campName, arm.segmentsDist etc...etc... I though it would be interesting because then, I can use all this data in what is comming. ( That is my approach to OOP, but of course I will later use polymorphisms, inheritance etc...But I think that creating an object with usefull data attributes is a good way of using OOP, because I don´t have to rewrite the same code each time in every functions , and also, I don´t need to specify the same arguments in the functions. For instance, if my object as the attribute side ( arm.side), in the rest of the methods, I just have to write : blablabla = self.side + blalala , so the method doesn´t have the side argument, because it already knows "what I am talking about") <<== sorry, I went off on a tangent. This is a competently different subject

And finally the package rbsolutions that have inside more packages like: basics, rigs etc... so this package would be the one that , once the skeleton of the rig is done, will add all the solutions, so each solutions is a module, such as rigarm.py, legarm.py, legarm_betatest.py, etc, etc...

So as you can see it is a modular rig builder I am working on, that I structured in the 3 packages. The first one creates the refpoints, the second creates the skeleton, and the third creates all the solutions for the rig.
By the way, what do you call the folder that hold the packages. Does it have a name

thanks

[Marcus Ottosson]

Consider how it would affect the readability of your project if you:

a) removed the rb prefix and
b) made each class into a module

At the moment, rb is used as a namespace. In languages such as C, you need those to avoid nameclashes and to make your code look readable. But Python has a nicer way of representing namespaces already, with a dot. And your classes are verbs, which suggests to me that instantiating it “does something”, rather than “becomes something”.

For example, instead of:

from guides import Guides
guides = Guides()
guides.create_guides()

You could write:

import guides
guides.create()

In fact, I might encourage you to remove all of your classes entirely, and see what becomes of it.

​

[Rudi Hammad]

yes, the rb prefix is annoying. I think it makes more cense put all the modules together intead of diferent packages. So the main package would be rigbuilder, and the modules would be guides and skeleton. I will maintain solutions as a package tough.
(I can' t  remove classes because the code is OOP. I learned from the past when I should avoid classes if I can do the same in a simple module, but here is not the case)

I like the .create_guides() better than createGuides(), although it is not "forbidden" to use capital letters according to pep-8 in methods.
I try to respect pep-8, but something are crazy. The 80 characters per line, is definitely crazy, at least for maya. When you have a names all the time like 'L_armA_shoulder_fk_JNT_parentConstraint", 80 characters makes you called a lot longer, because you
have to go to the next line all the time. In the end, after testing with  80, 100, and 120, I decided to go with 120. It is what works best I think. A lot of hard core programmers that I´ve woked with, don´t give a f*** about pep-8, and the are amazing programmers.
So I try to stay in a middle ground. Following all pep-8 rules makes you slave, and you spend more time thinking about the design, that the actual code I think.

[Marcus Ottosson]

About style, that is all fine. But if you're in a team, maybe try to think less about what you prefer, and consider the preference of those reading, and potentially maintaining your code.​

Even amazing programmers will appreciate having their preference considered.

[Alok Gandhi]

The 80 characters per line, is definitely crazy

When I started programming in python (and that was about 10 years ago) I thought the same. More so, when we have four spaces per indent. But then, now I am completely comfortable with 80 characters per line. There are ways to get your code to look more beautiful (and readable of course)  with 80 characters. And believe me, sometimes I have stuff that is easily 200 lines long if not formatted but I do get around by changing a few things here and there. At my work, we follow the 80 chars limit though it is not  strictly forced and sometimes I see code more than 120 characters per line. There is a big debate going on in all sorts of camps, Google, for example, uses four spaces per indent (the last I know) and there was a huge cry for 2 spaces per indent, but I think I did not happen so far.

There is a rationale going around that says that 80 characters per line were good in the old days when we did not have displays capable of handling more but that is not the case these days so why not go over 80. Well, this is not the only reason that code should be wrapped in 80 characters. The real reason is - Any line, to be read without causing a much cognitive burden on the reader, should not be more than 75 characters long according to some studies. This is more about written languages like English, but then the same applies. I would argue more, in a programming language. People (and for that matter even you ) read your code and they have to figure out what that piece of code is trying to achieve. If a line is too long, the visual noise compromises readability.

The first Zen of python is - "Beautiful is better than ugly". When Guido implemented scopes using indented space instead of curly braces (or other braces for that matter) and line endings without ";", it was meant for making code beautiful and readable. That is the philosophy of python and that's what makes it beautiful.

So, how do you make your code look good and readable within 80 characters per line guidelines? Here are a few things you can do:

1. Break early with the function:

# When faced with this
def a_very_big_fucntion_name(some_big_argument_name, another_big_argument, and_yet_another_huge_argument_name, this_seems_to_end_nowehere, what_should_I_do_with_these_arguments):
    pass

# Do this
def a_very_big_fucntion_name(
    some_big_argument_name,
    another_big_argument,
    and_yet_another_huge_argument_name,
    this_seems_to_end_nowehere,
    what_should_I_do_with_these_arguments,
    ):
    pass

2. Use () whenever needed:

# Instead of this
condition = some_condition_that_is_very_long == long_condition and another_very_long_condition == another_long_condition or yet_another_long_condition != short_condition

# Do this
condition = (
    some_condition_that_is_very_long == long_condition and
    another_very_long_condition == another_long_condition or
    yet_another_long_condition != short_condition
    )

3. Inside strings too:

# Instead of this
raise ValueError("Some error that is so huge that it cannot be wrapped up in 80 characters. You have to show full error message otherwise it is not worth reporting at all. What to do now!")

# Do this
msg = ("Some error that is so huge that it cannot be wrapped "
    "up in 80 characters. You have to show full error message"
    " otherwise it is not worth reporting at all. What to do now!") 
raise ValueError(msg)

 

Of course, there are many other things like naming your variables shorted when possible, breaking logic in two lines etc.

A lot of hard core programmers that I´ve woked with, don´t give a f*** about pep-8

That is true but sad. If you care about your code, if you respect beauty and aesthetics (and we should being in the entertainment industry), if you want other people to understand your code, if you consider that programming is an art, and if you think that good graphic design evokes right kind of emotions and has good bearing over the audience, then you should follow some graphic design principles even in your code. A lot of thought has gone into PEP-8 and there is a reason for its existence - To make code look good and resolve to clarity in the face of ambiguity. The whole idea behind high-level languages was to make code readable and understandable so that we can benefit from it, otherwise, we would have been writing machine and assembly till date. PEP-8 is a guiding principle and you should force yourself to follow it, your code will definitely become beautiful.

On Sun, Sep 25, 2016 at 7:13 PM, Marcus Ottosson <konstr...@gmail.com> wrote:

About style, that is all fine. But if you're in a team, maybe try to think less about what you prefer, and consider the preference of those reading, and potentially maintaining your code.​

Even amazing programmers will appreciate having their preference considered.

--

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 emails from it, send an email to python_inside_maya+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOCH5a4hW7QY8wZAS8PQngbJur%3DpEYCrGfPHP5gFtCwiig%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

[Rudi Hammad]

Your explanation is very reasonable. I try to write code in a beautiful and readable  way always,

This is a test to compare.

PEP-8

class MyClass(object):

    def someMethod(
        some_big_argument_name,
        another_big_argument,
        and_yet_another_huge_argument_name
        ):

       cmds.parentConstraint('L_armA_shoulder_fk_JNT',
                            'L_armA_shoulder_fk_JNT', mo=1, sr=1,
                             n='L_armA_shoulder_fk_parentConstraint')

Now with 120 char

class MyClass(object):
 
   def someMethod(some_big_argument_name, another_big_argument,and_yet_another_huge_argument_name):

        cmds.parentConstraint('L_armA_shoulder_fk_JNT', 'L_armA_shoulder_fk_JNT', mo=1, sr=1,
                              n='L_armA_shoulder_fk_parentConstraint')

from my point of view, 120 char reads better, and it is twice smaller. And I don´t think it is uglier.
I don´t know. I might be wrong

[Marcus Ottosson]

I like strawberry.

I think strawberry is the best flavour. It tastes good, has the right nutrition and makes every dish I make taste good too.

For my family of 10, I will make strawberry meals all day because it is what I prefer.

I don't care about what the others like, because they don't share my taste. I think they are wrong. But they will eat it nonetheless, because they have no choice.

---

Now replace "strawberry" with something you don't like - assuming you like strawberry - and put yourself in place of one of the 10 in my family.

Strawberry isn't wrong. But tastes differ, and best you can do is cook something that the largest amount of family members will like.

[Alok Gandhi]

Strawberry isn't wrong. But tastes differ, and best you can do is cook something that the largest amount of family members will like.

@marcus: My apologies but I fail to get the point. Is it for or against the use of PEP-8? 

--

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 emails from it, send an email to python_inside_maya+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmODaYsxN6Xd88c2mVNq_%3Dg2h_pKa90RPLMHmPf1bLaBtbA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

[Alok Gandhi]

And I don´t think it is uglier

Both are readable for sure, I agree, 120 is not bad at all. It is good to see that you put some thought not only what your code does but also how does it look.

Just another piece of advise - For the perspective of version control system in particular, there is a huge implication in using

 class MyClass(object):

    def someMethod(
        some_big_argument_name,
        another_big_argument,
        and_yet_another_huge_argument_name,  # Note the ',' (not technically needed)
        ):

Instead of

class MyClass(object):

def someMethod(some_big_argument_name, another_big_argument,and_yet_another_huge_argument_name):

am not sure how much version control you use but when you add that extra trailing ',' in the last argument, you are future proofing for adding extra argument in propective which will be detected by the version control more clearly:

Here version control system will report that one line was changed and another added 

- and_yet_another_huge_argument_name

+ and_yet_another_huge_argument_name,

+ some_new argument,

)

as compared to more clear (here the version control system will that only one line was added),

and_yet_another_huge_argument_name,

+ some_new argument

)

The same goes for lists, sets and dictionaries as python allows for a trailing comma at the end of last argument/element. This is the most important reason for it.

But in the end, the whole idea is to be readable, and as beautiful as possible. I am not advocating excessive use of PEP-8 (I am surely not PEP-8 police, actually far from it), my emphasis is more on using PEP-8 to your advantage. Each coder has a personal and distinctive style, so much that sometimes I can look at the code and know the person who wrote it before even running `git blame` on a file. As coders, the onus of writing good readable code lies on the author, for the benefit of those who will it read it later (sometimes even the author himself) and we should write every piece of code being constantly aware of that fact. 

[Marcus Ottosson]

If you have chosen the style, such as strawberry, preferred by the highest percentage of your family, then you are doing it right. :)

strawberry: 7/10  <- winner!
pear: 2/10
marmite: 1/10

​

[Rudi Hammad]

Thanks Alok.

See, some people think that, because they have a lot experience and talent(like marcus, and obviously he is very talented), they have they right to insult, using sarcastic comments, the people who are learning and asking questions.
( or maybe it is just with me, who knows). I am very stupid. So I have to ask and doubt the rules, no matter how many people follow them. In this forum, there are gods, that will just trash my opinion because I am nobody.
Thank you for taking the time to explain in a reasonable way all that, and not trashing my point of view with sarcasm.

I don´t think I will write in this forum anymore. I am sick of arrogance in programmers.
But I want to thank all of you, who helped me when I have doubts(Justin,Cesar, Alok, and many more I am forgetting). Thanks guys

cheers.

[Justin Israel]

Hey Rudi

On Mon, 26 Sep 2016, 4:45 AM Rudi Hammad <rudih...@gmail.com> wrote:

Thanks Alok.

See, some people think that, because they have a lot experience and talent(like marcus, and obviously he is very talented), they have they right to insult, using sarcastic comments, the people who are learning and asking questions.
( or maybe it is just with me, who knows). I am very stupid. So I have to ask and doubt the rules, no matter how many people follow them. In this forum, there are gods, that will just trash my opinion because I am nobody.

I had to scan back through the comments to find what you were referring to. I do completely value your feelings and how responses have affected you. Though I feel there may have been some miscommunication here. I do see some analogies being made to choosing a style that may or may not be what you like but may cover the preference of a large enough sample of people to be acceptable. It is possible that the use of the analogy may not have translated well and caused feelings of insult. I'm hoping that no one had any malicious intent here, such as a cause to want to belittle you. 

We definitely have no gods here in this forum. That is maybe a term those might use to embellish the difference in years of experience between different members. But we should strive to take part in discussions as equal colleagues in the related industries. As an example, while some may see me as a member that offers a lot of assistance on general programming, I know almost nothing about rigging aside from basic terminologies. You are far more experienced in this area than I am and I would likely need to call on you or others with more experience than me, should I ever need to solve a rigging problem. 

Fortunately we have a pool of talent on this forum. 

Thank you for taking the time to explain in a reasonable way all that, and not trashing my point of view with sarcasm.

I don´t think I will write in this forum anymore. I am sick of arrogance in programmers.
But I want to thank all of you, who helped me when I have doubts(Justin,Cesar, Alok, and many more I am forgetting). Thanks guys

I surely hope this isn't the end of your participation on this forum. Your questions also help to serve those that may not feel comfortable posting. Or to help future visitors that search the history. 

--

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 emails from it, send an email to python_inside_m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/ea187457-11d7-4a34-acb7-434dec3a790c%40googlegroups.com.

[Alok Gandhi]

Thanks Alok.
See, some people think that, because they have a lot experience and talent(like marcus, and obviously he is very talented), they have they right to insult, using sarcastic comments, the people who are learning and asking questions.
( or maybe it is just with me, who knows). I am very stupid. So I have to ask and doubt the rules, no matter how many people follow them. In this forum, there are gods, that will just trash my opinion because I am nobody. 

Thank you for taking the time to explain in a reasonable way all that, and not trashing my point of view with sarcasm.
I don´t think I will write in this forum anymore. I am sick of arrogance in programmers.
But I want to thank all of you, who helped me when I have doubts(Justin,Cesar, Alok, and many more I am forgetting). Thanks guys

cheers.

@rudi: I think Marcus' analogy was to provide an alternative way of thinking about the whole thing. I don't think that he was trying to belittle anyone. Knowledge acquisition is a life long process and you never stop learning. I try to learn new things every day and there so much that I don't know. As Justin has pointed, all of us have experience in the different aspects of our craft and the whole idea is to share knowledge between ourselves so each one of us can grow. I, for one, by no means consider myself an expert by any means, neither am I, I am just a learner at the most. I encourage you to continue sharing your knowledge on the forum.

[Justin Israel]

This issue has been sorted, off-thread.

As for an un-answered question previously asked.... 

The name for a directory that contains packages would also still be called a package. That package contains sub-packages.

 

--
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 emails from it, send an email to python_inside_m...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPaTLMR%2B_bcXF93%3DB%3DgiABopTPGSGg3bhqCP%3D-yzvvgOUrDG8Q%40mail.gmail.com.