[Webinar Recording] Polyglot PyCharm for Rich Web Front-ends

The recording of our January 12th webinar, Polyglot PyCharm for Rich Web Front-ends, is now available on JetBrains YouTube Channel. Paul Everitt’s code used in the recording along with the script for each step in the webinar can be found on GitHub.

Polyglot PyCharm for Rich Web Front-ends

Python has long been a staple of web development. In the recent world of “web apps”, though, the browser is playing a larger role. More of the application in a web app is done in JavaScript, in the “frontend”, with Python running UI-less data services in the “backend”. With its IntelliJ/WebStorm foundations, PyCharm can cover modern HTML/CSS/JS workflows. In this webinar, I’ll show building a JS MVC web app talking to a Python backend using REST, all from the perspective of a veteran Python developer.

The list of topics with timing:

00:20 Node Walkthrough
02:22 Webinar Overview
04:40 Repository for code samples
05:10 Flask ToDoMVC Starting Point
08:32 Add “Delete” Button
12:03 Packaging with npm and package.son
21:29 Tooling with aslant
31:45 Automation with npm run scripts
35:10 Move frontend out of backend with CORS
45:00 Pythonic modules with ES6, Babel, and Webpack

Note: The webinar was a huge success. We’ve got a lot of positive feedback in the after-webinar survey. As we hadn’t managed to cover all the topics declared in the webinar plan we decided to fire up another one webinar soon, which is supposed to cover “ES6 Modules with Babel and Webpack” and “Pythonic ES6” topics in more details. Stay tuned for the announcement.

Keep up with the latest PyCharm news on our blog and follow us on Twitter @PyCharm.

The Drive to Develop
– PyCharm team

Posted in Cool Feature, Screencast, Video, Webinar | 4 Comments

[Live Webinar] Polyglot PyCharm for Rich Web Front-ends, January 12

Join us Tuesday, January 12, 15:00 – 16:00 GMT (10:00 AM – 11:00 AM EST) for our free live webinar, Polyglot PyCharm for Rich Web Front-ends featuring Paul Everitt.

pycharm_webinar_Polyglot_PyCharm_for_Rich_Web_Front-ends

Polyglot PyCharm for Rich Web Front-ends
Python has long been a staple of web development. In the recent world of “web apps”, though, the browser is playing a larger role. More of the application in a web app is done in JavaScript, in the “frontend”, with Python running UI-less data services in the “backend”. With its IntelliJ/WebStorm foundations, PyCharm can cover modern HTML/CSS/JS workflows. In this webinar, I’ll show building a JS MVC web app talking to a Python backend using REST, all from the perspective of a veteran Python developer.

About Paul Everitt
Paul Everitt is the PyCharm Developer Evangelist at JetBrains and a partner with Chris McDonough and Tres Seaver at Agendaless Consulting. Before that, Paul was a co-founder with Zope Corporation, taking the first open source application server through $14M of funding. Paul has bootstrapped both the PSF and the Python Software Foundation. Before that, Paul was an officer in the US Navy, starting www.navy.mil in 1993.

Space is limited, so please register now. There will be an opportunity to ask questions during the webinar. A video recording will be made available a few days later.

Keep up with the latest PyCharm news on our blog and follow us on Twitter @PyCharm.

The Drive to Develop
PyCharm team

Posted in Webinar | 1 Comment

PyCharm 5.0.3 update released

As 2015 draws to a close and Christmas is upon us, we’re happy to announce the last release of the year, PyCharm 5.0.3.

Some notable highlights of this bug update release include:

  • a few fixes for performance problems
  • a number of fixes for Docker support
  • fixes for integrated Debugger and Profiler
  • a fix for Django project creation
  • fixes for Python inspections
  • numerous platform and web development improvements

For further details on the bug fixes and changes, please consult the release notes.
PyCharm 5.0.3 has been uploaded and is now available from the download page. It will also be available shortly as a patch update from PyCharm 5.0.2 and 5.0.3 EAP builds. As usual, please report any problem you find in the issue tracker.

