Re: [Maya-Python] Optimise this: Hierarchy from String

[Geordie Martinez]

Okay. I know this has probably already been figured out, but I can’t help
myself with puzzles. Marcus I think you were on to the right idea but just
needed to use an OrderedDict with enumerate. here is my stab at it:

import maya.cmds as mcfrom collections import OrderedDictdef
hierarchy_from_string(hierarchy):
stack = OrderedDict()
for line in hierarchy.split("\n"):
if not line:
continue
stack[line.strip()]= len(line) -len(line.strip())
node_stack = stack.keys()
for num,(k,v) in enumerate(stack.iteritems()):
tfm = mc.group(n=k,em=True)
if num:
par_stack = node_stack[:num]
par_stack.reverse()
for pp in par_stack:
if stack[pp] < v:
mc.parent(tfm,pp)
break

return stack

hStr = """\
rig
implementation
geometry
skeleton
interface
controls
preview
"""

hierarchy_from_string(hStr)

this will only work in this current example if there aren’t any duplicate
names.
​

On Fri, Sep 16, 2016 at 11:18 PM, Justin Israel 
wrote:

>
>
> On Sat, 17 Sep 2016, 6:12 PM Alok Gandhi 
> wrote:
>
>> Also I would like to throw my 2 cents in as someone that develops not as
>>> one that writes scripts and tools on a per-show basis to get shots finaled,
>>> but as one that works on longer term projects to serve the ongoing
>>> pipeline. The advise from that conference might be more applicable to
>>> situations like that, where a shot-delivery time frame is not the case. It
>>> really just depends on whether your deliverable is a shot, or software.
>>
>>
>> I agree, I am also employed as a Pipeline Engineer and do not have the
>> pressing need to script  for a single shot but rather develop Pipeline
>> Tools and APIs that are consumed by various departments. I can totally
>> understand where you are coming from and it makes complete sense. I started
>> out as an artist (animator, rigger, and generalist) and then a TD and
>> gradually segway into Pipeline. During this journey, I clearly saw my
>> development focus shift from 'just make it work' to 'make it beautiful and
>> readable'.
>>
>
> 100% agree!
>
>
>> On Sat, Sep 17, 2016 at 1:47 PM, Justin Israel 
>> wrote:
>>
>>>
>>>
>>> On Sat, Sep 17, 2016 at 5:34 PM Alok Gandhi 
>>> wrote:
>>>
 @Justin: I agree with readability trumping performance, and almost at
 all times, I follow almost the same tenets. However, in our trade,
 performance is ever more critical and is becoming important every single
 day. The entertainment industry is one of the major stakeholders when
 it comes to demand for processing power. We need that water to look real,
 10 million polygon processing, we need that. And on top of that, we work on
 deadlines, sometimes unreal. When there is a pressing need to process huge
 amounts of data so that the shot can be approved, we have to do that. And
 it is at such moments, readability might take a back seat. This by no means
 is a justification for ignoring readability but rather the state of
 affairs. There is sometimes a tradeoff involved, sometimes not. You can get
 the best of both the worlds if you have enough time on your hand.

>>>
>>> I appreciate this need. Ultimately we have to deliver shots and meet
>>> deadlines. Ultimately we are in the business of making
>>> Movies/Television/Games/, and not necessarily software.
>>>
>>> But really, it doesn't change the point of the advise from that
>>> conference speaker. Even if performance ends up becoming the primary focus,
>>> then naturally the other points become secondary. And you have to weigh
>>> those decisions, right? Do we need this solution beyond this shot? This
>>> show? Who gets to maintain it? How easy it is to continue to be adapted to
>>> the next challenge.
>>>
>>> Also I would like to throw my 2 cents in as someone that develops not as
>>> one that writes scripts and tools on a per-show basis to get shots finaled,
>>> but as one that works on longer term projects to serve the ongoing
>>> pipeline. The advise from that conference might be more applicable to
>>> situations like that, where a shot-delivery time frame is not the case. It
>>> really just depends on whether your deliverable is a shot, or software.
>>>
>>>

 It is good that we have a growing and healthy open source community,
 with studios investing in making amazing open source projects
 - OpenVDB exr, Alembic, USD etc. to name a few. With neatly written API to
 handle low-level high-processing procedures, all abstracted for the benefit
 of writing clean yet power packed code.

 That's my two cents.

 On Sat, Sep 17, 2016 at 9:15 AM, Justin Israel 
 wrote:

>
>
> On Sat, 17 Sep 2016, 1:09 PM yury nedelin 

Re: [Maya-Python] Optimise this: Hierarchy from String

[Justin Israel]

On Sat, 17 Sep 2016, 6:12 PM Alok Gandhi  wrote:

> Also I would like to throw my 2 cents in as someone that develops not as
>> one that writes scripts and tools on a per-show basis to get shots finaled,
>> but as one that works on longer term projects to serve the ongoing
>> pipeline. The advise from that conference might be more applicable to
>> situations like that, where a shot-delivery time frame is not the case. It
>> really just depends on whether your deliverable is a shot, or software.
>
>
> I agree, I am also employed as a Pipeline Engineer and do not have the
> pressing need to script  for a single shot but rather develop Pipeline
> Tools and APIs that are consumed by various departments. I can totally
> understand where you are coming from and it makes complete sense. I started
> out as an artist (animator, rigger, and generalist) and then a TD and
> gradually segway into Pipeline. During this journey, I clearly saw my
> development focus shift from 'just make it work' to 'make it beautiful and
> readable'.
>

100% agree!


