[pyar] kernel mata python

[Claudio Freire]

2016-10-13 20:41 GMT-03:00 Fernando Pelliccioni <fpelliccioni en gmail.com>:
> On Oct 13, 2016 7:58 PM, "Claudio Freire" <klaussfreire en gmail.com> wrote:
>>
>> 2016-10-13 17:36 GMT-03:00 Fernando Pelliccioni <fpelliccioni en gmail.com>:
>> > 2016-10-12 19:51 GMT-03:00 Claudio Freire <klaussfreire en gmail.com>:
>> >>
>> >> 2016-10-12 12:03 GMT-03:00 Javier Marcon <javiermarcon en gmail.com>:
>> >> >> Por otro lado, ¿cómo estás trabajando el CSV? Si lo leés y laburás
>> >> >> linea por linea no deberías tener problema de memoria... ¿Se puede
>> >> >> ver
>> >> >> qué estás haciendo?
>> >> >>
>> >> >> Slds.
>> >> >>
>> >> > No puedo poner el código por el contrato de confidencialidad, pero lo
>> >> > que hace es leer el csv y arma varias listas, una lista que por cada
>> >> > fila del csv tiene una lista de los valores de la fila, una lista con
>> >> > los encabezados, una lista de keys de fila, etc.
>> >>
>> >> Sin código va a ser difícil ayudarte, pero si te ponés a pensar, con
>> >> un input de 200MB tendrías que estar inflando muchísimo en memoria los
>> >> datos para estar teniendo problemas con el OOM - eso, o estás
>> >> laburando en una máquina demasiado chica.
>> >>
>> >> Si estás laburando en python 2, recordá que los strings unicode pesan
>> >> 4x lo normal debido al encoding interno. Podés ahorrar mucha memoria
>> >> guardando byte strings en vez de unicode (ej: x.encode("utf8") al
>> >> ponerlo en la lista, y x.decode("utf8") al sacarlo de la lista). Es un
>> >> laburo, pero te puede mejorar la eficiencia notablemente.
>> >>
>> >> En python 3, desde cierta versión (creo que 3.4), ésto es automático.
>> >
>> >
>> > ¿Por qué 4x?
>> > El encoding interno de los strings de CPython 2.x es el mismo que el de
>> > las
>> > versiones 3.0, 3.1 y 3.2.
>> > Recién en 3.3 lo cambian a un encoding dinámico
>> > (https://www.python.org/dev/peps/pep-0393/).
>> > Tanto en CPython 2.x como en CPython < 3.3 el encoding es UCS-2 o UCS-4
>> > (dependiendo de como se compile el intérprete).
>> >
>>
>>
>> Por eso que decís.
>>
>> Casi todas las distros compilan con UCS-4 (UCS-2 es limitado), y UCS-4
>> pesa, en la mayoría de los inputs, 4x lo que pesa UTF8.
>
> 4x me pareció exagerado, ya que es 4x siempre y cuando estemos en los
> primeros 128 Codepoints. Si laburás con plain-english es así. Sino es 2x,
> 4/3x o 1x...

No, para nada. En la mayoría de los idiomas, sigue siendo ~4x, porque
la mayoría de los code points siguen siendo de 1 byte en UTF8. Sólo
los code points que no corresponden a los primeros 128 se encodean con
más bytes, y en general no abundan tanto como para desviarte mucho del
4x.

Si usaras chino, sí, es más tipo ~2x. Pero siendo una lista de
Argentina asumo que es español (o inglés, o algún idioma que usa el
set latino básico, o a lo sumo el BMP)

> Mi Python 3.2 en Windows está compilado con UCS-2 ( 2x, 1x, 3/4x, 1/2x).
>
> UCS-2 es limitado, es cierto, lo que no queda claro es que encoding usa
> CPython < 3.3, mirá:
>
> https://mail.python.org/pipermail/python-dev/2008-July/080915.html
>
> Parece ser un UTF-16 a medias ya que no indexan por Codepoints ni graphemes,
> sino por Codeunits...

UTF tengo entendido no es nunca, siempre es uno de los UCS.

> Al margen, el encoding dinámico que inventaron en 3.3 no me gustó para nada.

¿Por?