[stdlib-sig] Proposal: new "interpreter" module

[Benjamin Peterson]

On Sat, Apr 5, 2008 at 6:50 PM, Jim Jewett <jimjjewett at gmail.com> wrote:

> On 4/5/08, Benjamin Peterson <musiccomposition at gmail.com> wrote:
> > On Sat, Apr 5, 2008 at 3:00 PM, Jim Jewett <jimjjewett at gmail.com> wrote:
>
> > > How have you decided which attributes are CPython-specific?
> > > I'm not saying your decisions are wrong, but I find all of them at
> > > least up for questioning.
>
> [trimming most; leaving only the parts where Benjamin commented, *and*
> I disagree with his comments]
>
> > What the bytecode is and how it is generated is
> > implementation specific.
> > It's not the fact you're writing it or not.
>
> I see no reason (other than efficiency or convenience of
> implementation) to even have a bytecode stage.  If you interpret the
> python source directly (as opposed to compiling it, even to bytecode)
> then there is no reason compiled product to save -- and no reason to
> indicate whether it should be saved.

But as of now, (don't quote me on this) all complete Python implementations
write some sort of bytecode.

>
>
> > >   - maxint and maxunicode
> > >
> > > I'm not sure what value these have.  I assume maxint doesn't include
> > > longs -- so is it just the maximum efficiently represented integer, or
> > > is this specific to C extensions, or ..?
> > The maximum int on the system. Jython provides this.
>
> Right, because Jython is based on Java which happens to allow "int" as
> a primitive type instead of requiring Integer objects.  The size of a
> system "int" is an implementation detail (though it has beeen
> effectively standardized for over a decade) that just happens to be
> shared by the two implementations.  The python language doesn't
> specify that anything odd should happen when you do
>
>    x=sys.maxint+1
>
> and the fact that it is represented differently is just an internal
> detail.

It is useful in general Python code, though, because some operations are
constrained by it. This is the max a C int can handle, so if you're
converting some value from Python to C for processing, and your value might
be huge, it's helpful to be able to compare it.

>
>
> > > And is maxunicode just roundabout way of figuring out the concrete
> > > representation (code points) of unicode characters?
> > It is the max Unicode character  that Python's unicode
> > implementation is capable of handling. Jython provides this.
>
> Even worse -- unicode characters are barely ordered, and are supported
> way above 16bits -- it is just an internal implementation detail that
> some physical encodings can't do it without some awkwardness (and the
> possibility of representing invalid values).
>
> (That said, Guido has ruled that the length and slicing of the unicode
> type will continue to be based on the physical code points, rather
> than the abstract characters, so there may be a reason to expose it.
> But is is clearly an implementation limit rather than a desirable part
> of the langauge.)

This is useful also because it tells you whether Python was compiled with
wide Unicode or short Unicode.

>
>
> > >   - ps1 and ps2
>
> > > This really seems like a config issue rather than sys.
> > Yeh, sys is about runtime Python. Besides, it's global to all
> > implementations.
>
> Within the sys exposed to IDLE, it seems to be gone.  (Though I can
> get it from the plain python.)  I expect other environments (ipython?)
> may have their own ideas about which variables are needed to control
> interactivity.

Right, ps1 and ps2 dictate the prompts of the *default* Python interactive
prompt at runtime,  so they should be in sys.

>
>
> > >   - tracebacklimit
> > >
> > > How is this different from setrecursionlimit?
> > It defines how many lines of traceback are printed in an exception.
>
> What I meant is "why are those two in separate sections?"
>
> I think of both tracebacklimit and recursionlimit as implementation
> restrictions.  They violate the language purity in favor of a
> practical benefit.  Since the exact tradeoffs are debatable, there are
> ways to reset them.

I disagree. Every Python implementation is going to have tracebacks, and be
able to handle huge ones. It's generally practical to be able to limit them.
However, not every Python implementation is going to work by frames and
recursion.

>
>
> That Jython still sees practical value in trimming exception displays
> to a readable length, but does not see enough value in restricting
> recursion depth just means that the cost of recursion is less there.
>
> > > If you care enough to say "Can I recurse 3000
> > > frames?", that is a legitimate question, and it just so happens that
> > > Jython should always answer "yes".
> > Actually, I believe you get a stack overflow before that. It doesn't
> tell
> > you that.
>
> Is this because of a limit on the number of stack frames, or because
> of the limit on the stacksize?  If so, that is still correlated with a
> recursion limit (so they can give a heuristic, based on the stack
> size).

It's stack size, but you'd have to talk to the Jython people about that.

>
>
> -jJ
>



-- 
Cheers,
Benjamin Peterson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/stdlib-sig/attachments/20080405/fafa1811/attachment-0001.htm