> On Sat, Sep 17, 2016 at 1:47 PM, Justin Israel 
> wrote:
>
>>
>>
>> On Sat, Sep 17, 2016 at 5:34 PM Alok Gandhi 
>> wrote:
>>
>>> @Justin: I agree with readability trumping performance, and almost at
>>> all times, I follow almost the same tenets. However, in our trade,
>>> performance is ever more critical and is becoming important every single
>>> day. The entertainment industry is one of the major stakeholders when
>>> it comes to demand for processing power. We need that water to look real,
>>> 10 million polygon processing, we need that. And on top of that, we work on
>>> deadlines, sometimes unreal. When there is a pressing need to process huge
>>> amounts of data so that the shot can be approved, we have to do that. And
>>> it is at such moments, readability might take a back seat. This by no means
>>> is a justification for ignoring readability but rather the state of
>>> affairs. There is sometimes a tradeoff involved, sometimes not. You can get
>>> the best of both the worlds if you have enough time on your hand.
>>>
>>
>> I appreciate this need. Ultimately we have to deliver shots and meet
>> deadlines. Ultimately we are in the business of making
>> Movies/Television/Games/, and not necessarily software.
>>
>> But really, it doesn't change the point of the advise from that
>> conference speaker. Even if performance ends up becoming the primary focus,
>> then naturally the other points become secondary. And you have to weigh
>> those decisions, right? Do we need this solution beyond this shot? This
>> show? Who gets to maintain it? How easy it is to continue to be adapted to
>> the next challenge.
>>
>> Also I would like to throw my 2 cents in as someone that develops not as
>> one that writes scripts and tools on a per-show basis to get shots finaled,
>> but as one that works on longer term projects to serve the ongoing
>> pipeline. The advise from that conference might be more applicable to
>> situations like that, where a shot-delivery time frame is not the case. It
>> really just depends on whether your deliverable is a shot, or software.
>>
>>
>>>
>>> It is good that we have a growing and healthy open source community,
>>> with studios investing in making amazing open source projects
>>> - OpenVDB exr, Alembic, USD etc. to name a few. With neatly written API to
>>> handle low-level high-processing procedures, all abstracted for the benefit
>>> of writing clean yet power packed code.
>>>
>>> That's my two cents.
>>>
>>> On Sat, Sep 17, 2016 at 9:15 AM, Justin Israel 
>>> wrote:
>>>


 On Sat, 17 Sep 2016, 1:09 PM yury nedelin  wrote:

> Is performance something you are concerned with for this process?
> Yury
>
 Marcus had said it was not a concern. I was just sharing some
 interesting info on the topic of readability and maintainability

> On Sep 16, 2016 6:16 PM, "Justin Israel" 
> wrote:
>
>>
>>
>> On Sat, Sep 17, 2016 at 5:27 AM Alok Gandhi <
>> alok.gandhi2...@gmail.com> wrote:
>>
>>>
>>> Coming back to some of the points that Ian raised:
>>> > Readability is a perfectly valid goal to seek but I
>>> find maintainability is often overlooked.
>>>
>>> IMHO more readable code is more maintainable. Readability goes hand
>>> in hand with maintainability. In fact, I very much agree that code lasts
>>> longer than an author and if you write readable code it will be easier 
>>> to
>>> read and understand for the people after you are gone and are not 
>>> available
>>> to explain why you did what. If by maintainability you meant actually
>>> extensibility, then it is a completely different aspect.
>>>
>>
>> As an aside, I just recently went to a convention, and in one of the
>> 

Re: [Maya-Python] Optimise this: Hierarchy from String

[Alok Gandhi]

>
> Also I would like to throw my 2 cents in as someone that develops not as
> one that writes scripts and tools on a per-show basis to get shots finaled,
> but as one that works on longer term projects to serve the ongoing
> pipeline. The advise from that conference might be more applicable to
> situations like that, where a shot-delivery time frame is not the case. It
> really just depends on whether your deliverable is a shot, or software.


I agree, I am also employed as a Pipeline Engineer and do not have the
pressing need to script  for a single shot but rather develop Pipeline
Tools and APIs that are consumed by various departments. I can totally
understand where you are coming from and it makes complete sense. I started
out as an artist (animator, rigger, and generalist) and then a TD and
gradually segway into Pipeline. During this journey, I clearly saw my
development focus shift from 'just make it work' to 'make it beautiful and
readable'.

On Sat, Sep 17, 2016 at 1:47 PM, Justin Israel 
wrote:

>
>
> On Sat, Sep 17, 2016 at 5:34 PM Alok Gandhi 
> wrote:
>
>> @Justin: I agree with readability trumping performance, and almost at all
>> times, I follow almost the same tenets. However, in our trade, performance
>> is ever more critical and is becoming important every single day. The
>> entertainment industry is one of the major stakeholders when it comes to
>> demand for processing power. We need that water to look real, 10 million
>> polygon processing, we need that. And on top of that, we work on deadlines,
>> sometimes unreal. When there is a pressing need to process huge amounts of
>> data so that the shot can be approved, we have to do that. And it is at
>> such moments, readability might take a back seat. This by no means is a
>> justification for ignoring readability but rather the state of affairs.
>> There is sometimes a tradeoff involved, sometimes not. You can get the best
>> of both the worlds if you have enough time on your hand.
>>
>
> I appreciate this need. Ultimately we have to deliver shots and meet
> deadlines. Ultimately we are in the business of making
> Movies/Television/Games/, and not necessarily software.
>
> But really, it doesn't change the point of the advise from that conference
> speaker. Even if performance ends up becoming the primary focus, then
> naturally the other points become secondary. And you have to weigh those
> decisions, right? Do we need this solution beyond this shot? This show? Who
> gets to maintain it? How easy it is to continue to be adapted to the next
> challenge.
>
> Also I would like to throw my 2 cents in as someone that develops not as
> one that writes scripts and tools on a per-show basis to get shots finaled,
> but as one that works on longer term projects to serve the ongoing
> pipeline. The advise from that conference might be more applicable to
> situations like that, where a shot-delivery time frame is not the case. It
> really just depends on whether your deliverable is a shot, or software.
>
>
>>
>> It is good that we have a growing and healthy open source community, with
>> studios investing in making amazing open source projects - OpenVDB exr,
>> Alembic, USD etc. to name a few. With neatly written API to handle
>> low-level high-processing procedures, all abstracted for the benefit of
>> writing clean yet power packed code.
>>
>> That's my two cents.
>>
>> On Sat, Sep 17, 2016 at 9:15 AM, Justin Israel 
>> wrote:
>>
>>>
>>>
>>> On Sat, 17 Sep 2016, 1:09 PM yury nedelin  wrote:
>>>
 Is performance something you are concerned with for this process?
 Yury

>>> Marcus had said it was not a concern. I was just sharing some
>>> interesting info on the topic of readability and maintainability
>>>
 On Sep 16, 2016 6:16 PM, "Justin Israel" 
 wrote:

>
>
> On Sat, Sep 17, 2016 at 5:27 AM Alok Gandhi 
> wrote:
>
>>
>> Coming back to some of the points that Ian raised:
>> > Readability is a perfectly valid goal to seek but I
>> find maintainability is often overlooked.
>>
>> IMHO more readable code is more maintainable. Readability goes hand
>> in hand with maintainability. In fact, I very much agree that code lasts
>> longer than an author and if you write readable code it will be easier to
>> read and understand for the people after you are gone and are not 
>> available
>> to explain why you did what. If by maintainability you meant actually
>> extensibility, then it is a completely different aspect.
>>
>
> As an aside, I just recently went to a convention, and in one of the
> talks the speaker opened with his list of priorities for designing
> software:
>
> 1. Integrity - The software should operate in a predictable manner,
> respond appropriately to exceptional 

Re: [Maya-Python] Optimise this: Hierarchy from String

[Justin Israel]