If you would like to discuss your experiences with PyCharm, we look forward to your feedback in the comments to this blog post and on Twitter.

Wishing you Merry Christmas on behalf of the entire PyCharm team!

Posted in Release Announcements | 1 Comment

PyCharm 5.0.3 EAP is Available

Having released PyCharm 5.0.2 with a bunch of improvements and performance fixes a few days ago, today we announce the early preview build of PyCharm 5.0.3. The list of bug fixes and improvements for this build can be found here.

Some highlights of the PyCharm 5.0.3 EAP build 143.1453.1 are:

  • a few fixes for Docker support
  • fixes for integrated Debugger and Profiler
  • a fix for minor performance issues
  • a fix for Django project creation
  • numerous platform and web development improvements

Please give PyCharm 5.0.3 EAP a try before its official release and please report any bugs and feature request to our issue tracker.

-PyCharm team

Posted in Early Access Preview | 1 Comment

Using Docker in PyCharm

Modern development workflows emphasize isolation and reproducability in development and production. Docker and its platform approach to containers has become very popular. With PyCharm Professional Edition 5, Docker is now supported as a remote interpreter.

Let’s take a look at PyCharm’s Docker integration in action.

Summary

  • Get a Django-oriented Docker image pulled locally
  • Make a sample Django project
  • Create a Docker interpeter to run it
  • The Django run configuration makes a new container on start and removes it on stop

Overview

In Python, when you run an application – a Django site, a database script, etc. – you are running it in an environment. Python has some tools to manage the environment and make it reproducible, such as virtual environments, pip requirements.txt files, and setup.py dependencies. But what about the non-Python parts of application?

Containers are one solution to this. In Docker, a container is an isolated universe with software, running inside your computer. They are fast and easy to create, start, stop, and destroy. This is ideal, not just for development, but for deployment as well.

PyCharm 5 provides the beginning of a series of steps towards productive development using containers and Docker. Namely, PyCharm 5 supports project interpreters that are executed in a Docker container.

Preparation

First, make sure docker and docker-machine are setup in your environment. The Docker installation is painless and the website docs are quite friendly. You’ll need a Docker “host” virtual machine setup and running, including on Linux. On Windows and OS X, installing the Docker Toolbox is effortless.

Next, we have to decide what software we want in our containers. In Docker, containers are built using “images”: collections of pre-installed software plus configuration that is called during container creation. Unlike other interpreters in PyCharm, you don’t visit the Project Interpreter preferences to add Python packages. All dependencies need to be baked into the Docker image you choose.

This blog post is based on the minimum/docker-django-mysite Docker image, which includes enough Python/Django software to run the PyCharm-generated Django starter project. You can fetch that onto your system with this command:

Once that Docker image is locally available and the Docker “host” is running and knows about it, PyCharm can make Docker interpreters for your project, as containers based on that image.

Alternatively, you can skip this step and later pull in the image while creating the Docker-based remote interpreter by simply typing in the image name during creation.

Note: You have the option of making your own image as well, using a Dockerfile. Once you make the image, you can tell PyCharm to make Docker interpreters based on it.

Create Django Project

Let’s make a Django project, then make a Docker interpreter for it. In PyCharm, choose File -> New Project, click on Django, and follow the normal process for making a Django project.

During project creation, you’ll have to use a local interpreter. If you try to make a Docker interpreter, PyCharm will give a warning saying you can only use a local interpreter.

The result of this step is a directory on your local computer with sample Django code and a Django-specific PyCharm Run Configuration.

Make PyCharm Docker Interpreter

On to the important part. We need to define a “remote interpreter” that runs in a PyCharm Docker container.

First, go to Preferences -> Project Interpreter and click on the gear to the right of Project Interpreter near the top. In the Configure Remote Python Interpreterdialog, click the Docker button.

