Continuando a série sobre o módulo asyncio do Python 3.4, vou apresentar as corotinas e como elas simplificam a escrita de nossos programas com o loop de eventos.

Modificamos também a chamada de execução da corotina, pois agora utilizamos loop.run_until_complete para iniciar nossa corotina principal. Aproveitamos para colocar tudo entre um try-finally para terminar a execução do loop corretamente (mesmo em caso de exceção). Perceba que no exemplo anterior, com call_soon, passamos a função e seus parâmetros, mas não executamos a função em si. No caso de run_until_complete, estamos passando o retorno da chamada de print_and_repeat que é uma corotina, uma vez que a marcamos com o decorador @asyncio.coroutine.

With the release of Python 3.4, I updated my book on Introduction to Programming with Python. Some topics fall outside the scope of the book, which is intended for beginners. I’m going to start writing a series of short posts about some interesting topics that I think are worth discussing and might even be the basis for a new book.

One of the new features in Python 3.4 is the asyncio module, which brings various routines for calling asynchronous methods in Python. Asynchronous programming is a bit different from what we’re used to writing in Python, but it’s an excellent alternative to using threads and a good choice for solving problems with many inputs or outputs (I/O).

I just uploaded all the solved exercises from my book: “Introduction to Programming with Python”.

Book website: http://www.nilo.pro.br/iprog/

Download of exercises: http://www.nilo.pro.br/iprog/exercicios_resolvidos.zip

Online exercises: http://www.nilo.pro.br/html/exercicios/

After using two or more monitors for programming, it’s difficult to go back to using just one. Microsoft Remote Desktop supports multiple monitors, but it usually only works well when both the remote machine and local machines have 2 monitors.

At work, I use a computer with 2 Full HD monitors and a notebook with a tablet resolution -D. This makes it impossible to use the notebook for programming. I normally open a Remote Desktop session in the morning and close it when I leave, often not using the notebook keyboard during the day, which becomes a remote disk and CPU!

Preparation

On July 30, I received my first Raspberry Pi, purchased at Element 14. After a one-month wait, it arrived in the mail, albeit late from Belgium – 9 pm. In reality, it arrived around lunchtime, but since I wasn’t home, the postman left it as regular mail.

The box is small, like a credit card. In fact, I found the computer amidst other letters.

[]

Continuation of the post, originally made in the Python-Brasil list:

I’ll try again, as the thread has already discussed three different things:

1. Code to use in Python programs: why UTF-8 is highly recommended
2. Encodings in general and problems caused and solved by it
3. A bug in Python on Windows, when the prompt is set to page 65001

I’ll try to explain for everyone, as it’s a recurring topic.

But before getting back to these topics, we have to go back to files.

A fellow blogger on Python-Brasil:

The colleagues have already talked about why UTF-8.

I just want to remind that the subject is more complicated than it seems, for example in Python 2.7:

# -*- coding: utf-8 -*-
print "Accents: áéíóúãõç"
print u"Accents2: áéíóúãõç"

Run the program above on Windows, either through IDLE or console:

C:\Users\nilo\Desktop>\Python27\python.exe test.py
Accents: ├í├®├¡├│├║├º├ú├Á
Accents2: áéíóúçãõ

You should have obtained good results only on the Accents2 line. If the string is not marked with unicode, it will be simply printed as a sequence of bytes, without translation. If you have u in front, like in accents2, Python gets that it needs to translate from unicode to cp850, in this case of console here at home. Already on Linux, both lines produce correct results!

Another post from the Python-Brazil list, where we discussed which language is best to learn for programming:

I agree that Python is a great language as a first programming language. But not everything is Hello World and often the professor or course coordinator tries to introduce Java or C++… to make future courses easier. Example: introducing a Java monstrosity in ICC, only to fine-tune it in an object-oriented course. Others do not know Python or dismiss Python as a script.

Of all the superheroes living on Java Island, the most dangerous is XML-Man.

XML-Man resolves everything with the SGML heiress, HTML’s cousin. Everything, everything. If it were possible, he would write Java programs in XML too. The power of XML-Man is to create configuration and management tools that you wouldn’t need if you didn’t have to write everything in XML.

This was my response to a post on the Python-Brasil list about the importance of certifications.

A few years ago, I hired over 100 IT professionals… developers in C++, Java, testers etc. During this period, I learned not to trust any diploma whatsoever.

I hired people from private universities who were better than those from federal or state universities, although this was not the rule, but an exception. If the person hiring is the same one who will work with you, for example your future boss, he looks for someone who can solve his problems, and leaves the diploma and certificate to the HR department to check. I knew many good people who didn’t have a university degree, but that was rare and not the norm. For some IT positions, having a university degree is a luxury… for others it’s absolutely necessary. I know that for network administration, certification is fundamental.