M.-A. Lemburg wrote:
> Done.
>
> In order to rebuild the codecs, cd Tools/unicode; make
> then check the codecs in the created build/ subdir (e.g.
> using comparecodecs.py) and copy them over to the
> Lib/encodings/ directory.
Thanks!
Martin
___
Pytho
M.-A. Lemburg wrote:
> Martin v. Löwis wrote:
>
>>M.-A. Lemburg wrote:
>>
>>
>>
>>>I had to create three custom mapping files for cp1140, koi8-u
>>>and tis-620.
>>
>>
>>Can you please publish the files you have used somewhere? They
>>best go into the Python CVS.
>
>
> Sure; I'll check in the who
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>
>>I just left them in because I thought they wouldn't do any harm
>>and might be useful in some applications.
>>
>>Removing them where not directly needed by the codec would not
>>be a problem.
>
>
> I think memory usage caused is measurable (I est
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>
>
>>I had to create three custom mapping files for cp1140, koi8-u
>>and tis-620.
>
>
> Can you please publish the files you have used somewhere? They
> best go into the Python CVS.
Sure; I'll check in the whole build machinery I'm using for this.
M.-A. Lemburg wrote:
> I had to create three custom mapping files for cp1140, koi8-u
> and tis-620.
Can you please publish the files you have used somewhere? They
best go into the Python CVS.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@pyth
M.-A. Lemburg wrote:
> I just left them in because I thought they wouldn't do any harm
> and might be useful in some applications.
>
> Removing them where not directly needed by the codec would not
> be a problem.
I think memory usage caused is measurable (I estimated 4KiB per
dictionary). More i
Walter Dörwald wrote:
> Why should koi_u.py be defined in terms of koi8_r.py anyway? Why not put
> a complete decoding_table into koi8_u.py?
Not sure. Unfortunately, the tables being used as source are not part of
the Python source, so nobody except MAL can faithfully regenerate them.
If they wer
Walter Dörwald wrote:
>>>I'd like to suggest a small cosmetic change: gencodec.py should output
>>>byte values with two hexdigits instead of four. This makes it easier to
>>>see what is a byte values and what is a codepoint. And it would make
>>>grepping for stuff simpler.
>>
>>True.
>>
>>I'll reru
M.-A. Lemburg wrote:
> Walter Dörwald wrote:
>
>>Martin v. Löwis wrote:
>>
>>>M.-A. Lemburg wrote:
>>>
I've checked in a whole bunch of newly generated codecs
which now make use of the faster charmap decoding variant added
by Walter a short while ago.
Please let me know if yo
Walter Dörwald wrote:
> Martin v. Löwis wrote:
>
>> M.-A. Lemburg wrote:
>>
>>> I've checked in a whole bunch of newly generated codecs
>>> which now make use of the faster charmap decoding variant added
>>> by Walter a short while ago.
>>>
>>> Please let me know if you find any problems.
>>
>>
>>
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>
>>I've checked in a whole bunch of newly generated codecs
>>which now make use of the faster charmap decoding variant added
>>by Walter a short while ago.
>>
>>Please let me know if you find any problems.
>
> I think we should work on eliminating t
M.-A. Lemburg wrote:
> I've checked in a whole bunch of newly generated codecs
> which now make use of the faster charmap decoding variant added
> by Walter a short while ago.
>
> Please let me know if you find any problems.
I think we should work on eliminating the decoding_map variables.
There
I've checked in a whole bunch of newly generated codecs
which now make use of the faster charmap decoding variant added
by Walter a short while ago.
Please let me know if you find any problems.
Some codecs (esp. the Mac OS X ones) have minor changes.
These originate from updated mapping files on
13 matches
Mail list logo