On Sat, 17 Sep 2016, 1:09 PM yury nedelin  wrote:

> Is performance something you are concerned with for this process?
> Yury
>
Marcus had said it was not a concern. I was just sharing some interesting
info on the topic of readability and maintainability

> On Sep 16, 2016 6:16 PM, "Justin Israel"  wrote:
>
>>
>>
>> On Sat, Sep 17, 2016 at 5:27 AM Alok Gandhi 
>> wrote:
>>
>>>
>>> Coming back to some of the points that Ian raised:
>>> > Readability is a perfectly valid goal to seek but I
>>> find maintainability is often overlooked.
>>>
>>> IMHO more readable code is more maintainable. Readability goes hand in
>>> hand with maintainability. In fact, I very much agree that code lasts
>>> longer than an author and if you write readable code it will be easier to
>>> read and understand for the people after you are gone and are not available
>>> to explain why you did what. If by maintainability you meant actually
>>> extensibility, then it is a completely different aspect.
>>>
>>
>> As an aside, I just recently went to a convention, and in one of the
>> talks the speaker opened with his list of priorities for designing
>> software:
>>
>> 1. Integrity - The software should operate in a predictable manner,
>> respond appropriately to exceptional conditions, and clean up nicely during
>> a termination
>>
>> 2. Readability - The intent of the code should be clear
>>
>> 3. Simplicity (has to be justified to be more important than #2)
>> 4. Performance
>>
>> He basically yelled at us for 10 minutes about the importance of the
>> first two, and said only when you can prove to me that everything else is
>> addressed, that you should then look at performance. It was a pretty good
>> talk.
>>
>>
>>> > In driving to a solution avoiding the additional markup (as in my
>>> solution or in json/XML) you've likely put yourself (and too often your
>>> team after you've left) in a place where you'll need to rewrite the
>>> function for future feature requests.
>>>
>>> If you read my previous posts in this threads, you will see that I
>>> clearly mentioned that getting input is an administrative logic. In fact, I
>>> provisioned for it and alluded to Marcus about it. Here's what I wrote:
>>>
>>>- Right in the beginning, we parse the string in a single line,
>>>keeping the administrative logic out from the rest of our business code.
>>>You can easily replace this single line with whatever parser you want.
>>>
>>> This means that the code that is responsible for creating nodes should
>>> not worry itself with how it is getting the data in, JSON or YAML. And the
>>> parser, whichever it is, should not worry about what is going to happen to
>>> data it outputs. any good architecture should take care of this point.
>>> Making components decoupled and flexible. Good architecture does not only
>>> apply to huge libraries or big project, it should be given thought to every
>>> single small quantum of code, a function and even inside parts of a
>>> function. I did not avoid the input data structure, I simply did not work
>>> on that part as was not required my Marcus originally. Even then, I
>>> separated the code so that in my implementation, nowhere it does rely on
>>> whether I choose JSON or YAML or some other markup. If ten years later,
>>> somebody wants to use my implementation, with JSON the only change it would
>>> require is to change the first line of my code.
>>>
>>>
>>>
>>> On Sat, Sep 17, 2016 at 12:56 AM, Marcus Ottosson <
>>> konstrukt...@gmail.com> wrote:
>>>
 Thanks Ian!

 Some notes.

 - The implementation is up for grabs, but I'd like to keep the
 interface of the function; that is, passing a single string with
 indentation for hierarchy.
 - Performance is not important here, because (1) the function is only
 being used in example code, where the call itself should fall into the
 background and (2) creating a hierarchy can safely take a few hundred
 milliseconds if it means more readable code.

 --
 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+unsubscr...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/python_inside_maya/CAFRtmODtC8L1BiXxbTOHRH_KwK32ZxRZeo%3DatdrKgdkeThNzRw%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 

Re: [Maya-Python] Optimise this: Hierarchy from String

[yury nedelin]

Is performance something you are concerned with for this process?
Yury
On Sep 16, 2016 6:16 PM, "Justin Israel"  wrote:

>
>
> On Sat, Sep 17, 2016 at 5:27 AM Alok Gandhi 
> wrote:
>
>>
>> Coming back to some of the points that Ian raised:
>> > Readability is a perfectly valid goal to seek but I
>> find maintainability is often overlooked.
>>
>> IMHO more readable code is more maintainable. Readability goes hand in
>> hand with maintainability. In fact, I very much agree that code lasts
>> longer than an author and if you write readable code it will be easier to
>> read and understand for the people after you are gone and are not available
>> to explain why you did what. If by maintainability you meant actually
>> extensibility, then it is a completely different aspect.
>>
>
> As an aside, I just recently went to a convention, and in one of the talks
> the speaker opened with his list of priorities for designing software:
>
> 1. Integrity - The software should operate in a predictable manner,
> respond appropriately to exceptional conditions, and clean up nicely during
> a termination
>
> 2. Readability - The intent of the code should be clear
>
> 3. Simplicity (has to be justified to be more important than #2)
> 4. Performance
>
> He basically yelled at us for 10 minutes about the importance of the first
> two, and said only when you can prove to me that everything else is
> addressed, that you should then look at performance. It was a pretty good
> talk.
>
>
>> > In driving to a solution avoiding the additional markup (as in my
>> solution or in json/XML) you've likely put yourself (and too often your
>> team after you've left) in a place where you'll need to rewrite the
>> function for future feature requests.
>>
>> If you read my previous posts in this threads, you will see that I
>> clearly mentioned that getting input is an administrative logic. In fact, I
>> provisioned for it and alluded to Marcus about it. Here's what I wrote:
>>
>>- Right in the beginning, we parse the string in a single line,
>>keeping the administrative logic out from the rest of our business code.
>>You can easily replace this single line with whatever parser you want.
>>
>> This means that the code that is responsible for creating nodes should
>> not worry itself with how it is getting the data in, JSON or YAML. And the
>> parser, whichever it is, should not worry about what is going to happen to
>> data it outputs. any good architecture should take care of this point.
>> Making components decoupled and flexible. Good architecture does not only
>> apply to huge libraries or big project, it should be given thought to every
>> single small quantum of code, a function and even inside parts of a
>> function. I did not avoid the input data structure, I simply did not work
>> on that part as was not required my Marcus originally. Even then, I
>> separated the code so that in my implementation, nowhere it does rely on
>> whether I choose JSON or YAML or some other markup. If ten years later,
>> somebody wants to use my implementation, with JSON the only change it would
>> require is to change the first line of my code.
>>
>>
>>
>> On Sat, Sep 17, 2016 at 12:56 AM, Marcus Ottosson > > wrote:
>>
>>> Thanks Ian!
>>>
>>> Some notes.
>>>
>>> - The implementation is up for grabs, but I'd like to keep the interface
>>> of the function; that is, passing a single string with indentation for
>>> hierarchy.
>>> - Performance is not important here, because (1) the function is only
>>> being used in example code, where the call itself should fall into the
>>> background and (2) creating a hierarchy can safely take a few hundred
>>> milliseconds if it means more readable code.
>>>
>>> --
>>> 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+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/
>>> msgid/python_inside_maya/CAFRtmODtC8L1BiXxbTOHRH_
>>> KwK32ZxRZeo%3DatdrKgdkeThNzRw%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+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/python_inside_maya/CAPaTLMT8pNLXc4XM7jT4AVQETE37Q
>> 9Z0pGYBBBjYZhYbLDHKMQ%40mail.gmail.com
>> 

Re: [Maya-Python] Optimise this: Hierarchy from String

[Justin Israel]

On Sat, Sep 17, 2016 at 5:27 AM Alok Gandhi 
wrote:

>
> Coming back to some of the points that Ian raised:
> > Readability is a perfectly valid goal to seek but I
> find maintainability is often overlooked.
>
> IMHO more readable code is more maintainable. Readability goes hand in
> hand with maintainability. In fact, I very much agree that code lasts
> longer than an author and if you write readable code it will be easier to
> read and understand for the people after you are gone and are not available
> to explain why you did what. If by maintainability you meant actually
> extensibility, then it is a completely different aspect.
>

As an aside, I just recently went to a convention, and in one of the talks
the speaker opened with his list of priorities for designing software:

1. Integrity - The software should operate in a predictable manner, respond
appropriately to exceptional conditions, and clean up nicely during a
termination

2. Readability - The intent of the code should be clear

3. Simplicity (has to be justified to be more important than #2)
4. Performance

He basically yelled at us for 10 minutes about the importance of the first
two, and said only when you can prove to me that everything else is
addressed, that you should then look at performance. It was a pretty good
talk.


> > In driving to a solution avoiding the additional markup (as in my
> solution or in json/XML) you've likely put yourself (and too often your
> team after you've left) in a place where you'll need to rewrite the
> function for future feature requests.
>
> If you read my previous posts in this threads, you will see that I clearly
> mentioned that getting input is an administrative logic. In fact, I
> provisioned for it and alluded to Marcus about it. Here's what I wrote:
>
>- Right in the beginning, we parse the string in a single line,
>keeping the administrative logic out from the rest of our business code.
>You can easily replace this single line with whatever parser you want.
>
> This means that the code that is responsible for creating nodes should not
> worry itself with how it is getting the data in, JSON or YAML. And the
> parser, whichever it is, should not worry about what is going to happen to
> data it outputs. any good architecture should take care of this point.
> Making components decoupled and flexible. Good architecture does not only
> apply to huge libraries or big project, it should be given thought to every
> single small quantum of code, a function and even inside parts of a
> function. I did not avoid the input data structure, I simply did not work
> on that part as was not required my Marcus originally. Even then, I
> separated the code so that in my implementation, nowhere it does rely on
> whether I choose JSON or YAML or some other markup. If ten years later,
> somebody wants to use my implementation, with JSON the only change it would
> require is to change the first line of my code.
>
>
>
> On Sat, Sep 17, 2016 at 12:56 AM, Marcus Ottosson 
> wrote:
>
>> Thanks Ian!
>>
>> Some notes.
>>
>> - The implementation is up for grabs, but I'd like to keep the interface
>> of the function; that is, passing a single string with indentation for
>> hierarchy.
>> - Performance is not important here, because (1) the function is only
>> being used in example code, where the call itself should fall into the
>> background and (2) creating a hierarchy can safely take a few hundred
>> milliseconds if it means more readable code.
>>
>> --
>> 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+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/python_inside_maya/CAFRtmODtC8L1BiXxbTOHRH_KwK32ZxRZeo%3DatdrKgdkeThNzRw%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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/python_inside_maya/CAPaTLMT8pNLXc4XM7jT4AVQETE37Q9Z0pGYBBBjYZhYbLDHKMQ%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 

Re: [Maya-Python] Optimise this: Hierarchy from String

[Alok Gandhi]

Ah ok, just saw Marcus's answer, so most of my assumptions were correct. I
would still say, there are many ways to achieve the same thing in
programming. With the kind of flexibility, that python provides, the 'many
ways' becomes 'so many ways'.

Coming back to some of the points that Ian raised:
> Readability is a perfectly valid goal to seek but I
find maintainability is often overlooked.

IMHO more readable code is more maintainable. Readability goes hand in hand
with maintainability. In fact, I very much agree that code lasts longer
than an author and if you write readable code it will be easier to read and
understand for the people after you are gone and are not available to
explain why you did what. If by maintainability you meant actually
extensibility, then it is a completely different aspect.

> In driving to a solution avoiding the additional markup (as in my
solution or in json/XML) you've likely put yourself (and too often your
team after you've left) in a place where you'll need to rewrite the
function for future feature requests.

If you read my previous posts in this threads, you will see that I clearly
mentioned that getting input is an administrative logic. In fact, I
provisioned for it and alluded to Marcus about it. Here's what I wrote:

   - Right in the beginning, we parse the string in a single line, keeping
   the administrative logic out from the rest of our business code. You can
   easily replace this single line with whatever parser you want.

This means that the code that is responsible for creating nodes should not
worry itself with how it is getting the data in, JSON or YAML. And the
parser, whichever it is, should not worry about what is going to happen to
data it outputs. any good architecture should take care of this point.
Making components decoupled and flexible. Good architecture does not only
apply to huge libraries or big project, it should be given thought to every
single small quantum of code, a function and even inside parts of a
function. I did not avoid the input data structure, I simply did not work
on that part as was not required my Marcus originally. Even then, I
separated the code so that in my implementation, nowhere it does rely on
whether I choose JSON or YAML or some other markup. If ten years later,
somebody wants to use my implementation, with JSON the only change it would
require is to change the first line of my code.



On Sat, Sep 17, 2016 at 12:56 AM, Marcus Ottosson 
wrote:

> Thanks Ian!
>
> Some notes.
>
> - The implementation is up for grabs, but I'd like to keep the interface
> of the function; that is, passing a single string with indentation for
> hierarchy.
> - Performance is not important here, because (1) the function is only
> being used in example code, where the call itself should fall into the
> background and (2) creating a hierarchy can safely take a few hundred
> milliseconds if it means more readable code.
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/python_inside_maya/CAFRtmODtC8L1BiXxbTOHRH_
> KwK32ZxRZeo%3DatdrKgdkeThNzRw%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/python_inside_maya/CAPaTLMT8pNLXc4XM7jT4AVQETE37Q9Z0pGYBBBjYZhYbLDHKMQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Maya-Python] Optimise this: Hierarchy from String

[Marcus Ottosson]

Thanks Ian!

Some notes.

- The implementation is up for grabs, but I'd like to keep the interface of
the function; that is, passing a single string with indentation for
hierarchy.
- Performance is not important here, because (1) the function is only being
used in example code, where the call itself should fall into the background
and (2) creating a hierarchy can safely take a few hundred milliseconds if
it means more readable code.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/python_inside_maya/CAFRtmODtC8L1BiXxbTOHRH_KwK32ZxRZeo%3DatdrKgdkeThNzRw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Maya-Python] Optimise this: Hierarchy from String

[Alok Gandhi]

Hi Ian,

Although your approach is so valid, I was working under the following
constraints, most of which were assumptions:
1.  Marcus originally presented a single function with a need to
reimplement it to achieve a few specific goals as he mentioned.
2. I wanted to keep the signature of the function as is.

If I were to freely implement this having more freedom and knowledge about
Marcus's intended use, I would have thought of many other ways to achieve
this, including something like yours.

As for the performance, I think you're right about my use of pymel. But
other than that,

> but also due to searching the scene twice
Can you elaborate on that? As far as I know I am not searching the scene
twice, but maybe you saw something that I missed.

And only very minor,

   1. self.children = children if children is not None else list()


could be

   1. self.children = children or list()
   2.


On Sat, Sep 17, 2016 at 12:35 AM, Ian Jones  wrote:

> It can be achieved without iteration if you solve the original problem in
> another way.
>
> If the problem originally is:
>
> I’m putting together a minor helper function for establishing a transform
> hierarchy within Maya but am not yet satisfied with the implementation.
>
> Then I might suggest something like this:
>
>
>1. import maya.cmds
>2.
>3. class Node(object):
>4. def __init__(self,name,children=None,type='transform'):
>5. self.name = name
>6. self.type = type
>7. self.children = children if children is not None else list()
>8.
>9. def create(self):
>10. node = None
>11. if maya.cmds.objExists(self.name):
>12. node = self.name
>13. else:
>14. node = maya.cmds.createNode(self.type,name=self.name,
>skipSelect=True)
>15.
>16. for child in self.children:
>17. maya.cmds.parent(child.create(),node)
>18.
>19. return node
>20.
>21.
>22. hierarchy = Node('rig',
>23.  [
>24.  Node('implementation',
>25.   [
>26.   Node('geoemtry'),
>27.   Node('skeleton')
>28.   ]),
>29.  Node('interface',
>30.   [
>31.   Node('controls'),
>32.   Node('preview'),
>33.   ]),
>34.  ])
>35. hierarchy.create()
>
>
> Where you define and record the hierarchy as you go then simply create it
> on demand. It may feel like the hierarchy definition (line 22-34) is more
> complex than your basic string but it will be much easier to maintain if
> you wanted to add additional information like nodeType or custom
> attributes/markup. Readability is a perfectly valid goal to seek but I
> find maintainability is often overlooked. In my experience code seems to
> last much longer than the original author anticipated. In driving to a
> solution avoiding the additional markup (as in my solution or in json/xml)
> you've likely put yourself (and too often your team after you've left) in a
> place where you'll need to rewrite the function for future feature requests.
>
> As for the performance side of the world I suggest using the profiler
> (import cProfile;cProfile.run(str) as it's simplest) to understand what
> your code is doing. Unless you're building a very large hierarchy I doubt
> you'll noticed the difference in performance being dict/bisect. In the
> effort to avoid the scan Alok's solution introduced a number of other
> performance penalties (mostly due to pymel, but also due to searching the
> scene twice).
>
> Marcus:
>  - 49 function calls in 0.005 seconds
> Mine:
>  - 29 function calls (23 primitive calls) in 0.003 seconds
> Alok:
> - 3246 function calls (3239 primitive calls) in 0.011 seconds
>
> Ian
>
>
>
>
>
> On Fri, Sep 16, 2016 at 7:57 AM Alok Gandhi 
> wrote:
>
>> > How does bisect achieve this if not by traversing each node in turn and
>> returning the first found, like how the dict is being used currently?
>>
>> In all fairness, there is no way, this can be achieved without some sort
>> of iteration. Bisect is efficient because it implements the binary search
>> algorithm which runs in O(logN) time in the worst case. For a few hundred
>> or maybe even few thousand nodes this is better than doing a for loop for
>> finding a key. The key point is the binary search. In a for loop you go
>> through each key of the dictionary from top to bottom, in binary search,
>> you start from the middle and halve the search domain in each iteration,
>> which is far more efficient. Not to mention, running a for loop inside
>> another for loop makes this O(n**2)
>>
>> Dict (hash table) is good only if you know the 

Re: [Maya-Python] Optimise this: Hierarchy from String

[Ian Jones]

It can be achieved without iteration if you solve the original problem in
another way.

If the problem originally is:

I’m putting together a minor helper function for establishing a transform
hierarchy within Maya but am not yet satisfied with the implementation.

Then I might suggest something like this:


   1. import maya.cmds
   2.
   3. class Node(object):
   4. def __init__(self,name,children=None,type='transform'):
   5. self.name = name
   6. self.type = type
   7. self.children = children if children is not None else list()
   8.
   9. def create(self):
   10. node = None
   11. if maya.cmds.objExists(self.name):
   12. node = self.name
   13. else:
   14. node = maya.cmds.createNode(self.type,name=self.name
   ,skipSelect=True)
   15.
   16. for child in self.children:
   17. maya.cmds.parent(child.create(),node)
   18.
   19. return node
   20.
   21.
   22. hierarchy = Node('rig',
   23.  [
   24.  Node('implementation',
   25.   [
   26.   Node('geoemtry'),
   27.   Node('skeleton')
   28.   ]),
   29.  Node('interface',
   30.   [
   31.   Node('controls'),
   32.   Node('preview'),
   33.   ]),
   34.  ])
   35. hierarchy.create()


Where you define and record the hierarchy as you go then simply create it
on demand. It may feel like the hierarchy definition (line 22-34) is more
complex than your basic string but it will be much easier to maintain if
you wanted to add additional information like nodeType or custom
attributes/markup. Readability is a perfectly valid goal to seek but I
find maintainability is often overlooked. In my experience code seems to
last much longer than the original author anticipated. In driving to a
solution avoiding the additional markup (as in my solution or in json/xml)
you've likely put yourself (and too often your team after you've left) in a
place where you'll need to rewrite the function for future feature requests.