Click the menu dropdown for Machine Name. It will likely have one entry named default. Choose that, and you will see the following:

docker_interpreter

Choosing default gives PyCharm a way to find the Docker daemon, which can let PyCharm know which images are available locally. Hence the dropdown for Images. Click on the dropdown and choose minimum/docker-django-mysite:latest as the image, then click Ok.

You now have a Docker container that will be used as your project interpreter. PyCharm features like autocompletion, code inspections, and checks will be driven by this interpreter.

Run Django

Now that we have a Docker container for our project interpreter, let’s use our Django-flavored Run Configuration to run it. Just to be safe, edit the run configuration to make sure it is using the Docker-oriented interpreter.

What does PyCharm do when it runs this configuration:

  1. First, it creates and starts a new container based on the image we named when creating the project interpreter.
  2. This container mounts your project directory into the container at /opt/project in the container. Note: On Linux, you currently have to perform this volume mapping manually.
  3. This container also mounts volumes needed for PyCharm to do its work: Python skeletons and Python library sources.
  4. It then executes the run configuration’s Python command.

If you are running PyCharm 5.0.2 or older, there is one fix you need to do:

  • Run -> Edit Configurations and select the PyCharm-generated Djano run configuration
  • In the Host field, enter 0.0.0.0

When you click the “Run” button, Django will be started. Yay, we are running a container! In fact, we can go on to test running, debugging, code coverage, profiling, and all the other ways to run a configuration. But first, let’s click the link in the console to open the Django site in our browser:

django_admin
You can confirm this using the following Docker commands:

This shows the most recently-run container. As you can see, our minimum/docker-django-mysite-based container is currently running.

Likewise, when you click the “Stop” button in PyCharm to stop the running Django configuration, PyCharm not only stops Django, but it also stops the Docker container. In fact, it deletes the container. Each time you run, PyCharm creates a new Docker container and starts it.

You can confirm this. After re-starting the Django run configuration, type:

The value in the CONTAINER ID column, as well as the NAMES value, is different from the previous values we got from running docker ps -l.

Current Limitations

Docker integration in PyCharm is already useful, but is still only a start. Much more is being done for future releases. For example:

  • Docker Compose. This is a big item and a frequently-requested feature. The effort for this is tracked in a YouTrack ticket in the PyCharm ticket system and work is already being scheduled. Please vote and leave any comments you might have.
  • Linux mounts. As noted in the PyCharm online help, on Linux, you have to mount your project directory manually via VirtualBox. This issue is obviated by work on the next point.
  • Customizing the container. Docker lets you pass arguments when creating/running a container. These arguments include volumes to mount and ports to forward. PyCharm doesn’t currently let you customize this in the run configuration, but this is being worked on.
  • Only Django for web ports. If you want a container with HTTP (or any other) ports available, the Django run configuration is the only one, and that is only for HTTP. Other run configurations (Flask, Pyramid, etc.) won’t forward any ports. Nor will attaching to a database, or orchestrating multi-container apps (unless your Dockerfile forwards the ports.) This is really just emphasizing the previous point, and as said there, help is on its way.

Conclusion

With this release we’ve shown the beginnings of what we can do with Docker integration, and the results are promising. Docker has the potential to be a first-class part of PyCharm’s development workflow.

Posted in Cool Feature | 18 Comments

PyCharm 5.0.2 update released along with new JetBrains branding

First, we’re glad to announce the immediate availability of the PyCharm 5.0.2 release update. This update introduces a massive list of bug-fixes and changes described in detail in the Release Notes. The build is already available for download from our website.

PyCharm_400x400_Twitter_logo_whiteSecond, today is a big day for us at JetBrains as we’re rolling out new company branding. You will surely notice a number of visual changes in PyCharm 5.0.2 that have to do with this. Head also to our completely redesigned website, and read about the branding update in this blog post. PyCharm Edu also gets these changes and releases as PyCharm Edu 2.0.3.

 

