Modern Python offers powerful features such as asynchronous programming (using async and await) and memory-efficient data processing with generators and iterators. Leveraging these advancements, primarily found in Python 3, can significantly improve your code’s performance and maintainability. This often necessitates migrating existing Python 2 projects. The migration process can vary from a straightforward conversion to a substantial refactoring. To help you navigate this, we’ll discuss some of the crucial differences between the two Python versions.
1. PRINT:
This one is easy – most of the time it’s just about translating code from:
print "abcd";
to:
print("abcd")
FOSDEM is an annual event for software developers, focused on open source software, happening in Bruxelles during the first weekend of February.
The event this year was the 5th FOSDEM conference I attended, starting from 2010. During the years I have seen it evolve: as the presentation focus moved along with the industry, some topics faded out and got replaced by newer things. Many of these newcomers did not actually gain traction over the years and also faded out at some point.
One of the main transitions I have noticed was the one from abstract or too general things (e.g. discussions on the Linux Kernel or performance tricks in C/C++) towards end products and getting (soon to be) mature technologies applied in order to get clear outcomes.
CloudFormation is the core functionality provided by Amazon Web Services in the area of expressing infrastructure as code. One can write the infrastructure design in either JSON and YAML (with similar syntax keywords); there is also a template designer that may help in putting together the infrastructure elements and their dependencies. The particular details of each resource being defined must be coded out, though.
There are no limitations on the types of resources that can be brought up, as far as I noticed – each resource type provided by Amazon can be coded and subsequently created and provisioned. One can also define an explicit order (e.g. some resource to be created before another), apart from the implicit order that can be deduced (e.g. if an EC2 instance is defined with a IAM Role, the role is always created before the instance). The revert process is also clean: deleting the CloudFormation stack does delete everything created by the stack itself; nothing gets left behind.