As for the performance side of the world I suggest using the profiler
(import cProfile;cProfile.run(str) as it's simplest) to understand what
your code is doing. Unless you're building a very large hierarchy I doubt
you'll noticed the difference in performance being dict/bisect. In the
effort to avoid the scan Alok's solution introduced a number of other
performance penalties (mostly due to pymel, but also due to searching the
scene twice).

Marcus:
 - 49 function calls in 0.005 seconds
Mine:
 - 29 function calls (23 primitive calls) in 0.003 seconds
Alok:
- 3246 function calls (3239 primitive calls) in 0.011 seconds

Ian





On Fri, Sep 16, 2016 at 7:57 AM Alok Gandhi 
wrote:

> > How does bisect achieve this if not by traversing each node in turn and
> returning the first found, like how the dict is being used currently?
>
> In all fairness, there is no way, this can be achieved without some sort
> of iteration. Bisect is efficient because it implements the binary search
> algorithm which runs in O(logN) time in the worst case. For a few hundred
> or maybe even few thousand nodes this is better than doing a for loop for
> finding a key. The key point is the binary search. In a for loop you go
> through each key of the dictionary from top to bottom, in binary search,
> you start from the middle and halve the search domain in each iteration,
> which is far more efficient. Not to mention, running a for loop inside
> another for loop makes this O(n**2)
>
> Dict (hash table) is good only if you know the key beforehand, otherwise,
> you will have to implement your own logic to find the right key, value pair
> and that logic either bloats up your code and/or sometimes makes it less
> efficient in terms of both memory and/or performance. And then python has
> these little gotchas when it comes to optimization (simple things like
> using `xrange` over `range`, `izip` over `zip`, even using `% (a,)` in
> place of `% a` make a considerable difference), which might be overlooked,
> if either you don't know them or you don't have time to polish your code.
>
> For me bisect brings two distinct advantages to the table:
> 1. A compiled efficient fast search code that has been optimized to a
> certain level (being a part of core python library) compared to my own
> logic that might or might not be the fastest, efficient thing.
> 2. A neat single line call in my code instead of a for loop and maybe
> other conditionals, control flows, lookups etc. with my own logic -
> readability does count.
>
> Also, not an answer to your original question but -
> I did a dry run of your code replacing the parenting with a simple print
> like '{0} 

Re: [Maya-Python] Optimise this: Hierarchy from String

[Alok Gandhi]

> How does bisect achieve this if not by traversing each node in turn and
returning the first found, like how the dict is being used currently?

In all fairness, there is no way, this can be achieved without some sort of
iteration. Bisect is efficient because it implements the binary search
algorithm which runs in O(logN) time in the worst case. For a few hundred
or maybe even few thousand nodes this is better than doing a for loop for
finding a key. The key point is the binary search. In a for loop you go
through each key of the dictionary from top to bottom, in binary search,
you start from the middle and halve the search domain in each iteration,
which is far more efficient. Not to mention, running a for loop inside
another for loop makes this O(n**2)

Dict (hash table) is good only if you know the key beforehand, otherwise,
you will have to implement your own logic to find the right key, value pair
and that logic either bloats up your code and/or sometimes makes it less
efficient in terms of both memory and/or performance. And then python has
these little gotchas when it comes to optimization (simple things like
using `xrange` over `range`, `izip` over `zip`, even using `% (a,)` in
place of `% a` make a considerable difference), which might be overlooked,
if either you don't know them or you don't have time to polish your code.

For me bisect brings two distinct advantages to the table:
1. A compiled efficient fast search code that has been optimized to a
certain level (being a part of core python library) compared to my own
logic that might or might not be the fastest, efficient thing.
2. A neat single line call in my code instead of a for loop and maybe other
conditionals, control flows, lookups etc. with my own logic - readability
does count.

Also, not an answer to your original question but -
I did a dry run of your code replacing the parenting with a simple print
like '{0} ->{1}'.format(parent, child). I saw that parenting was done
multiple times starting from a top parent and going down to the desired
level:
level1->child, level2->child, level3->child etc. With bisect
implementation, you leave all that to the algorithm and just parent once.

In the end, I admit that this was a quick first stab at the problem and
might not be the greatest code or there may be a more beautiful, idiomatic
simpler pythonic way of doing this through the use of dictionaries or some
other standard container.



On Fri, Sep 16, 2016 at 10:04 PM, Marcus Ottosson 
wrote:

> > but then you should do this lookup only once for each node and not
> iterate through each key and then deep inside it until some condition is
> reached. To me, that is a bit complex.
>
> Ah, yes that is true. I did not think of that. Thanks for pointing that
> out.
>
> As someone who isn't terribly familiar with bisect, how does bisect
> achieve this if not by traversing each node in turn and returning the first
> found, like how the dict is being used currently?
>
> On 16 September 2016 at 15:01, Alok Gandhi 
> wrote:
>
>> Hi Marcus,
>>
>> My objective was simple, parenting is the main focus and it should be
>> done  once and only once for each node in the hierarchy. To achieve this,
>> during each iteration the node should have knowledge about his parent just
>> by knowing its position (indent).
>>
>> I did not want complex processing of saving states and whole trees and
>> then lookup up and down. The node should have a place (the tuple list) to
>> look for its parent. It simply asks this question - I have this position,
>> who is my parent. This is typically looking for an insertion point in an
>> array and bisect was a perfect candidate for these requirements.
>>
>> After finding the parent, the node attaches itself to the list replacing
>> the current node at that position so that preceding nodes can find it as a
>> parent when required.
>>
>> Using a dict is a better option just for the reason of O(1) lookup times,
>> but then you should do this lookup only once for each node and not iterate
>> through each key and then deep inside it until some condition is reached.
>> To me, that is a bit complex.
>>
>> On Fri, Sep 16, 2016 at 8:44 PM, Marcus Ottosson 
>> wrote:
>>
>>> Ok, Alok, I had a closer look at your example and the bisect module in
>>> Python.
>>>
>>> In my example, a dict replaces bisect. The dict is limited, in that once
>>> a parent at the same level as an above parent appears, the above parent
>>> vanishes from consideration. But in this case, maybe that works to our
>>> advantage? Could you tell me about your motivation for using bisect?
>>>
>>> --
>>> 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+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit 

Re: [Maya-Python] Optimise this: Hierarchy from String

[Marcus Ottosson]

> but then you should do this lookup only once for each node and not
iterate through each key and then deep inside it until some condition is
reached. To me, that is a bit complex.

Ah, yes that is true. I did not think of that. Thanks for pointing that out.

As someone who isn't terribly familiar with bisect, how does bisect achieve
this if not by traversing each node in turn and returning the first found,
like how the dict is being used currently?

On 16 September 2016 at 15:01, Alok Gandhi 
wrote:

> Hi Marcus,
>
> My objective was simple, parenting is the main focus and it should be done
>  once and only once for each node in the hierarchy. To achieve this, during
> each iteration the node should have knowledge about his parent just by
> knowing its position (indent).
>
> I did not want complex processing of saving states and whole trees and
> then lookup up and down. The node should have a place (the tuple list) to
> look for its parent. It simply asks this question - I have this position,
> who is my parent. This is typically looking for an insertion point in an
> array and bisect was a perfect candidate for these requirements.
>
> After finding the parent, the node attaches itself to the list replacing
> the current node at that position so that preceding nodes can find it as a
> parent when required.
>
> Using a dict is a better option just for the reason of O(1) lookup times,
> but then you should do this lookup only once for each node and not iterate
> through each key and then deep inside it until some condition is reached.
> To me, that is a bit complex.
>
> On Fri, Sep 16, 2016 at 8:44 PM, Marcus Ottosson 
> wrote:
>
>> Ok, Alok, I had a closer look at your example and the bisect module in
>> Python.
>>
>> In my example, a dict replaces bisect. The dict is limited, in that once
>> a parent at the same level as an above parent appears, the above parent
>> vanishes from consideration. But in this case, maybe that works to our
>> advantage? Could you tell me about your motivation for using bisect?
>>
>> --
>> 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+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/python_inside_maya/d86fb040-1d59-492d-8b7c-50dc5cf67d96%
>> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/python_inside_maya/CAPaTLMTaOkfYe0G_x3JCMxfDwiJzeYeQMyAObKCGuPqA2n
> 7foQ%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
*Marcus Ottosson*
konstrukt...@gmail.com

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOD02m%3DbffY2GhNbncgEs0OXp0iYeck_woAg9fATHt2PTA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Maya-Python] Optimise this: Hierarchy from String