The most significant fixes in PyCharm 5.0.2 include:

  • numerous visual changes according to the new company branding
  • numerous fixes for different performance issues
  • fixes for docstrings support
  • fixes for Docker and remote interpreters support
  • a number of fixes for scientific tools, including IPython Notebook, matplotlib and miniconda support
  • a few fixes for Django support
  • a number of fixes for the debugger
  • fixes for integrated test runner
  • numerous platform fixes and improvements, including UI and VCS fixes and more

As usual, please report any problems you find in our issue tracker. If you would like to discuss your experiences with PyCharm, we look forward to your feedback in the comments to this blog post and on twitter.

Drive to Develop!
The PyCharm Team

Posted in Release Announcements | 63 Comments

PyCharm 5.0.2 EAP build 143.1183.2 is Available

Today we announce the early preview build of PyCharm 5.0.2 #143.1183.2. The list of bug fixes and improvements for this build can be found in the release notes.

Some highlights of the PyCharm 5.0.2 build 143.1183.2 are:

  • a number of debugger fixes for both Python and JavaScript.
  • a test runner fix for the ‘Rerun failed tests’ action
  • a few fixes for Jinja2
  • a number of platform fixes, including UI and VCS fixes and more

Please give PyCharm 5.0.2 EAP a try before its official release and please report any bugs and feature request to our issue tracker.

Develop with Pleasure!
-PyCharm team

Posted in Early Access Preview | 6 Comments

PyCharm 5.0.2 EAP build 143.1015.4 is Available

Today we announce the second early preview build of PyCharm 5.0.2. The list of bug fixes and improvements for this build can be found here.

Some highlights of the PyCharm 5.0.2 build 143.1015.4 are:

  • fixes for different performance issues
  • fixes for docstrings support
  • a number of fixes for scientific tools, including IPython Notebook, matplotlib and miniconda support
  • a number of fixes for debugger
  • fixes for Docker and remote interpreters support
  • a fix for Django support
  • and more

Please give PyCharm 5.0.2 EAP a try before its official release and please report any bugs and feature request to our issue tracker.

Develop with Pleasure!
-PyCharm team

Posted in Early Access Preview | 1 Comment

Python 3.5 type hinting in PyCharm 5

Python 3.5 introduces type hinting to help code-writing during development. Let’s take a look at this feature and show it in action.

Motivation

Some folks, but not all, like help from their tools when writing code and documentation. For example, lint-like tools can spot errors before your code executes, and editors and IDEs can harness that to show you mistakes, as you type. Particularly for large code bases and large teams, such help is quite valuable.

These mistakes can include passing the wrong type of value to a function. Wouldn’t it be great if you could get that help once typed, or even as you are typing (autocompletion)? Other languages have some concept of type checking. We don’t want to turn Python into a statically-typed language. But can’t we get a little help?

Python’s PEP 484 brings optional type hinting to Python 3.5. Using the typing module, you can provide type hint information in your code. This can be used by yourself or others to flag certain problems, while you are developing.

Quick Example

Code speaks, so let’s start with an example. mypy was the originator of Python 3.5’s typing module. Let’s use one of its examples:

This example shows the most important part of type hinting: it is optional. Python hasn’t changed to suddenly require static typing. But if we add a little more:

…then we can let an IDE such as PyCharm help us:

02a

What Is (and Isn’t) Type Hinting?

There’s a lot of apprehension out there about this new language feature. Before showing more in-depth code, let’s try to clear this up. First, here’s what type hinting is for:

  • Develop better/faster. Think of it like linting, or as Guido said, “linting on steroids”. With the right tools, it can surface mistakes more quickly.
  • Help users of your code. If someone wants to use your function, type hinting helps explain (autocomplete) and flag when they mess up.
  • Documentation. Rather than pack argument and response type information into carefully-formatted docstrings, use something in the language.

