Extendend string selector syntax using PyParsing

[adam-urbanczyk]

Do not merge yet - WIP

So far only the grammar is implemented. It extends the current one with:

• python style indexing: e.g. >Z[10]
• arbitrary vectors: e.g. +(1.,1.,0)

[coveralls]

Coverage increased (+0.2%) to 85.799% when pulling f8c377c on adam-urbanczyk:master into 0ef569a on dcowden:master.

[coveralls]

Coverage increased (+0.2%) to 85.799% when pulling f8c377c on adam-urbanczyk:master into 0ef569a on dcowden:master.

[hyOzd]

Hi @adam-urbanczyk , do you plan to make selector combining a part of this new syntax?

[coveralls]

Coverage decreased (-0.1%) to 85.509% when pulling 76a2207 on adam-urbanczyk:master into 0ef569a on dcowden:master.

[coveralls]

Coverage increased (+0.3%) to 85.884% when pulling d1593e6 on adam-urbanczyk:master into 0ef569a on dcowden:master.

[adam-urbanczyk]

@hyOzd not in the scope of this PR. Maybe in a following one, shouldn't be that hard

@dcowden I think this is almost it - all tests pass. Please review and tell me what you think. BTW: I still want to add more test cases.

[coveralls]

Coverage increased (+0.4%) to 85.99% when pulling 5b0b5c0 on adam-urbanczyk:master into 0ef569a on dcowden:master.

[adam-urbanczyk]

@dcowden @jmwright I added additional test case (and fixed some parsing bugs that it pointed to). From my side it is ready to be merged.

@hyOzd @dcowden @jmwright do you think that adding logical ops to the string syntax is a good idea? If so I can start thinking about another PR

[dcowden]

This looks ok to me. Great work @adam-urbanczyk , nice contribution!
@jmwright if you are ok with this please merge, or let me know and i will

[jmwright]

@adam-urbanczyk Great work, thank you.

@adam-urbanczyk @dcowden How do we want to handle the new dependency (pyparse)? Should it be included directly with CadQuery, or should we just add instructions on how to install it in the docs? I think Windows users might have to jump through a few hoops to install that package.

My vote would be to add logical ops. They're so powerful that I think it would be worth the effort if you're willing to do it, @adam-urbanczyk

[dcowden]

yes, +1 on the logical ops.

on managing the dependency, that's a very good question. I did some quick prototyping a while back, and I concluded that packaging it with cadquery is not really a good idea. I extracted the source, and i found that non-trivial source code modifications were required to make it happy living in our package structure.

So unfortunately I think we'll have to require an external dependency. You're right that this is a pain, especially on windows.

But on another level, the installation process for CQ and all its deps is already completely out of control-- so i dont see a reason to hold this up due to one more.

Instead, we need to 'lean in' to the dependency problem and shift to delivery via containers and/or conda packages-- so that we can have all the deps we want and still not make it hard for the user.

[jmwright]

I'll try to get this merged tonight.

[hyOzd]

@adam-urbanczyk having logical ops as part of string selector would be awesome.

[jmwright]

Ready to merge. Thanks again for this contribution. I'm looking forward to putting this new selector syntax to use. I'll create a separate issue about documenting the new dependency so that it doesn't fall through the cracks.

[dcowden]

Thanks again @adam-urbanczyk for this work, and thanks @jmwright for merging!

[jmwright]

I updated the CadQuery module for FreeCAD for this change and embedded pyparsing as a library. I played around a bit with the new selector syntax and things seemed to work well.

[adam-urbanczyk]

Good to hear. I am working on a semi-complicated model using Nth selector (which actually was the reason to develop it) . Once I am done, I can post it somwhere.

[jmwright]

We have a discussion thread on the Google Group for sharing work if you're interested in using that.

https://groups.google.com/forum/#!topic/cadquery/mS2ITd37sQA