[Alok Gandhi]

Hi Marcus,

My objective was simple, parenting is the main focus and it should be done
 once and only once for each node in the hierarchy. To achieve this, during
each iteration the node should have knowledge about his parent just by
knowing its position (indent).

I did not want complex processing of saving states and whole trees and then
lookup up and down. The node should have a place (the tuple list) to look
for its parent. It simply asks this question - I have this position, who is
my parent. This is typically looking for an insertion point in an array and
bisect was a perfect candidate for these requirements.

After finding the parent, the node attaches itself to the list replacing
the current node at that position so that preceding nodes can find it as a
parent when required.

Using a dict is a better option just for the reason of O(1) lookup times,
but then you should do this lookup only once for each node and not iterate
through each key and then deep inside it until some condition is reached.
To me, that is a bit complex.

On Fri, Sep 16, 2016 at 8:44 PM, Marcus Ottosson 
wrote:

> Ok, Alok, I had a closer look at your example and the bisect module in
> Python.
>
> In my example, a dict replaces bisect. The dict is limited, in that once a
> parent at the same level as an above parent appears, the above parent
> vanishes from consideration. But in this case, maybe that works to our
> advantage? Could you tell me about your motivation for using bisect?
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/python_inside_maya/d86fb040-1d59-492d-8b7c-
> 50dc5cf67d96%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/python_inside_maya/CAPaTLMTaOkfYe0G_x3JCMxfDwiJzeYeQMyAObKCGuPqA2n7foQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Maya-Python] Optimise this: Hierarchy from String