So that’s the benefit, but what is type hinting not?

  • Not required. You can ignore it. You can use it a little. You can use it a lot. It’s all the same. Heck, Python itself (at runtime) ignores type hinting.
  • Not static typing. This is not, not, not changing Python into Java. The language is not enforcing anything.
  • Not Performance boosting. Providing type information makes people think of compilation speedups. But this has no impact on Python execution. Also, the Cython and PyPy teams have said these type hints are unlikely to make a difference to them for speedups.
  • Not incompatible. The extra characters added into your code are ignored by older versions of Python 3. This requirement – to be syntactically-valid pre-3.5 – was a constraint on the options for expressing the hints. If you’re one that thinks the syntax is ugly, this constraint is likely to blame.

Type hinting is most useful when you share your code with a consumer: when you publish a library, or code in a project with others, or helping out your future self who needs to live with the sins of your current self.

With all that preface out of the way, let’s take a look at some usages.

Generics

The teeny-tiny examples above just cover a single argument or return value. What if I want to say hello to a list of names?

Python 3.5’s type hinting provides an answer for this. Namely, you can express the hint as “a list of strings”:

What happens if we ignore the hint and supply a list of integers? PyCharm warns us:

04a

PEP 484 refers to hints such as List as “generics”. That is, a hint that contains other hints. An Iterator for example is a list-y kind of generic. As you would expect, dictionaries are supported:

In this case we see an unusual-looking structure: Dict[str, int]. Think of the values between the brackets as “arguments” to the generic Dict type. The first argument is the type of the dictionary keys. The second is the type of the dictionary values.

Optional Values

We are now passing in a string to use for formatting. But maybe we’d like our class to provide a default string. Let’s allow None as a value that can be passed in, in addition to a string:

Alas, type hinting now warns us that the first argument has to be a string:

07

Fortunately there are several ways to solve this, each useful in various circumstances. For example, we could use regular Python and make this a keyword option with a default:

With this, you can omit passing in a format string and instead use a value of None. (Of course, you could skip the following test and just make the format string the keyword default.) If you pass in an integer, though, you’ll get warned:

07a-broken

Here’s another variation: allow your users to pass in a formatting string or False:

The Union type from typing, as shown here, lets the type be from any of the provided type values. In this case, str or bool.

Here, though, is the approach that best conveys the meaning of optional:

That is, PEP 484 type hinting defines a generic type of Optional.

String-Based Hints

I follow a pattern where I use a static method on my class to query for instances. Hey, I saw someone smart post it once, don’t judge me. For example, in a SQLAlchemy model:

Unfortunately, that fails. As the mypy docs explain: “Python does not allow references to a class object before the class is defined.”:

09-broken

To fix this, type hinting has the concept of a forward reference. In the location where you would normally provide the hint, just provide that same hint, but in a string:

This lets the Python interpreter parse the module at import time, then deal with the type hinting later.

Stub Files

As mentioned in the introduction, some people might find all this type hinting to be noise that distracts from the readability of the code. Wouldn’t it be great if you could get the benefits of type hinting, but keep that information separate? Or in other cases, you can’t actually put in the type hints: it’s in old version of Python code (before function annotations), or in C code, or in code you don’t control.

For these cases, Python type hinting provides stub files. These are extra files, named the same as the module they are stubbing, which contain the type hints. For example, imagine we have a simple function in a module with a filename of greeting.py:

No type hinting. Then, imagine a second file, in the same directory, named greeting.pyi:

The addition of the .pyi suffix makes this shadow the original module. PyCharm helps by denoting the stubbing with an asterisk in the gutter, and a mouseover gives more detail:

greeting-broken1

If we now try to “break the rules” of type hinting, we’ll get the same effect we would if we put the type hints directly in our code:

greeting-broken2

Type Aliases

Sometimes the function arguments and return values can get quite unwieldy. Imagine a greeting function which could accept either a list of strings, or a dictionary where each value is a list of strings. Based on this, you’d also need return different types of values.

Here’s what the type hinting would look like:

Gorgeous, isn’t it? Well, not so much. For cases like this, Python 3.5 type hinting provides a type alias: a way to define the type hint information in one place, then use it in one or more other places. Let’s define a type alias for a GreetingType:

That’s a lot tidier, letting the function usage concentrate on the meaning and the declaration contain the noise….erm, provide the detail.

And yes, this section was added in response to a StackOverflow complaint about the unwieldy syntax.

Downsides

For the audience that wants tools to warn them earlier, Python 3.5 type hinting is very valuable. But not everybody falls into that category. They might use simpler editors. Or they might view those extra characters as seriously breaking Python’s readability.

In theory the answer is simple: “Then don’t use type hinting, it’s optional.” But the worry is that if type hinting becomes “best practice”, library authors will be pressured into supporting it. At that point, adoption will go up and you’ll constantly come across Python code that gouges your eyeballs. It won’t feel so optional then.

On the other side of the argument, some might wish it went further. Perhaps it should cover more cases. Perhaps it should bend the language syntax further to avoid the forward-reference comment-based type hinting, or provide a less line-noise-looking way to express complicated typings.

Conclusion

That’s a walkthrough Python 3.5 type hinting: what it is and isn’t, and ways that it can help you write quality code faster. This article isn’t an exhaustive treatment of all the options. For more information, take a look at the mypy examples and PEP 484.

Posted in Cool Feature, Tutorial | 35 Comments

Interview with Quazi Nafiul Islam, Author of ‘Mastering PyCharm’

1316OTPublished a few weeks ago, Mastering PyCharm by Quazi Nafiul Islam reveals the best development practises using PyCharm. Relying on his extensive programming experience using PyCharm, in his book Nafiul delves into essential topics of setting up PyCharm for your needs and then getting the most out of its numerous development features, ranging from the editor basics, setting up look’n feel and essential shortcuts all the way to specialized tools for debugging, version control and web programming. ‘Mastering PyCharm’ is recommended for both beginning Python programmers and those coming to PyCharm from other IDEs or text editors.

We seized the opportunity and interviewed Nafiul. Read on to learn more about the man, his programming experience and his vision.

– Hi Nafiul, could you tell us a bit about yourself and your occupation?

I’m a consultant at my day job, what that basically means is that I deal with a whole range of things from helping startups build their MVP to helping companies optimize their applications (mostly web applications), to even being a support engineer and developer evangelist. I try out different roles, because I want to learn more about software development as a process.

– How long have you been using PyCharm and why you find it as the best tool for Python development?

I’ve been using PyCharm for the past three years. I initially started with just Notepad++. What got me hooked initially was the code completion, but what kept me with PyCharm for so long was that you guys kept on bringing out good feature after good feature, and you went further than any other IDE out there. You folks really delivered on making workflow better.
But, what I also must acknowledge, is that PyCharm not only made me more productive because of code completion and python specific tools, but also because navigation with “Go To Action” and the newer “Search Everywhere”. Also, a lot of people don’t know this, but keymaps and snippets are highly customizable to do almost anything you might desire.

– Had you also used other IDEs or text editors? If yes, could you tell us why you switched from them over to PyCharm?

Many. I’ve tried out Emacs, Atom, Sublime Text, Komodo, Wing, PyDev, NinjaIDE and some others. I’ve never switched though for the single reason that none of them provided the kind of code completion that PyCharm did. PyCharm will even parse your docstrings for completions. Even the community edition of PyCharm is better than some paid editors when it comes to code completion. And that’s just code completion, don’t get me started on navigation, debugging and all the other good stuff.

However, I have to say that PyCharm cheats a little here. For example, you guys knew that it’d be hard convincing vim users to use PyCharm, so you went ahead and created an emulator for vim. That’s what I love about PyCharm, you folks know what people want before people even think of wanting it. So for a lot of people who “switch” over to PyCharm aren’t really switching, they can get the functionality they love in another editor as a plugin most of the time. For example, I love Emacs’ Ace Jump mode. After John Lindquist built the Ace Jump plugin, I rarely used Emacs anymore.

