py3k

[cperezabo]

Esta vivo el desarrollo de la compatibilidad con python3 o esta abandonado? Los commits de la rama py3k ya tienen varios meses, lo estan haciendo localmente y no pushean? necesitan ayuda?

[reingart]

Por ahora esta suspendido, por el momento no es prioridad por todos los últimos cambios de AFIP y nuevos webservices.
Para sacarlo de stand-by habría que ajustar algunas cuestiones y probarlo en detalle, para más info ver:

https://groups.google.com/d/msg/pyafipws/1xmTXORUooo/kYlkfhciAwAJ

Toda colaboración es bienvenida

[cperezabo]

El tema seria como planificarlo a futuro, porque yo puedo colaborar en la migración a py3, pero no puedo perseguir los cambios de la 2.7 todo el tiempo, ademas mantener 2 proyectos en paralelo seria cansador, deberiamos en un punto mergear ambos y mantener condiciones para salvar las diferencias entre una versión y la otra. Me refiero a la carga condicional de módulos, de llamada a métodos y demás cuestiones.
Porque sino va a ser un infierno.

[cperezabo]

Hice un fork del proyecto, me puse a probar un poco, en principio aplique un 2to3 para actualizar a python3 lo basico, y un pasteurize para que agregue los modulos future necesarios para que todo funcione en python 2 y 3 a la vez. Despues empece a corregir algunos errores que surgian por esa conversión y logre hacer funcionar wsfev1, y wsaa en python 2 y 3 con el mismo source. (probe con wsfev1 porque es el que yo uso en mis proyectos y ya lo tengo mas conocido.
Si te interesa que lo hagamos, le sigo metiendo tiempo (que no me sobra)

[matuu]

Me interesa colaborar para avanzar y luego mantener la compatibilidad con py3. En un año y algo caduca python2 y sería muy bueno tenerlo estable.

[cperezabo]

Exactamente 3 años y 1 mes, pero igualmente hay que empezar a hacerlo jaja
Mirate este enlace. https://pythonclock.org

[reingart]

@cperezabo si, muy bueno! podes mandar un PR a la rama py3k?

Yo pensaba en hacer algo más automatizado para no tener que mantener dos ramas.
El problema con import future es que en algunos casos no esta soportado (py2.4, py2.5) y todavía hay gente que usa esas versiones.
Pensaba que una vez que la rama py3k este estable, se podría hacer el cambio como rama principal, y luego usar 3to2 o similar para soportar los usuarios que no haya actualizado.
Otra opción es dejar una rama 2.x histórica.

@matuu Python 2.7 va a seguir siendo soportado hasta 2020 (+3 años), y posiblemente luego por algunas empresas (i.e. RedHat?).

En estos momentos comercialmente no es una prioridad para mí, y en mi caso no tengo tiempo/recursos como para dedicarle a una migración extensiva (y de hecho preferiría levantar los tests automatizados y hacer otras limpiezas antes), pero desde ya son bienvenidos a colaborar.

Lo único que necesitaría es que me envíen un acuerdo de contribuidor (similar al de la PSF):
https://github.com/reingart/pyafipws/wiki/ContributorAgreement
y podría darles permisos en el repositorio para que manejen esta rama directamente.

[cperezabo]

@reingart es buena la que planteas de 3to2
Bajo esa mirada deberíamos intentar hacer andar el proyecto únicamente en Python 3 en esa rama y después vemos como lo llevamos a la inversa a Python 2, no preocuparnos por hacerlo híbrido.
No pense que había gente usando Python 2.4 y 2.5 aun jaja, pensé que el mas quedado estaría en Python 2.6

[reingart]

@cperezabo yo tengo que terminar unos webservices nuevos (WSLSP) y ver de pulir otras cuestiones (mejorar builds, tests, intregación continua?)
En cuanto termine eso podría darles una mano con este tema.

"Oficialmente" no podría hacer el cambio a Python3 hasta que este todo listo, documentado, probado y funcionando correctamente (en Linux y Windows, todos los webservices y aplicativos, etc.).
Lamentablemente somos pocos los colaboradores activos y hay muchos usuarios (la mayoría ya actualizó a 2.7 pero no todos), y no quisiera que se genere más ruido o dificultades con esto.

Volviendo al tema, si podes hacer un PR con los cambios y comentar brevemente los pasos sería interesante para poder evaluar el impacto que tendría.
Si luego se puede volver a py2.x con 3to2 creo que estaría ok, aunque preferiría que por ahora se pueda migrar con 2to3 de forma automática (por lo menos hasta que estén estabilizados los webservices nuevos).

Como comentas, no quisiera hacer algo híbrido, es más esfuerzo y el código no queda tan limpio ni se aprovechan las nuevas características.
De hecho, creo algunas cuestiones de Python 3 son muy útiles, especialmente las anotaciones, para mejorar el tema de tipos de datos y conversiones en la interface / archivos de intercambio con otros lenguajes.

[matuu]

Pensé que el soporte se retiraba a principios del 2019, mejor entonces! :-)