[Marcus Ottosson]

Ok, Alok, I had a closer look at your example and the bisect module in 
Python.

In my example, a dict replaces bisect. The dict is limited, in that once a 
parent at the same level as an above parent appears, the above parent 
vanishes from consideration. But in this case, maybe that works to our 
advantage? Could you tell me about your motivation for using bisect?

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/python_inside_maya/d86fb040-1d59-492d-8b7c-50dc5cf67d96%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Maya-Python] Optimise this: Hierarchy from String

[Marcus Ottosson]

Thanks Alok, that's just what I was looking for.

I was just about to mention that about the escape characters, a bare
`strip()` works to our advantage here.

Use of bisect is interesting, I'll have to dig deeper into that.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/python_inside_maya/CAFRtmODX19ihrUD0zDYXixbZUakyMQYMzhqF5vVm%2BU3enWed6Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Maya-Python] Optimise this: Hierarchy from String

[Alok Gandhi]

On second thought, we would NOT like to parse escape characters as maya
would complain later:

   for nodeName, currIndent in ((line.strip(),
  len(line) - len(line.lstrip()))
 for line in hierarchy.split("\n")
 if line.strip()):




On Fri, Sep 16, 2016 at 4:04 PM, Alok Gandhi 
wrote:

> IMHO, parsing the string is just a matter of administrative logic and
> should not be bothered with when focussing on the business logic (which, in
> this case, is recreating the hierarchy).
>
> Sure JSON, YAML, and XML(ugly) are a few options to choose from for
> parsing the string. In the end, It is just a detail to get the data,
> nothing more, nothing less.
>
> What is important is how we deal with that data in the most efficient,
> optimized and readable way.
>
> So here is my implementation, parsing your original indented string. This
> definitely covers your points 1 and 2.  3 is a matter of opinion and is
> subjective.
>
> Few things to note:
>
>- Right in the beginning, we parse the string in a single line,
>keeping the administrative logic out from the rest of our business code.
>You can easily replace this single line with whatever parser you want.
>
>
>- I am using `namedtuple` for readability they are lightweight and
>require no more memory than regular tuples.
>
>
>- `bisect` uses a basic bisection algorithm, an improvement over the
>common approach for finding an insertion point in a sorted list without
>having to sort it again.
>
>
>- This completely eliminates multiple calls to parent() as in your
>original implementation. For each line in the input string, we parent only
>once, no need to go back up or down in the hierarchy with multiple
>if-elif-else. This is more efficient and straight forward.
>
>
>- Handles multiple hierarchies starting from the root (which your
>version also covered I think)
>
>
>- Space characters are not a problem on an empty line(In my example, I
>have deliberate space chars to demonstrate that). On that note, please note
>that I am using line.strip(' ') instead of line.strip(), the reason being
>you can still parse escape characters like \r \t \n etc., strip() eats them
>up as they are whitespaces as well.
>
>
> --
>
> from collections import namedtuplefrom bisect import bisect_left
> import pymel.core as pm
>
> def hierarchy_from_string(hierarchy):
> NodeInfo = namedtuple('NodeInfo', 'node indent')
> nodeInfos = []
> for nodeName, currIndent in ((line.strip(' '),
>   len(line) - len(line.lstrip(' ')))
>  for line in hierarchy.split("\n")
>  if line.strip()):
>
> node = (pm.ls(nodeName)[0] if pm.ls(nodeName)
> else pm.createNode('transform', name=nodeName))
>
> parentIndex = bisect_left([nodeInfo.indent for nodeInfo in nodeInfos],
>   currIndent)
>
> parentNode = (nodeInfos[parentIndex - 1].node
>   if parentIndex - 1 >= 0 else None)
>
> nodeInfo = NodeInfo(node=node, indent=currIndent)
>
> if parentIndex < len(nodeInfos):
> nodeInfos[parentIndex] = nodeInfo
> else:
> nodeInfos.append(nodeInfo)
>
> pm.parent(node, parentNode)
>
>
> hierarchy_from_string("""\rigimplementationgeometry
> skeletoninterfacecontrolspreviewfoobarbaz 
> alicebob""")
>
>
> - Alok
>