– How much time did it take you to learn PyCharm from scratch? Do you think learning tools is a big part of a developer’s trade?

To use it as well as I do now, it took some time. But, people get the wrong idea when I tell them that. You can be very productive with PyCharm with knowing very little, and you can use “Go To Action”, “Search Everywhere” and the Keymap to just quickly use the shortcuts you end up using the most (there’s even a plugin for making you use more shortcuts). Just by using those three things you’d be much more productive than most other IDEs out there. But you’d get a lot more if you learn about how to use VTL to create your own templates. There’s a tonne more to learn as well, but learning those things will make you more productive and less prone to making some rookie mistakes.

Do I think learning tools are a big part of a developer’s trade? Absolutely. Tools matter immensely when it comes to building things, good tools will help you get the job done with minimal frustration, you’ll enjoy your work more for it too.

– What are your favorite PyCharm features that you can’t imagine working without?

“Search Everywhere”, “Go To Action”, The Debugger and TypeScript stub support for JS code completion (if you use the professional version).

– As a bare minimum, what subsystems and features should new PyCharm users learn first of all?

I think of this as a tree, as I’ve alluded to before. Learn how to use the keymap (which will help you with shortcuts), then learn how to use Search Everywhere, and then learn to use the debugger. I assure you, you will be orders of magnitude more productive if you go down this path.

– Every serious project is not only about Python. It often involves testing, isolation of environment, deployment, version control, and database management. How does Pycharm help manage all this stuff?

Well, that’s the thing PyCharm isn’t only about Python, it’s about a lot of other things as well. It has an amazing database manager, you have JavaScript support, and live debugging. There’s so much stuff packed into a single IDE that it’s ridiculous sometimes.

– What other developer tools help you be more productive? Would you recommend any to other Python developers?

Dash. It basically allow you to search documentation offline very quickly. Probably *the* most useful tool for me other than PyCharm. Dash is for Mac OS, but there is a free alternative called “Zeal”, and it works on pretty much any platform and uses the same doctests that dash does.

– There are several Web frameworks backed by Python, including Django, Flask, Pyramid, and Google App Engine. What are your personal and professional preferences?

Flask. Everything else feels over-engineered, too complicated or designed to build only one kind of web application. Flask is beautifully designed, has a whole host of plugins, and is also very easy to extend.

– There are two major versions of Python currently co-existing: 2.x and 3.x. What do you think about the current state of Python? What’s your take on the future of the language?

I don’t really see it like that. I see fast python and slow python. In other words, if you’re focusing on the language divide, you’re missing the bigger picture. Right now, Python needs fast implementation, and so you’ll see a lot of implementations like pypy and pyston try to solve this problem. They are both mostly focused on python 2. So, in the future, whatever implementation solves the speed problem and provides good stability will win, and whatever version of the language it supports will therefore win. In the world of software, speed talks, and whatever is fast with a good level of abstraction to get the job done will win in the end.

– What do you think makes Python unique as a language?

It feels like writing pseudocode most of the time. It’s just so easy to read. I’ve used plenty of other languages, but nothing feels as readable as python.

– Please recommend two other books on development you enjoyed reading recently or just consider important.

I learned a lot from the Algorithm Design Manual. It is by far the best book out there if you want to understand and use algorithms (and data structures) practically. If you’ve tried reading CLRS and hated it, this is the book for you.

I would highly recommend “What If” by Randall Munroe. I don’t know what you’ll take away from reading this book, but you’ll definitely enjoy reading it.

– Thank you for the interview, Nafiul!

Photo_on_10-7-14_at_11.21_AMQuazi Nafiul Islam is a consultant, speaker and, most recently, an author.

You can buy ‘Mastering PyCharm’ by Quazi Nafiul Islam here. He also runs his own blog (nafiulis.me), so check it out!

Posted in interview | 1 Comment