La versión mayor mas vieja de Python acaba de ser “terminada”, al dejar de tener soporte oficial por parte de la PSF. Python 2.x no tendrá mas actualizaciones.
Desde hace tiempo ya la versión menor de Python se retuvo en 2.7, quedando en el aire la versión 2.8 que nunca vió la luz. Python 3, la versión mayor de Python ha estado entre nosotros desde 2008, 11 años le ha costado para poder ser la unica versión mayor de Python.
Y por que le tomó a Python cambiar por completo un total de 11 años?. Bien la cuestión es que Python 3.x no es compatible con Python 2.x, es decir, si escribes un programa pensando en la sintáxis de Python 2.x es muy probable que no funcione al correrlo con el interprete de Python 3.
La adopción de Python 3 entonces se retraso porque los desarrolladores de las principales librerias y apps tuvieron que empezar a soportar Python 3. El tener dos versiones de Python provocó que muchos desarrolladores ya metidos en Python continuaran con Python 2, las nuevas generaciones empezaron con Python 3 porque era lo mas nuevo, pero las generaciones que de por si usan Python se tomaron mas tiempo.
En mi opinión, depreciar por completo Python 2 está principalmente motivado a que muchos todavia usan Python 2 porque es simplemente mas cómodo continuar con el mecanismo que ha existido durante tanto tiempo en lugar de migrar. Dicho de otro modo, depreciar Python 2 es una forma de obligar a los desarrolladores a usar Python 3.
¿Tu por que crees que Python 2 aguantó tanto (11 años) en ser depreciado?
Este es un “re-post” en español de este otro articulo que escribí en inglés: Python trick: How to make lazy objects?. Si ya leíste aquel articulo igual te invito a que leas este, compares y compartas.
Esta vez voy a hablar de los “lazy objects”, los he llamado así porque son mas o menos similar a lo que usaba con los “Lazy treeviews” en GTK donde el árbol muestra los expansiones pero no se cargan los nodos hijos hasta que expandes el nodo. Lo que quiero entonces es crear objetos que sirvan para contar, que tengan un tipo de dato, pero que no carguen nada de datos hasta que se necesite.
¿Por que haría esto?, bueno, actualmente estoy trabajando en un programa que muestra una lista de clientes y muestra cuántas cuentas tiene, estas cuentas son algo complejas así como crear el objeto para representarlas. Este objeto es responsable de cargar y guardar datos, y cualquier dato necesario es accesado via “propiedades”.
En mi primer intento, el objeto cargaba con los datos tan pronto como el constructor era llamado, pero a veces nunca accedía a la información en dicho objeto, recuerden, un client puede tener muchas (y me refiero, muchas muchas) cuentas, entonces, ¿por que cargar todos los datos si hay una oportunidad de que nunca voy a usar ese dato?. Bueno, está ahí por qué también hay una oportunidad de que voy a necesitar ese dato.
Entonces, como podría crear un objeto y despues cargar los datos cuando alguien los requiera?. Eso podría ser fácil… tal vez no ?. Una aproximación es hacer uso de las “propiedades” de Python, crear el objeto y cuando alguien necesite un valor de este objeto entonces usar la propiedad para obtener el dato, procesarlo y retornar un valor, una propiedad se puede definir así:
He creadola clase “demo” y la propiedad “some_property”.
Python va a llamar el método get_some_property permitiéndote hacer el truco. Pero si tienes un objeto con mas y mas propiedades es mejor obtener todos los datos de una vez y solo usar propiedades para regresar un pedazo de el. Podrías llamar a un método en cada propiedad si el contenedor está vacío pero para mi no es lo mejor.
Lo que podemos hacer, es obtener los datos la primera vez que los necesites, pero como sabría que datos/variables son requeridas en mi objeto?.
Bueno, pues las clases de Python tienen ciertos métodos, los llamados “magic methods”, uno de ellos es __getattribute__. Este método te permite manejar cada petición a cualquier propiedad o variable de clase en tu objeto.
Con esto puedes buscar en tu objeto, saber si el contenedor esta vacío y si está vacío entonces llenarlo con datos antes de retornar el valor de la propiedad ?
Digamos que el objeto demo tiene un diccionario llamado __data donde almacenaremos la información necesaria, también tenemos propiedades que buscarán por esta información. también tiene una referencia a la capa de almacenamiento.
Presta atención que he usado object.__getattribute__ en lugar de self.property, si usara self.propertyesto llamaría a self.__getattribute__ y esto causaría una excepción de recursión.
Con eso, podemos crear un gran numero de objetos de forma rápida, al mismo tiempo que reducimos el uso de memoria. La paga es que obtener los datos será mas caro si llegaremos a requerir todos los datos de todos los objetos al mismo tiempo.
Este es el primero, cuando nos cuentan de un proyecto lo primero que hacemos es empezar a divagar, es mas, ni bien nos estan terminando de contar los requerimientos y ya hemos escogido el lenguaje, el framework y a veces hasta el pilón.
Siempre es importante pensar el proyecto, ¿es viable?, hay que investigar y planear, entonces, escribe, valida los resultados y modifica.
2. Planear demasiado las cosas
También este es un error, a veces sobrepasamos demasiado las cosas y terminamos creando un monstruo porque “en el futuro puede que llegue a necesitar esta característica”, es mejor implementar algo simple y que logre el propósito aunque despues tengamos que reescribr parte del código.
3. Subestimar la calidad del código escrito
La mayor parte del tiempo leemos código, se lee mas de lo que se escribe, si quieres entender que hace tu código dentro de 6 meses es mejor que apliques las convenciones para escribir buen código.
4. Escoger la primera opción
Este va un poco de la mano de la primera, a veces creemos que ya tenemos la solución porque fue lo primero que se nos vino a la mente, pero a veces las soluciones pueden ser mas elegantes y mas simples si las pensamos un poco mas.
5. No Googlear
No somos un sabelotodo, si hay algo que no sabes entonces googlealo, incluso, si lo sabes pero crees que puede hacerse de una forma mejor, igual, googlealo.
6. No usar las estructuras de datos apropiadas
Aprende los “pros” y los “contras” de los tipos de datos de tu lenguaje de programación a usar, algunos te darán flexibilidad y facilidad de usar, algunos te darán velocidad y mejor uso de los recursos.
7. Dejar el código peor de como estaba
A veces en nuestro intento de arreglar algo o de agregar una nueva característica dejamos nuestro código hecho un cochinero, siempre procura dejarlo un poco mejor de cómo lo encontraste.
Usa un IDE que te ayude a formatearlo tu código, con esto ganaras mucho tiempo al dejar un código mas legible.
8. Usar frameworks solo por una pequeña característica
A veces por querer ahorrarnos un poco de código y de pensar, metemos mas y mas dependencias a nuestros programas, total, el CPU en el que va a correr lo soporta, son XX núcleos y 1TB de RAM, debe funcionar perfecto.
Tal vez sí, pero si puedes quitarte una dependencia y hacer ese poquito de código por tu cuenta, hazlo.
I’ve been using PyCharm for professional use since about 1 ½ years now ( I mean paying for the Pro license, I have more time using the Community Edition), and I like a lot what PyCharm help me to do, the Django support is pretty awesome and is super fast even when my computer is a 2012 model.
So, I’m pretty happy with every new version of PyCharm, there are several new features and improvements, you can see them here: What’s New in PyCharm
La cuestión es que JavaScript está presente como bien dice el articulo, en cerca del 95% de los sitios web en el mundo, es un lenguaje de programación que domina la forma en la que las paginas web tienen cierto dinamismo, vaya, para nadie es raro escuchar de la tripleta HTML5+CSS+JavaScript, sin embargo otras tecnologias como Flash o Java decayeron tanto que solo un par de navegadores lo soportan aún.
Python por otro lado es un lenguaje de uso general, muy popular en el backend y en aplicaciones de Machine Learning y computo científico, es su sencillez y madurez lo que le da su popularidad, sin embargo no cuenta con esa exclusividad que tiene JavaScript.
Es JavaScript un mejor lenguaje que Python?. Lo dudo mucho, hay muchos ejemplos de lo que está roto en JavaScript, tanto que hasta juegos sobre sus patrones de igualdad hay. Incluso hay lenguajes que se compilan a JavaScript para hacer las cosas mas “sencillas” y menos susceptibles a errores. Sin embargo, como dije en el párrafo anterior, JavaScript cuenta con esa exclusividad en la web que hace casi imposible que otro lenguaje de programación sea tan popular como él. Si vas a aprender a hacer sitios web tienes por fuerza que aprender a usar JavaScript, incluso si usas algún framework. Otro punto fuerte de JavaScript son los dispositivos móviles, para muchos el tener que mantener la misma app en diferentes plataformas los ha llevado a tener un framework con un lenguaje de programación común, ahí es donde JS ha sido el que ha triunfado, es común encontrarse frameworks que usan JS y “convierten” estas instrucciones a una app nativa, o en el peor de los casos a una especie de web-view con el dinamismo dado por JS.
Como podría Python ganarle terreno a JavaScript?, lo está haciendo muy bien sirviendo desde el backend (como de costumbre), muchos sitios web estan construidos sobre Django, APIs que se han construido sobre Flask, en el computo científico es muy pero muy popular, pero seria genial que Python fuera la base para alguna plataforma móvil, te imaginas escribir apps para dispositivos móviles usando Python de forma nativa? es decir, que el dispositivo use Python directamente, que no se compile a JS, Java/Kotlin u ObjectiveC/Swift.
Cuál es tu predicción a 5 años?, Python será mas popular que JavaScript?.
JavaScript and Python are two influential programming languages for building a wide range of applications.
Guido van Rossum hizo el merge del PR de Victor Stinner, por lo que los términos Master y Slave ya no aparecerán en la versión 3.8 de Python, aunque uno de los PRs quedó fue porque refleja la terminología de las pseudoterminales de UNIX.
Así que váyanse preparando, para eliminar los “child processes” porque como vas a tener a un niño trabajando. Igual los Daemons, y finger tendrá que ser renombrado porque, pues propone un dedo y no se me vayan a ofender por eso…
A ver que opina usted, ¿le gustaría que se dejaran de usar los términos “master” y “slave” o “Maestro” y “Esclavo” de la terminología en Python?.
En lo personal creo que hay muchas cosas mejores que hacer, un par de palabras que no me parecen en absoluto ofensivas porque desde un principio, no estan dirigidas a mi, no se refieren a mi, de hecho, no se refieren a una persona, se refieren a un par de procesos.
Me da un poco de coraje mezclado con tristeza el hecho de que haya personas que con cosas tan triviales como un par de palabras se sientan ofendidas, deberían entender que son solo palabras, las palabras sin contexto no tienen un verdadero significado y dentro del contexto en Python solo se refiere a un proceso que tiene el control sobre otro que no, lo que dice que no es el maestro y el otro el esclavo.
Considerando esto, cualquier palabra podría en algún momento ser ofensiva si nos ponemos a pensar en casos de uso, algo como perro podría ser ofensivo, porque a alguien tal vez le dijeron perro. Al rato va a resultar que no quieren que se diga “Camel Case” porque.. bueno, los camellos pueden sentirse ofendidos.
Usted que opina?
The political correctness debate has now found its way to the world of computers, after a developer from the Python programming language suggested that the words “master” and “slave” should be removed.
En un post anterior les comenté las buenas prácticas en Python, ahora toca hablar de Django, si bien Django esta hecho en el lenguaje Python tiene sus propias convenciones como framework, y seguir estos lineamientos permitirá que tengas proyectos organizados pero sobre todo, que tus compañeros de trabajo (si todos siguen estas recomendaciones) y tu funcionen mejor.
Estilo de código
Aquí no hay mucho que decir, estamos hablando de Python y por lo tanto aplican las reglas de estilo de Código de Python, debes escribir siguiendo la PEP8. Django también tiene sus propias convenciones para escribir código, estas las puedes encontrar aquí , coteja con las de Python, verás que son complementarias.
Settings
settings.py es uno de los módulos principales en tu app, en el se definen los parámetros con los que ha de funcionar tu aplicación, es importante mantener limpio este módulo, e incluso, quitar lo que no es básico para entender el funcionamiento de la aplicación o moverlo a otro lado.
Recordemos que estamos hablando de Python, podemos hacer nuestro settings.py muy modular, e importar lo que se necesita en el momento. Por ejemplo, las configuraciones de logging , o las configuraciones correspondientes al ambiente de desarrollo que son típicamente diferentes a las de producción.
Rutas
Nuestro ambiente de desarrollo esta en una ruta en el almacenamiento diferente de la que estará en producción, es por ello que debemos evitar usar rutas “duras”, en su lugar debemos referirnos a rutas relativas a una que Python nos proporcionará.
Es común ver en el settings.py la variable BASE_DIR y STATIC_ROOT que son variables donde se define la ruta absoluta del proyecto en disco duro, así como donde se guardan los archivos estáticos en disco duro. Estas variables las podemos definir mejor así:
En nuestro proyecto veremos un archivo urls.py que no es mas que un módulo que contiene la información de cada una e las URLs dentro de nuestro proyecto. Me ha tocado ver urls.py tan largos como la cuaresma, y no, no es nada bonito tener un módulo asi de grande, sobre todo porque es confuso.
Que podemos hacer entonces?. Bueno, en principio, tener un urls.py en cada app de tu proyecto, de esta forma cada app será independiente, se reducirá el tamaño del archivo principal y te será m as fácil ubicar las urls en caso de agregar/editar/borrar. La otra, en el caso de que nuestra app tenga muchas urls, es modularizar, puedes repartir las urls en mas módulos dependiendo de cada sección dentro de tu app.
Plantillas
Las plantillas en Django están en básicamente en dos lugares, en el directorio base de tu proyecto y en el de cada app, ahí deberá haber un directorio llamado templates. Lo importante aquí es que las plantillas de tu app deben estar en el directorio templates dentro de tu app. Las plantillas “base” o genéricas podrían estar en tu directorio templates en el directorio base.
Lo mismo que con las plantillas. Cada app debe mantener su contenido estático para cada una de ellas, con esto mantienes la independencia de la app y permites que pueda ser usada en otros proyectos.
El contenido estático pueden ser:
imágenes
JavaScript
CSS
Ojo, no se debe confundir el contenido estático con el contenido que sube el usuario final, este contenido que sube el usuario va al directorio “Media”
Otras convenciones que aplico yo
Estas no están dentro de las convenciones de las buenas prácticas en Django, pero las he usado y me han servido muy bien:
Convertir views.py /forms.py en un paquete
Con esto puedo seccionar las partes de mi app, así tengo Views para cada sección y son generalmente archivos pequeños. Con esto evito tener un “views” de mas de 1000 lineas.
Django desde hace buen tiempo ya cuenta con las Class Views. Antes estábamos acostumbrados a que cada vista era una función, pero los Class Views tienen muchas ventajas sobre las funciones.
Lo que mas me gusta es que puedo crear una clase base y solo extender su uso dependiendo de la sección, por ejemplo, tengo la sección Customers, entonces creo una vista básica de “customers”:
class CustomerBasicView(LoginRequiredMixin ,TemplateView):
template_name = "blank.html"
# Esta variable de clase se llenará con el valor delcliente en turno.
customer = None
def get_context_data(self, *args, **kwargs):
# Crear el contexto y llenar lo "General"
def get(self, request, *args, **kwargs):
# Llamar get_context_data
# Llamar una función en las clases hijas para complementar el contexto
# Ejecutar una función anexa a "get" para finalizar get
# Si no existe dicha función retrnar
return self.render_to_response(self.context)
Y las demás clases solo necesitan heredar de CustomerBasicView
class Dashboard(CustomerBasicView):
template_name="customers/dashboard.html"
class View(CustomerBasicVIew):
template_name="customers/view.html"
class Edit(CusotmerBasicView):
template_name="customers/edit.html"
Como ven?. Dejaré una explicación mas detallada de esto que hago para otro post. Tal vez mañana.
Si te gustó el articulo, compartelo en tus redes sociales, si tienes algo que agregar con toda confianza hazlo en los comentarios.
Si hemos usado Django seguro nos hemos enamorado de su forma de hacer formularios, sobre todo los que están relacionados con un modelo, puesto que son simplísimos. Hay que reconocer lo simple de Django, y gracias a esta simplicidad que no busca satisfacer completamente todas las necesidades podemos encontrarnos con situaciones que pues, no se apegan a lo que queremos hacer.
Programar es divertido, sobre todo si tienes a tus manos el lenguaje de programación y otras herramientas de tu elección, sin embargo, a veces cometemos errores que bien fácil podemos evitar si seguimos estas buenas prácticas.
Python, continua con su desarrollo y aunque en la versión 2.7 ya no tiene grandes cambios si que lo tiene en la versión 3, en esta ocasión la versión 3.7 que incluye una cuantas cositas que si que valen la pena mencionar.
Microsoft, a company that have their very own tools and programming languages is now making it easier for developers to use their favorite language. This time Python have better support in the Visual Studio Code, more specifically in the IntelliSense autocomplete System.
Visual Studio Code is the source code editor that Microsoft released as Open Source and is available in Linux, Windows and MacOS. and thanks to the Python Language Server now have better support for Python. I mean, Python support has been there for a while, but is greatly improved by the PLS.
Do you use Python or Visual Studio?, leave your thoughts in the comment section.
Python Language Server an option for those that code
This is good, as a developer is a PITA to follow all the dependencies your app have. There are several tools to keep them up to date (updating your requirements.txt file) for future builds/updates of your app. But sometimes we just don’t follow the security flaws.
GitHub’s Security Alerts now also work for Python projects, notifying developers about vulnerabilities in software packages that their projects depend on.
Many projects are now migrating from github to #GitLab, this is not because GitHub is a bad service, it’s just because its being acquired by Microsoft.
Even when the official statement says that GitHub will operate independent and with the same policies used right now, many (me included) don’t trust Microsoft. then.. the need to move away from GitHub.
GNOME already made the transition and GIMP is now in GitLab. Are you moving your projects?. Do you think GitHub will finish like Skype did?.
Just yesterday, we shared that The GNOME Project moved to GitLab. This was a major score for GitLab, but also, an important move for GNOME as well — it should greatly improve collaboration between its contributors. GNOME is not alone in its move to that Git-repository manager, however, as GIMP (plus the babl and GEGL libraries) also made the transition. Actually, believe it or not, GNOME is hosting GIMP there.
Quite probably you have a repo in GitHub, and probably the company you work for does too. Aside from the fact that they have to stick with the terms and policies that already govern GitHub, what would you do ?.
For many Linux/OpenSource users this is a dilemma, Microsoft is the “enemy” because for so many years Microsoft tried to kill Linux and now is using it in their cloud offering just because no-one beats Linux in the server (or VPS or whatever the fuck buzz-name you choose), and it seems they like to embrace-extend-extinguish Linux.
Would you keep your code in GitHub knowing Microsoft is behind?. would you move to any other provider?. Would you prefer to use your own Git Server?. Think about it! a leave a comment.
Microsoft may be talking to GitHub about possible acquiring the hosting and development service, according to a report. If it happens, the move may not be as crazy as some might think.
Useful for quick edits, maybe not a full featured IDE (I don’t know why it is called Web IDE instead of Web CodeEditor or something…) because it lacks of several features of the complete IDE, for instance you cannot do debugging in it, just an editor but still useful.
I like the idea that this “web IDE” is Open Source, is available for everyone and it will be integrated in many other parts of gitlab.
Not that I’m surprised, Python is in humble opinion the best balanced programming language, it is really general purpose pl doing from simple automation scripts to complex projects and scientific computing.
I started to use vagrant to hold my development environment, it helps to keep the development environment isolated, since the app will run on a Linux server, with a specific database engine and probably some other specific modules, I don’t want to clutter my OS with all that stuff. More if I plan to work on another project that maybe, have a dependency on other versions of the same base (legacy Django perhaps?)
So, basically, both are fine but it depends on what you need (as with most tools).
In my opinion a less verbose language is better, also, python have tons of packages installable via pip, is C++ extensible (for those scenarios where speed matters) and is present in most platforms.
Also, although there is an Open Source Java implementation, not all the “core” libraries are, I mean, you can’t just replace Oracle’s Java with the Open Source and expect everything will run just fine, probably will, but slower.
Language affiliations are sometimes spread more loosely and broadly across different codebases, frameworks, and platforms
Quite probably you have a repo in GitHub, and probably the company you work for does too. Aside from the fact that they have to stick with the terms and policies that already govern GitHub, what would you do ?.