--

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/python_inside_maya/CAPaTLMRbGAcKNswNERKK6P0NUzUOhFnoiYjaeqmdDA2qf9Zwaw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Maya-Python] Optimise this: Hierarchy from String

[Marcus Ottosson]

Fair enough!

The resulting function is going into a code example that I’m trying to make
as readable as possible.

I find the readability of this approach less distracting and less motivated
than, say, this.

hierarchy_from_json({
"rig": {
"implementation": {},
"geometry": {},
"skeleton": {},
"interface": {
"controls": {},
"preview": {},
}
}
})

And YAML would require either my tiny example to include it, or for the
user to install it.

Apart from that, and the reason I’m here, was that I was interested in
seeing how others would approach a string processing challenge of this
stature. I expected to find it inspiring and spark ideas with others and
myself.
​

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOApkzq%3DO3texe22zV0WVByFzGs%3DHmbsjf9FfZ3S-1Kh7A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Maya-Python] Optimise this: Hierarchy from String

[Eric Thivierge]

Definitely didn't mean to be snarky. I could have worded it differently
sure. I guess I was trying to get more info on why JSON or YAML wouldn't be
a solution for you.


Eric Thivierge
http://www.ethivierge.com

On Thu, Sep 15, 2016 at 3:18 PM, Justin Israel 
wrote:

