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 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.
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.
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.
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.
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
Java has a strong user base and while new developers are using new programing languages/technologies like Swift, the user base is lowering quite slow. Many companies have their software built on Java and is unlikely that they will rewrite it in another programming language.
I do like the fact that Python, being a mature language is still one of the most loved one and used in financial field/startups. It’s one of the top that is growing super fast, which is good.
A recent survey found that while developers are into newer languages like Swift, Rust, and Scala, businesses prefer the stalwarts — and Python can bridge the gap between the two
A few weeks ago, I have to write a program in PyGTK that was supposed to be all the time in the background. This application needs to run over Microsoft Windows, and hide in the notification area, wich in Windows is near to the clock.
One of challenges for me in this application is that as it must run in the background there must be a way to raise it, the most easy way to do it is by force the user to click on the small icon in the notification area, but in this case, that was impossible because the computer don’t have any mouse, everything is done with the keyboard.
This time I’m going to talk about putting an image as the application background in Gtk. In Gtk we are used to leave the colors of the application to the theme, but sometimes we will need to use an image as background. I already wrote how to draw a pixbuf in a gtk.DrawingArea (Esp), we could use that, but we will “draw” directly on the widget window instead.
Yes, I said the widget’s window instead the widget itself. You should know that every widget that has been packed in a container has a gtk.gdk.window object and is the responsible for containing your widget. Well, we can draw on that object.
What we need is to create a simple gtk.gdk.Pixbuf and call the gtk.gdk.window.draw_pixbuf method using your widget.window object on the expose-event.
It is just a window with an HBoxButton as container and a Button in the middle. The button draws normal, but the HButtonBox is drawing its gtk.gdk.window with a pixbuf.
The last couple of days I’ve been working with Kivy. For those that don’t know is a framework to create applications in graphical environments and in multiple platforms, all of these in the most easy to use programming language: Python, (And I mean programming language, JavaScript doesn’t count).
Well, its interesting to work with it, basically because I have the influence of GTK+ and having no windows but calling to widgets creates some confusion. Also, there is this Kivy language which is something like what Glade is In GTK but a lot easier to read (actually everything is easier to to read than XML).
I’m just starting to do this, this post is not a “how to do things in Kivy”, but I hope I can write some of those in the next weeks.