Changes by ajaksu [EMAIL PROTECTED]:
--
nosy: +ajaksu2
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2506
__
___
Python-bugs-list mailing list
Unsubscribe:
http
ajaksu added the comment:
Here's my attempted patch against trunk. The doc is poor (but what else
should it contain?) and the attribute name could be better.
I'm worried about lack of testing for this change as the module has
virtually no tests. Should we start adding naive (regarding
ajaksu added the comment:
he specific issue mentioned might arise from UAs interpreting the
snippet as a header, but the whole thing is so oblivious to standards
that it doesn't matter:
def reset():
Return a string that resets the CGI and browser to a known state.
return '''!--: spam
New submission from ajaksu:
This small patch adds a HTML 3.2 doctype, a html and a body tags.
Should work on py3k.
This patch only accomplishes a Tentatively Valid HTML 3.2 result.
Adding information on encoding would make that more conclusive, but
IMHO wrong too.
--
components
ajaksu added the comment:
If the fix was applied, this should be closed. If not, seems pretty easy
to do (worst case: add as Known Issue, Won't Fix).
--
nosy: +ajaksu2
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1207466
ajaksu added the comment:
Would it be implemented in C? How about using Luschny's Prime Swing
(http://www.luschny.de/math/factorial/FastFactorialFunctions.htm and
http://www.luschny.de/math/factorial/Benchmark.html )?
--
nosy: +ajaksu2
__
Tracker [EMAIL
ajaksu added the comment:
Martin, I agree that simply not resolving DTDs is an unreasonable
request (and said so in the blog post). But IMHO there are lots of
possible optimizations, and the most valuable would be those darn easy
for newcomers to understand and use.
In Python, a winning combo
ajaksu added the comment:
IMHO this patch should be considered for (at least) py3k, in which long
becomes the new int. As there is current interest in long/int
performance[1] this seems like a good time to raise this kind of issue.
Mark, could you please outline the semantic changes
ajaksu added the comment:
Thanks a lot for the explanation. I still think it could be valuable
(C?)py3k change (but now for the predictability, as you say :)
Regarding the performance of Decimal.__hash__:
I believe (int) hash performance would be a moot issue if
Decimal.__int__ was (much