>
>
> On Fri, 16 Sep 2016, 7:15 AM  wrote:
>
>> Snarky, but thanks for chiming in.
>>
>
> Maybe. Maybe not.
> It seems to address your 2nd and 3rd points, by asking if you would
> consider changing the input string format to a style that would give you
> hierarchy processing for free.
>
>
>> --
>> 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+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/python_inside_maya/b96da911-316a-4815-83e0-
>> d359fe1b6ea9%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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/python_inside_maya/CAPGFgA0-U9ovtaBUx4tjgB%2Bx55FKmWM_zHdsW2F85UJ%
> 3DAtyFjw%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/python_inside_maya/CAAjrnHtgamK%3Dhd%2BC0kuR%2BAPh-OQtjk%2B5zGEky_nfqYuxqXfBeQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Maya-Python] Optimise this: Hierarchy from String

[marcus . ottosson]

Snarky, but thanks for chiming in.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/python_inside_maya/b96da911-316a-4815-83e0-d359fe1b6ea9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Maya-Python] Optimise this: Hierarchy from String

[Justin Israel]

On Fri, 16 Sep 2016, 7:15 AM  wrote:

> Snarky, but thanks for chiming in.
>

Maybe. Maybe not.
It seems to address your 2nd and 3rd points, by asking if you would
consider changing the input string format to a style that would give you
hierarchy processing for free.


> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/python_inside_maya/b96da911-316a-4815-83e0-d359fe1b6ea9%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA0-U9ovtaBUx4tjgB%2Bx55FKmWM_zHdsW2F85UJ%3DAtyFjw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Maya-Python] Optimise this: Hierarchy from String

[Eric Thivierge]

Isn't this sort of thing what YAML and JSON were created for? Human
readable formats that have tools to iterate over hierarchies of data?


Eric Thivierge
http://www.ethivierge.com

On Thu, Sep 15, 2016 at 1:36 AM, Marcus Ottosson 
wrote:

> Hi all,
>
> I’m putting together a minor helper function for establishing a transform
> hierarchy within Maya but am not yet satisfied with the implementation.
>
> It works like this.
>
> hierarchy_from_string("""\
> rig
> implementation
> geometry
> skeleton
> interface
> controls
> preview
> """)
>
> Resulting in this.
>
> [image: Inline images 1]
>
> The idea then is to start making nodes and move them into their home via
> cmds.parent().
>
> But my implementation so far is fairly limited.
>
>1. Doesn’t take existing nodes into account
>2. Breaks on empty lines
>3. Can overall be made more elegant, I think
>
> So my question to you is, how would you write this?
>
> def hierarchy_from_string(hierarchy):
> parents = {}
>
> for line in hierarchy.split("\n"):
> if not line:
> continue
>
> name = line.strip()
> padding = len(line[:-len(name)])
> parents[padding] = name
>
> name = cmds.createNode("transform", name=name)
>
> for parent in sorted(parents):
> if parent < padding:
> cmds.parent(name, parents[parent])
>
> Thanks for chiming in!
> ​
> --
> *Marcus Ottosson*
> konstrukt...@gmail.com
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/python_inside_maya/CAFRtmODMBoLY%2Bcc_%3DK58NKmaPt0D%3DBKqdwL%2B%
> 3DRFwLLH2j8831A%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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/python_inside_maya/CAAjrnHsrd4ZxOKKGS%2B_hE4_wBJNf3fR01x20MFyxDSL2-2dd0A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Maya-Python] Optimise this: Hierarchy from String

[Marcus Ottosson]

Hi all,

I’m putting together a minor helper function for establishing a transform
hierarchy within Maya but am not yet satisfied with the implementation.

It works like this.

hierarchy_from_string("""\
rig
implementation
geometry
skeleton
interface
controls
preview
""")

Resulting in this.

[image: Inline images 1]

The idea then is to start making nodes and move them into their home via
cmds.parent().

But my implementation so far is fairly limited.

   1. Doesn’t take existing nodes into account
   2. Breaks on empty lines
   3. Can overall be made more elegant, I think

So my question to you is, how would you write this?

def hierarchy_from_string(hierarchy):
parents = {}

for line in hierarchy.split("\n"):
if not line:
continue

name = line.strip()
padding = len(line[:-len(name)])
parents[padding] = name

name = cmds.createNode("transform", name=name)

for parent in sorted(parents):
if parent < padding:
cmds.parent(name, parents[parent])

Thanks for chiming in!
​
-- 
*Marcus Ottosson*
konstrukt...@gmail.com

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/python_inside_maya/CAFRtmODMBoLY%2Bcc_%3DK58NKmaPt0D%3DBKqdwL%2B%3DRFwLLH2j8831A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.