[reingart]

FYI para Python 3 se está avanzando en la rama py3k, ver commits recientes para más información, especialmente 89ef2c6
Es necesario tener instalada la biblioteca SOAP, también branch para pysimplesoap/stable_py3k

Los pasos de instalación serían:

git clone git@github.com:pysimplesoap/pysimplesoap -b stable_py3k
cd pysimplesoap
python3 setup.py install
pip3 install httplib2
git clone git@github.com:reingart/pyafipws -b py3k

Para PDF y cuestiones particulares, se debe instalar el resto de los pip3 install -r requirements.txt, comentar m2crypto que por el momento no soporta py3k.

Para pruebas básicas, pueden ejecutar:

python3 -m pyafipws.wsfev1 --prueba

Se agradecen reportes sobre pruebas (tanto exitosas como cuestiones que falten completar por el momento).

Desde ya toda colaboración es más que bienvenida!

[foxcarlos]

Saludos, estoy probando la version py3k con python 3.5 en utils.py en las lineas:
import platform
dist, ver, nick = platform.linux_distribution() if sys.version > (2, 6) else ("", "", "")

Genera error en :
sys.version > (2, 6) devuelve es un string como el siguiente:
'3.5.3 (default, Jan 19 2017, 14:11:04) \n[GCC 6.3.0 20170118]'
por tal motivo esa linea da error "unorderable types: str() > tuple()"

Creo que la forma correcta seria
sys.version_info > (2, 6)

[reingart]

Gracias @foxcarlos por el aporte, ya subi el cambio con el ajuste.
En principio es un tema menor porque solo afectaría a los usuarios con SSOO antiguos.
Además, sólo aplica a la parte de ARBA (COT e IIBB), que por lo que veo necesitan más ajustes para Python3.
Pueden probarlo y cualquier cosa lo vemos

[reingart]

Para instrucciones de instalación ver:

https://github.com/reingart/pyafipws/wiki/Factura-Electronica-Python-3

Gracias @lukio @smarro @jjscarafia et.al. por los PR, ya tiene además algunos otros fixes

[soporteglsistemas]

buenos dias
unbuntu 20.4
he seguido todos los pasos mencionados para
instalcion https://github.com/reingart/pyafipws/wiki/Factura-Electronica-Python-3
cambiando las opciones de pip por pip3 y python por python3
se instalo todo correctamanete sin errores
sin embargo me encuentro con este problema
python3 wsaa.py /home/glspvx/certificados/mcs_homo.crt /home/glspvx/certificados/mcs_homo.key --debug --trace
Traceback (most recent call last):
File "wsaa.py", line 34, in
from .utils import inicializar_y_capturar_excepciones, BaseWS, get_install_dir,
ImportError: attempted relative import with no known parent package

