Re: [PyX-devel] Curves with infinite curvature

[Joerg L. <jo...@us...>]

Hello Michael,

On 14.09.05, Michael Schindler wrote:
> 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:

No, sorry, you misunderstood that. _marker is only used for determining
whether someone passed a keyword argument or not. That's completely
unrelated to the discussion on the undefined results. There, of course,
we have to export the undefined instance. But again, it should not be
contained in the helper module, but in the corresponding module (i.e.
normpath) itself.

Btw, as you said yourself, <module>._marker would be bad anyway. But we
already convinced André, so no need to discuss this again.

        Jörg