Re: [Python-Dev] Python 2.6 on AMD64 recusion crash
> I believe it's the wrong diagnosis :) As I mentioned in the bug, I believe you are correct :) Thanks! Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] IDLE croaks on both beta3s?
Marks Summerfield and Dickenson report 2.6/3.0 b3 will not run IDLE http://bugs.python.org/issue3628 because idlelib/run.py needs s/set_daemon(True)/daemon = True/ Assuming they are correct and this is general: 1. Is not there any test to make sure that IDLE basically runs? For instance by having it run a file that writes a test file? 2. If the Windows installers have not been made yet (they are not on Python.org yet), could they incorporate the needed change? For me, this is a show stopper since I use IDLE as my Python editor and tester. tjr ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Doc translation -- from LaTeX to reStructuredText
On Fri, Aug 22, 2008 at 9:03 AM, harp <[EMAIL PROTECTED]> wrote: > Dear Developers, > > We have translated the tutorial into Hungarian earlier, and I do not > know how to convert the LaTeX file into reStructuredText. Could > somebody help us? Have you looked at the LaTeX to reST converter at http://svn.python.org/view/doctools/converter? > > HTML: http://pythonlib.pergamen.hu/html/tut/ > LaTeX file: http://mail.roik.bmf.hu/linux/python/tutorial/tut.tex > > There will be included translations of documentation on the python.org > homepage? > > Arpad > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.com > -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode 5.1.0
On Fri, Aug 22, 2008 at 07:59:46AM -0700, Guido van Rossum wrote: > That's up to us. I don't know what the reason was for keeping the > 3.2.0 database around -- does anyone here recall ever using it? For > what? RFC 3491, one of the internationalized domain name RFCs, explicitly requires Unicode 3.2.0, so Lib/stringprep.py needs to use the old database and we have to keep 3.2.0 available. Maybe no specs depend on 4.1.0, so it could simply be replaced by 5.1.0. --amk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode 5.1.0
I think it's an anti-spam measure. Anybody can be a member though. :-) On Fri, Aug 22, 2008 at 8:15 AM, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > when did Python-Dev turn into a members only list, btw? > > --- > > Your mail to 'Python-Dev' with the subject > > Re: Unicode 5.1.0 > > Is being held until the list moderator can review it for approval. > > The reason it is being held: > > Post by non-member to a members-only list -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode 5.1.0
when did Python-Dev turn into a members only list, btw? --- Your mail to 'Python-Dev' with the subject Re: Unicode 5.1.0 Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode 5.1.0
2008/8/22 Fredrik Lundh <[EMAIL PROTECTED]>:
> On Fri, Aug 22, 2008 at 4:59 PM, Guido van Rossum <[EMAIL PROTECTED]>
wrote:
>
>>> (how's the 3.2/4.1 dual support implemented? do we have two distinct
>>> datasets, or are the differences encoded in some clever way? would it
>>> make sense to split the unicodedata module into three separate
>>> modules, one for each major Unicode version?)
>>
>> The current API looks fine to me: unicodedata is the latest version
>> whereas unicodedata.ucd_3_2_0 is the older version. The APIs are the
>> same; there's a tiny bit of code in the generated _db.h file that
>> expresses the differences:
>>
>> static const change_record* get_change_3_2_0(Py_UCS4 n)
>> {
>>int index;
>>if (n >= 0x11) index = 0;
>>else {
>>index = changes_3_2_0_index[n>>7];
>>index = changes_3_2_0_data[(index<<7)+(n & 127)];
>>}
>>return change_records_3_2_0+index;
>> }
>
> there's a bunch of data tables as well, but they don't seem to be very
> large. looks like Martin did a thorough job here.
>
> ... digging digging digging ...
>
> yes, the generator script produces difference tables between the main
> version and a list of older versions. I'd say it's worth running the
> script on the 5.1.0 tables, and if it doesn't choke, compare the
> resulting table with the corresponding table for 4.1.0 (a simple loop
> fetching the main properties for all code points). if the differences
> look reasonably small, switch 5.1.0 and keep the others.
Right, that's my hope as well. I believe the changes between 3.2 and 4.1
were much larger than more recent changes. (Yay convergence! :-)
> I can tinker a little with this over the weekend, unless Martin tells
> me not to ;-)
That would be great!
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (08/15/08 - 08/22/08) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1976 open (+67) / 13495 closed (+21) / 15471 total (+88) Open issues with patches: 626 Average duration of open issues: 717 days. Median duration of open issues: 1688 days. Open Issues Breakdown open 1963 (+67) pending13 ( +0) Issues Created Or Reopened (92) ___ Can't pickle partial functions 08/15/08 http://bugs.python.org/issue1398reopened alexandre.vassalotti Operator precedence misdocumented08/19/08 http://bugs.python.org/issue3558reopened tjreedy Windows installer should add Python and Scripts directories to t 08/15/08 CLOSED http://bugs.python.org/issue3561created jasonspiro Intermitent failure in test_multiprocessing.test_number_of_objec 08/15/08 http://bugs.python.org/issue3562created pitrou fix_idioms.py generates bad code 08/16/08 http://bugs.python.org/issue3563created hawking patch making partial functions comparable 08/16/08 http://bugs.python.org/issue3564created erickt array documentation, method names not 3.0 compliant 08/16/08 http://bugs.python.org/issue3565created mgiuca patch httplib persistent connections violate MUST in RFC2616 sec 8.1.4 08/16/08 http://bugs.python.org/issue3566created cananian test_ossaudiodev fails when run with -bb 08/16/08 CLOSED http://bugs.python.org/issue3567created pitrou list enumeration corrupt when remove() 08/16/08 CLOSED http://bugs.python.org/issue3568created jacek Glitch in eval() doc 08/16/08 http://bugs.python.org/issue3569created tjreedy str.find docstring typo 08/16/08 CLOSED http://bugs.python.org/issue3570created andyharrington test_closerange in test_os can crash the test suite 08/16/08 CLOSED http://bugs.python.org/issue3571created pitrou patch with closed file descriptor #2 (stderr), py3k hangs when trying 08/16/08 CLOSED http://bugs.python.org/issue3572created pitrou IDLE hangs when passing invalid command line args (directory(ies 08/16/08 http://bugs.python.org/issue3573created gpolo patch, needs review compile() cannot decode Latin-1 source encodings 08/17/08 http://bugs.python.org/issue3574created brett.cannon patch, needs review [py3k] tell() fails in some situation08/17/08 CLOSED http://bugs.python.org/issue3575created ocean-city patch Demo/embed builds against old version08/17/08 CLOSED http://bugs.python.org/issue3576created mgiuca patch Interpreter name: python vs. python-3.0 08/17/08 http://bugs.python.org/issue3577created jjlee 'dictionary changed size' error in test_multip
Re: [Python-Dev] Unicode 5.1.0
On Fri, Aug 22, 2008 at 4:59 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> (how's the 3.2/4.1 dual support implemented? do we have two distinct
>> datasets, or are the differences encoded in some clever way? would it
>> make sense to split the unicodedata module into three separate
>> modules, one for each major Unicode version?)
>
> The current API looks fine to me: unicodedata is the latest version
> whereas unicodedata.ucd_3_2_0 is the older version. The APIs are the
> same; there's a tiny bit of code in the generated _db.h file that
> expresses the differences:
>
> static const change_record* get_change_3_2_0(Py_UCS4 n)
> {
>int index;
>if (n >= 0x11) index = 0;
>else {
>index = changes_3_2_0_index[n>>7];
>index = changes_3_2_0_data[(index<<7)+(n & 127)];
>}
>return change_records_3_2_0+index;
> }
there's a bunch of data tables as well, but they don't seem to be very
large. looks like Martin did a thorough job here.
... digging digging digging ...
yes, the generator script produces difference tables between the main
version and a list of older versions. I'd say it's worth running the
script on the 5.1.0 tables, and if it doesn't choke, compare the
resulting table with the corresponding table for 4.1.0 (a simple loop
fetching the main properties for all code points). if the differences
look reasonably small, switch 5.1.0 and keep the others.
I can tinker a little with this over the weekend, unless Martin tells
me not to ;-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Doc translation -- from LaTeX to reStructuredText
Dear Developers, We have translated the tutorial into Hungarian earlier, and I do not know how to convert the LaTeX file into reStructuredText. Could somebody help us? HTML: http://pythonlib.pergamen.hu/html/tut/ LaTeX file: http://mail.roik.bmf.hu/linux/python/tutorial/tut.tex There will be included translations of documentation on the python.org homepage? Arpad ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode 5.1.0
On Fri, Aug 22, 2008 at 6:42 AM, Facundo Batista <[EMAIL PROTECTED]> wrote: > - In view of jumping to a new standard at *this* point, what I'd like > to have is a comprehensive test suite for unicodedata in a similar > sense to what happens with Decimal... It would be great to have from > the Unicode Consortium a series of test cases (in Python, or in > something we could process), to verify that we support Unicode > properly. Unicode conformance isn't specified in the same way as Decimal conformance. While there are certain algorithms that can be tested (e.g. normalization, encoding, decoding), much of the conformance requirements (AFAIK) are expressed in lots of words about providing certain facilities etc. I don't actually think putting lots of effort into this is well-spent; given the mechanical nature of the translation from the unicode database files into C code (see Tools/unicode/makeunicodedata.py) a bug in the translation is likely to result in either bad C code or a systematic error that is easily spotted. > - We always could have a beta4 if it's necessary... No way. On Fri, Aug 22, 2008 at 7:54 AM, Antoine Pitrou <[EMAIL PROTECTED]> wrote: > And another question: would it be hard for Google to maintain this separately > until at least it's integrated to 3.1? That's the plan. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode 5.1.0
On Fri, Aug 22, 2008 at 3:47 AM, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 22, 2008 at 3:25 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
[MAL]
>>> So while we could say: "we provide access to the Unicode 5.1.0
>>> database", we cannot say: "we support Unicode 5.1.0", simply because
>>> we have not reviewed the all the necessary changes and implications.
>>
>> Mark's response to this was:
>>
>> """
>> I'd suspect that you'll be as conformant to U5.1.0 as you were to U4.1.0 ;-)
>
> is the suggestion to *replace* the 4.1.0 database with a 5.1.0
> database, or to add yet another database in that module?
That's up to us. I don't know what the reason was for keeping the
3.2.0 database around -- does anyone here recall ever using it? For
what?
I think Mark believes that 5.1.0 is very much backwards compatible
with 4.1.0 so that there is no need to retain access to 4.1.0; but as
I said I don't know the use case so who knows.
> (how's the 3.2/4.1 dual support implemented? do we have two distinct
> datasets, or are the differences encoded in some clever way? would it
> make sense to split the unicodedata module into three separate
> modules, one for each major Unicode version?)
The current API looks fine to me: unicodedata is the latest version
whereas unicodedata.ucd_3_2_0 is the older version. The APIs are the
same; there's a tiny bit of code in the generated _db.h file that
expresses the differences:
static const change_record* get_change_3_2_0(Py_UCS4 n)
{
int index;
if (n >= 0x11) index = 0;
else {
index = changes_3_2_0_index[n>>7];
index = changes_3_2_0_data[(index<<7)+(n & 127)];
}
return change_records_3_2_0+index;
}
static Py_UCS4 normalization_3_2_0(Py_UCS4 n)
{
switch(n) {
case 0x2f868: return 0x2136A;
case 0x2f874: return 0x5F33;
case 0x2f91f: return 0x43AB;
case 0x2f95f: return 0x7AAE;
case 0x2f9bf: return 0x4D57;
default: return 0;
}
}
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode 5.1.0
Facundo Batista gmail.com> writes: > > Two thoughts: > > - In view of jumping to a new standard at *this* point, what I'd like > to have is a comprehensive test suite for unicodedata in a similar > sense to what happens with Decimal... It would be great to have from > the Unicode Consortium a series of test cases (in Python, or in > something we could process), to verify that we support Unicode > properly. > And another question: would it be hard for Google to maintain this separately until at least it's integrated to 3.1? > - We always could have a beta4 if it's necessary... If we go this route there are lots of attractive things that might justify yet and yet another beta :-) Just my two over-evaluated euro cents. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode 5.1.0
2008/8/21 Guido van Rossum <[EMAIL PROTECTED]>: > The two, quite separate, questions, then, are (a) how much work would > it be to upgrade to version 5.1.0 of the database; and (b) would it be > acceptable to do this post-beta3 (but before rc1). If the answer to > (b) is positive, Google can help with (a). Two thoughts: - In view of jumping to a new standard at *this* point, what I'd like to have is a comprehensive test suite for unicodedata in a similar sense to what happens with Decimal... It would be great to have from the Unicode Consortium a series of test cases (in Python, or in something we could process), to verify that we support Unicode properly. - We always could have a beta4 if it's necessary... Just my two pesos cents. Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode 5.1.0
On Fri, Aug 22, 2008 at 3:25 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> So while we could say: "we provide access to the Unicode 5.1.0 >> database", we cannot say: "we support Unicode 5.1.0", simply because >> we have not reviewed the all the necessary changes and implications. > > Mark's response to this was: > > """ > I'd suspect that you'll be as conformant to U5.1.0 as you were to U4.1.0 ;-) is the suggestion to *replace* the 4.1.0 database with a 5.1.0 database, or to add yet another database in that module? (how's the 3.2/4.1 dual support implemented? do we have two distinct datasets, or are the differences encoded in some clever way? would it make sense to split the unicodedata module into three separate modules, one for each major Unicode version?) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6 on AMD64 recusion crash
Hi Mark, > I believe that this is the only path that allows us to go past an > *actual* recursion level of 1/2 the nominated maximum value due to that > other regression I mentioned. I believe it's the wrong diagnosis :) If you look at http://bugs.python.org/issue3373 and the small script I posted, there are paths where the actual recursion level is still 1000. Furthermore: > Yes, exactly - that is the point. If we got to 1000 Python would have > prevented us going any further. As it was, we ran out of stack space at > 629. [...] > The 32bit windows versions of Python do > exactly this and nominate 2MB, which the 64bit builds inherited. 2MB divided by 629 is more than 3KB. It means each cPickle recursion level consumes more than 3KB of stack. It sounds awful enough to be considered a bug in cPickle, IMO. 2MB is plenty of stack space. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