lo mismo para python2.7 funciona correctamente en linux 14.04
agradezco comentarios

[cperezabo]

Hola @reingart ¿cómo podemos sincronizar los últimos cambios de develop a py3k? porque se necesitaría la generación de QR en esa rama. ¿Vos los pensás mover? ¿O hago un merge, ajusto lo necesario y levanto un PR para integrar los cambios?

Por otro lado, ¿qué haría falta terminar para que Python3 sea la versión oficial de este proyecto y Python2 quede como retro compatibilidad?, ya que es muy difícil y se desperdician muchos recursos manteniendo las cosas de la forma en que se hace actualmente me parece.

[lukio]

Hola @cperezabo @reingart estoy en la misma situación.

La rama develop avanzó no solamente con los cambios del nuevo módulo de QR, sino con otras cosas también, que no han sido backporteadas a la rama de python3.

Además, de que varios cambios para la rama python3 que fueron a parar a https://github.com/PyAr/pyafipws no han vuelto a este repositorio.

[cperezabo]

A mi me parece que este proyecto creció bastante y esta demandando muchos esfuerzos distribuidos que se desperdician de cierta forma, y que hay que organizar urgente el trabajo para poder aprovechar el tiempo que le podamos dedicar al mismo y que todos nos veamos favorecidos de eso. Se que hay muchos proyectos en Python2 y que van a seguir existiendo por un tiempo, pero la realidad es que esta muerto, no va a recibir más updates, y hay que mirar a Python3 de forma determinante. En mi experiencia la rama py3k es muy estable. Yo podría colaborar con convertir los tests que @reingart suele poner como --prueba y pasarlos a PyTest para automatizar los mismos y empezar a pisar suelo firme! Ahora con Github Actions no hay que complicarse tanto la vida y menos cuando es open source.

[cperezabo]

¿Alguna noticia sobre este tema? 😃

[reingart]

Buenas!

Comparto el tema de usar integración continua con GitHub actions, incluso estoy viendo de armar Dockerfiles para containers en linux y windows, para poder buildear local 😉

Por suerte el año pasado @NicolasSandoval avanzó bastante con los test (movió todos los --test a pytest) y Travis.
Están listos en https://github.com/PyAr/pyafipws/pulls en cuanto pueda lo veo de mergear.

Estuve analizando para switchear a Python 3, y si bien una parte importante esta funcionando, faltararían ajustar y terminar probar algunas cuestiones:

• Hay varios problemas de unicode ej en wsfev1.py """M�dulo para obtener CAE/CAEA, c�digo de autorizaci�n electr�nico...""" (más allá de que queda feo, esto trae conflictos y habría que convertir a UTF8 de manera definitiva)
• py2exe para python 3 no tiene aún buen soporte para la interface COM en Windows (esto afectaría a usuarios de lenguajes legados como Visual Basic y similar)
• m2crypto habría que deprecarlo, Nico también trabajó para pasar a cryptography y no tener que compilar OpenSSL
• el soporte para tablas dbf, xml, planillas xls y posiblemente otras librerías tendrían que ser revisadas (esto afectaría también a usuarios de lenguajes legados como Fox, dBase, COBOL, etc.)
• los aplicativos visuales PyRECE y PyFactura también posiblemente necesiten ajustes

Por todo esto creo que lo más sano sería convertir la rama develop en Python 3 compatible, por ej con modernize.
Con unit tests podríamos modificar con mas tranquilidad (e incluso en algún momento dividir los módulos básicos de las herramientas e interfaces para otros lenguajes).
Trayendo los cambios de la rama py3k se podría unificar, manteniendo actualizado master para todos los usuarios de este proyecto.

@cperezabo creo que habías armado algo similar con pausterize, desde ya toda sugerencia y colaboración es bienvenida

Espero tener en estos días algo de avance para mostrarles, cualquier cosa avisen.