Re: [PyX-devel] Curves with infinite curvature

[Michael S. <m-s...@us...>]

Hello Jörg,

On 14.09.05, Joerg Lehmann wrote:
> On 14.09.05, Andre Wobst wrote:
> > On 14.09.05, Andre Wobst wrote:
> > > > So, we could introduce something like trafo.invalid but we would also
> > > > need a marker for the infinite curvature case. Alternatively, we could
> > > > just live with a single notdefined marker.
> > > 
> > > I'm at least +0 for a generic notdefined marker. Which -- for the sake
> > > of easy to use -- should raise exceptions on access like the old
> > > invalidcurrentpoint did. It's just handy. And I would also like to
> > > have a 
> > 
> > Sorry. I wanted to say, that I still think, that we could use this
> > notdefined in keyword arguments as well. The point is, that we should
> > never use this marker but only check by "... is notdefined". 
> 
> What means notdefined in the context of keyword arguments. Sounds
> strange.
> 
> > Then
> > we're back at the naming issue. For the use case in this thread
> > "notdefined" seems appropriate. For the keyword arg "_marker" is more
> > common. We might just create two instances for that. Fine. The last
> > question I would than ask, whether we want it underscored or not (in
> > the helper module). I would not underscore it, although this is would
> > be different from "_marker". BTW did we reach a final decision whether
> > to have a single _marker in helper or whether we should create such a
> > class/instance/whatever in every module. I would like to have a single
> > instance ...
> 
> Why? What's the advantage of
> 
>     from helper import _marker
> 
> as opposed to
> 
>     class _marker: pass
> 
> Not speaking of having to import an underscored name from a module.
> 
> A not-underscored version is out, because it would indicate that this is
> an external interface, which it explicitely should not be. In other
> words, no caller should be allowed to pass it as argument, simply
> because he was never allowed to access it.
> 
> So, I see only one way (and that's anyway the standard way): we
> use one _marker per module.

This means I have to compare with the _marker from the corresponding
module: normpath._marker in this case:

[code in deformer.py]
curvatures = anormpath.curvature_pt(alist)
for curvature in curvatures:
    if curvature is normpath._marker:
        do fallback
    else:
        do real things


I cannot see the difference to saying helper._marker here.

Michael.

-- 
"A mathematician is a device for turning coffee into theorems"
  Paul Erdös.