<br><br><div class="gmail_quote">On Sat, Apr 5, 2008 at 6:50 PM, Jim Jewett <<a href="mailto:jimjjewett@gmail.com">jimjjewett@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On 4/5/08, Benjamin Peterson <<a href="mailto:musiccomposition@gmail.com">musiccomposition@gmail.com</a>> wrote:<br>
> On Sat, Apr 5, 2008 at 3:00 PM, Jim Jewett <<a href="mailto:jimjjewett@gmail.com">jimjjewett@gmail.com</a>> wrote:<br>
<br>
> > How have you decided which attributes are CPython-specific?<br>
> > I'm not saying your decisions are wrong, but I find all of them at<br>
> > least up for questioning.<br>
<br>
</div>[trimming most; leaving only the parts where Benjamin commented, *and*<br>
I disagree with his comments]<br>
<div class="Ih2E3d"><br>
> What the bytecode is and how it is generated is<br>
> implementation specific.<br>
> It's not the fact you're writing it or not.<br>
<br>
</div>I see no reason (other than efficiency or convenience of<br>
implementation) to even have a bytecode stage. If you interpret the<br>
python source directly (as opposed to compiling it, even to bytecode)<br>
then there is no reason compiled product to save -- and no reason to<br>
indicate whether it should be saved.</blockquote><div>But as of now, (don't quote me on this) all complete Python implementations write some sort of bytecode. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<div class="Ih2E3d"><br>
> > - maxint and maxunicode<br>
> ><br>
> > I'm not sure what value these have. I assume maxint doesn't include<br>
> > longs -- so is it just the maximum efficiently represented integer, or<br>
> > is this specific to C extensions, or ..?<br>
> The maximum int on the system. Jython provides this.<br>
<br>
</div>Right, because Jython is based on Java which happens to allow "int" as<br>
a primitive type instead of requiring Integer objects. The size of a<br>
system "int" is an implementation detail (though it has beeen<br>
effectively standardized for over a decade) that just happens to be<br>
shared by the two implementations. The python language doesn't<br>
specify that anything odd should happen when you do<br>
<br>
x=sys.maxint+1<br>
<br>
and the fact that it is represented differently is just an internal detail.</blockquote><div>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="Ih2E3d"><br>
> > And is maxunicode just roundabout way of figuring out the concrete<br>
> > representation (code points) of unicode characters?<br>
> It is the max Unicode character that Python's unicode<br>
> implementation is capable of handling. Jython provides this.<br>
<br>
</div>Even worse -- unicode characters are barely ordered, and are supported<br>
way above 16bits -- it is just an internal implementation detail that<br>
some physical encodings can't do it without some awkwardness (and the<br>
possibility of representing invalid values).<br>
<br>
(That said, Guido has ruled that the length and slicing of the unicode<br>
type will continue to be based on the physical code points, rather<br>
than the abstract characters, so there may be a reason to expose it.<br>
But is is clearly an implementation limit rather than a desirable part<br>
of the langauge.)</blockquote><div>This is useful also because it tells you whether Python was compiled with wide Unicode or short Unicode.<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<div class="Ih2E3d"><br>
> > - ps1 and ps2<br>
<br>
> > This really seems like a config issue rather than sys.<br>
> Yeh, sys is about runtime Python. Besides, it's global to all<br>
> implementations.<br>
<br>
</div>Within the sys exposed to IDLE, it seems to be gone. (Though I can<br>
get it from the plain python.) I expect other environments (ipython?)<br>
may have their own ideas about which variables are needed to control<br>
interactivity.</blockquote><div>Right, ps1 and ps2 dictate the prompts of the *default* Python interactive prompt at runtime, so they should be in sys.<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<div class="Ih2E3d"><br>
> > - tracebacklimit<br>
> ><br>
> > How is this different from setrecursionlimit?<br>
> It defines how many lines of traceback are printed in an exception.<br>
<br>
</div>What I meant is "why are those two in separate sections?"<br>
<br>
I think of both tracebacklimit and recursionlimit as implementation<br>
restrictions. They violate the language purity in favor of a<br>
practical benefit. Since the exact tradeoffs are debatable, there are<br>
ways to reset them.</blockquote><div>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
That Jython still sees practical value in trimming exception displays<br>
to a readable length, but does not see enough value in restricting<br>
recursion depth just means that the cost of recursion is less there.<br>
<div class="Ih2E3d"><br>
> > If you care enough to say "Can I recurse 3000<br>
> > frames?", that is a legitimate question, and it just so happens that<br>
> > Jython should always answer "yes".<br>
> Actually, I believe you get a stack overflow before that. It doesn't tell<br>
> you that.<br>
<br>
</div>Is this because of a limit on the number of stack frames, or because<br>
of the limit on the stacksize? If so, that is still correlated with a<br>
recursion limit (so they can give a heuristic, based on the stack<br>
size).</blockquote><div>It's stack size, but you'd have to talk to the Jython people about that. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<font color="#888888"><br>
-jJ<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Cheers,<br>Benjamin Peterson