Re: [PyX-devel] Curves with infinite curvature

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

Hi André,

[ sorry, forgot to CC the list, here we go ]

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.

     Jörg