The post Xarray joins NumFOCUS Sponsored Projects appeared first on NumFOCUS.

The whole world is confidently stepping into the digital age and the tools that scientists use for research are also changing. Electronic microscopes and telescopes, sending and analysis of information collected during the experiments, in electronic form and much more. In the article Python in science, you will learn why this language is ideal for such purposes.

Introduction

This article will be a continuation of the topic of my prior article Preparing for a Python Developer Interview where I gave my opinions and suggestions that I feel will put you in the best position to out perform other developers competing for a Python developer role. In this article I will be reviewing the popular Udemy course on preparing for a Python developer interview by Nicolas Georges called Master the Python Interview - get the senior & well paid job.

Structure and Topics Covered in the Course

The structure of this course is composed of sections covering the topics listed below where each section ends in either one or more exercises or quizzes to reinforce the material.

The topics covered by Nicolas in his course are as follows:

• Collections with Lists and Tuples
• Intro to OOP in Python
• Unit testing
• Idiomatic Python - Ask for forgiveness not permission
• Must know Python Programming Constructs
• Must know Python Data Structures
• More on OOP in Python
• Data Structure Comprehensions

In the sections that follow I briefly discuss the content of each section along with things that I liked and did not like about each. I conclude with an additional section discussing things that I feel would benefit this Udemy course if they were included or done differently.

Before I get into the individual sections I would like to note that this course was taught using "legacy" Python 2.7 which I feel is a bit of a flaw in the course. The Python community is just over a year away from completely loosing support from the Core developer team with regards to maintenance of Python 2. For this reason I feel it necessary for Python content producers to 100 percent adopt and use Python 3.

Collections with Lists and Tuples

Collections are an enormously important topic in all high level programming languages and Python is certainly no exception to this, so I am quite glad that they were covered in this course. Nicolas does a good job of differentiating between immutability and mutability in relation to lists and tuples which, in my opinion, are the primary differentiators between the two.

Unfortunately there was a charge made about implementation of lists and tuples that I found to be either very misleading or flat out incorrect. In this section Nicolas states that "lists contain homogenous data types while tuples are meant to contain heterogenous data types". At first I thought this was simply a harmless gaffe that all of are susceptible to in life, but later in this section it was reiterated and it was even reenforced in one of the section ending quizzes.

I would like to take some time to correct this statement as I believe that Nicolas was probably trying to describe a common usage trend where lists often contain homogenous data types while tuples can often contain heterogenous data types. In my experience it is true that when I use lists the data in them are usually of the same type. However, it is important to know that both lists and tuples can in fact contain different data types as well as the same.

Here is an example of lists and tuples containing the same data types which are strings representing the letters of my name:

>>> x = ['a','d', 'a', 'm']
>>> y = ('a', 'd', 'a', 'm')

And here is an example of lists and tuples containing different data types of a string representing my name and an integer representing my age:

>>> x = ['Adam', 30]
>>> y = ('Adam', 30)

Intro to OOP in Python

In this section Nicolas explains a very important feature of the Python programming language in that every single element of the language is in the form of an object. From this you can extrapolate that the language is a fully object oriented language. Nicolas goes on to demonstrate and explain the usage and usefulness of many built-in functions that enable to the programmer to inspect objects like dir(), id(), help() as well as others.

However, Nicolas does contradict his earlier statements about homogeny / heterogeneity of data types in lists during this section, which I hope can get cleaned up as I believe most early Python users would become quite confused at this point of the course.

Unit testing

I was most impressed with this section of the course. I feel many, if not most, of the courses on programming often fail to address the importance of testing one's code. Nicolas does an excellent job covering the basics of the unittest module and even devotes considerable time explaining how to use test driven development and why it is important.

Idiomatic Python - Ask for forgiveness not permission

This is the part of the course where Nicolas begins to transition into common conventions, or idioms, of the Python programming community. I do not want to steal Nicolas's thunder by going too far into the explanation of the material covered here because I believe he does a great job explaining what it means to "ask for forgiveness and not permission" and how this convention differs in Python as opposed to other languages, such as Java.

Must know Python Programming Constructs

I was a little confused at why this section of the courses exists and why it was placed in the middle of the course. The topics covered in this section go over the very basic syntactic constructs like boolean expressions, conditionals, and loops. For a course targeting mid to senior level Python developers it felt like this section should be assumed knowledge, but I guess for completeness it is not inappropriate to include it. I do think it would perhaps make better sense to put this material at the beginning of the course, however.

With the above said about this section I do want to leave my review of this section with something that I did find quite positive. I liked that Nicolas explained what it meant in the language to be considered truthy / falsy, to steal a term from the Javascript community. Nicolas did a great job of taking the time to describe the usefulness of the built-in bool() function to test for boolean equivalents to commonly used conditional expressions to test values such as empty lists, empty strings, None, and others.

Must know Python Data Structures

Here Nicolas introduces an additional collection data type, which is known as a set and follows with a comparisons of sets and lists. During this explanation he covers the notion of what it means to be hashable.

However, one thing that I felt was missing here was an explanation of performance benefits of searching a set for inclusion of a value as compared to a list, which is a major benefit of using sets.

More on OOP in Python

This section circles back around to further elaborate on OOP in Python. Nicolas further explains the syntax and meaning of defining a custom class and creating objects from it. He introduces the concepts of defining custom instance attributes and methods as well as goes into what magic methods are and how they are used. In general I felt this section was well covered and is important knowledge for a mid-to-senior level Python developer.

Data Structure Comprehensions

The course finishes with a section on one of my favorite Pythonic features, comprehensions. Here Nicolas demonstrates how comprehensions are used and why you might use them when working with lists and dictionaries.

Topics to Add that would Benefit the Course

Given that the title of this course indicates that its target audience is geared towards mid-to-senior level Python developer roles I feel that not enough content was aimed at more describing more mid-level to advanced features of the language. Below are a set of topics that I believe would elevate the course to better suit its target audience.

A. More idiomatic Python programming techniques are in order. An example of what I mean by this is simply unpacking of tuples and lists into component elements. I see this often demonstrated in advanced texts as well as blogs and personally find it to be congruent with the well known Python idiom that explicit is better than implicit.

I think a coding example would better demonstrate my argument here. Consider the case where you have a list of tuples where each tuple represents the length and width of a rectangle and you would like to iterate over them to calculate and display each one's area. I can think of two variations in which I might implement this: (i) one uses indexing of the tuple elements, and (ii) the other utilizes tuple unpacking into meaningfully named variables.

Using indexing:

>>> shapes = [(1,1), (2,2), (3,2)]
>>> for shape in shapes:
...     print "Area of shape %.2f" % (shape[0] * shape[1])
... 
Area of shape 1.00  
Area of shape 4.00  
Area of shape 6.00  

Using unpacking:

>>> for width, height in shapes:
...     print "Area of shape %.2f" % (width * height)
... 
Area of shape 1.00  
Area of shape 4.00  
Area of shape 6.00  

To me the second example that uses unpacking is more readable and demonstrates a greater idiomatic Python implementation.

B. A discussion of built-in Python functions that perform operations on collections would be a great addition to this course. Many of the built-in functions have been provided because they provide solutions to common programming problems, but have highly optimized implementations that often give significant performance boosts. Some of the built-in functions that I think would be worth mentioning are zip, filter, and map.

For example, say you want to filter a list of numbers and only select those that are even. I can think of two common approaches that would be taken. One that would use a loop to iterate over the items along with a conditional to test each number to see if it is even or not and when even add the number to a separate lists designated for the even numbers. This is likely to be the approach taken by a junior developer who is less familiar with the language. The second would be to use the built in filter() function along with a lambda function to test for even numbers.

In code these two approaches would look like so:

First method:

>>> nums = [1, 2, 3, 4, 5, 6, 7, 8]
>>> even_nums = []
>>> for num in nums:
...     if num % 2 == 0:
...             even_nums.append(num)
... 
>>> even_nums
[2, 4, 6, 8]

Second method:

>>> even_nums = filter(lambda num: num % 2 == 0, nums)
>>> even_nums
[2, 4, 6, 8]

C. Another topic that I think would be beneficial to add to the existing content would be coverage of some of the advanced collection data types such as named tuples and ordered dictionaries. I have often reached for a named tuple in cases where I wanted to represent a real world object but, would be maybe awkward or overkill to use a custom class or the overly used dictionary. Not only are they a great way to organize data representing something in the real word but they have excellent performance, particularly better than a dictionary.

D. Last but certainly not least I would really have liked to see mention of the differences between Python 2 and 3. In particular I feel it would have been important to give some pointers for migrating existing systems from Python 2 to Python 3 which is quickly becoming a priority item for many companies and leading to increased demand for senior Python developers.

Conclusion

In this article I have done my best to give a thorough and honest review of the Udemy course, Master the Python Interview - get the senior & well paid job by Nicolas Georges, which currently has seen about 2,700 enrollments.

My overall opinion of the course is that it is a bit misleading because it's title leads one to believe that the content is geared more towards the mid-to-senior level Python developer, while I found it to be a bit lacking for that. That being said there is some really excellent content covered in this course that will be valuable to entry and junior level Python devs.

As always I thank you for reading and welcome comments and criticisms below.

Introduction

Pickling is a popular method of preserving food. According to Wikipedia, it is also a pretty ancient procedure – although the origins of pickling are unknown, the ancient Mesopotamians probably used the process 4400 years ago. By placing a product in a specific solution, it is possible to drastically increase its shelf life. In other words, it's a method that lets us store food for later consumption.

If you're a Python developer, you might one day find yourself in need of a way to store your Python objects for later use. Well, what if I told you, you can pickle Python objects too?

Serialization

Serialization is a process of transforming objects or data structures into byte streams or strings. A byte stream is, well, a stream of bytes – one byte is composed of 8 bits of zeros and ones. These byte streams can then be stored or transferred easily. This allows the developers to save, for example, configuration data or user's progress, and then store it (on disk or in a database) or send it to another location.

Python objects can also be serialized using a module called Pickle.

One of the main differences between pickling Python objects and pickling vegetables is the inevitable and irreversible change of the pickled food's flavor and texture. Meanwhile, pickled Python objects can be easily unpickled back to their original form. This process, by the way, is universally known as deserialization.

Pickling (or serialization in general) should not be confused with compression. The purpose of pickling is to translate data into a format that can be transferred from RAM to disk. Compression, on the other hand, is a process of encoding data using fewer bits (in order to save disk space).

Serialization is especially useful in any software where it's important to be able to save some progress on disk, quit the program and then load the progress back after reopening the program. Video games might be the most intuitive example of serialization's usefulness, but there are many other programs where saving and loading a user's progress or data is crucial.

Pickle vs JSON

There is a chance that you have heard of JSON (JavaScript Object Notation), which is a popular format that also lets developers save and transmit objects encoded as strings. This method of serialization has some advantages over pickling. JSON format is human-readable, language-independent, and faster than pickle.

It does have, however, some important limitations as well. Most importantly, by default, only a limited subset of Python built-in types can be represented by JSON. With Pickle, we can easily serialize a very large spectrum of Python types, and, importantly, custom classes. This means we don't need to create a custom schema (like we do for JSON) and write error-prone serializers and parsers. All of the heavy liftings is done for you with Pickle.

What can be Pickled and Unpickled

The following types can be serialized and deserialized using the Pickle module:

• All native datatypes supported by Python (booleans, None, integers, floats, complex numbers, strings, bytes, byte arrays)
• Dictionaries, sets, lists, and tuples - as long as they contain pickleable objects
• Functions and classes that are defined at the top level of a module

It is important to remember that pickling is not a language-independent serialization method, therefore your pickled data can only be unpickled using Python. Moreover, it's important to make sure that objects are pickled using the same version of Python that is going to be used to unpickle them. Mixing Python versions, in this case, can cause many problems.

Additionally, functions are pickled by their name references, and not by their value. The resulting pickle does not contain information on the function's code or attributes. Therefore, you have to make sure that the environment where the function is unpickled is able to import the function. In other words, if we pickle a function and then unpickle it in an environment where it's either not defined or not imported, an exception will be raised.

It is also very important to note that pickled objects can be used in malevolent ways. For instance, unpickling data from an untrusted source can result in the execution of a malicious piece of code.

Pickling a Python List

The following very simple example shows the basics of using the Pickle module in Python 3:

import pickle

test_list = ['cucumber', 'pumpkin', 'carrot']

with open('test_pickle.pkl', 'wb') as pickle_out:  
    pickle.dump(test_list, pickle_out)

First, we have to import the pickle module, which is done in line 1. In line 3 we define a simple, three element list that will be pickled.

In line 5 we state that our output pickle file's name will be test_pickle.pkl. By using the wb option, we tell the program that we want to write (w) binary data (b) inside of it (because we want to create a byte stream). Note that the pkl extension is not necessary – we're using it in this tutorial because that's the extension included in Python's documentation.

In line 6 we use the pickle.dump() method to pickle our test list and store it inside the test_pickle.pkl file.

I encourage you to try and open the generated pickle file in your text editor. You'll quickly notice that a byte stream is definitely not a human-readable format.

Unpickling a Python List

Now, let's unpickle the contents of the test pickle file and bring our object back to its original form.

import pickle

with open('test_pickle.pkl', 'rb') as pickle_in:  
    unpickled_list = pickle.load(pickle_in)

print(unpickled_list)  

As you can see, this procedure is not more complicated than when we pickled the object. In line 3 we open our test_pickle.pkl file again, but this time our goal is to read (r) the binary data (b) stored within it.

Next, in line 5, we use the pickle.load() method to unpickle our list and store it in the unpickled_list variable.

You can then print the contents of the list to see for yourself that it is identical to the list we pickled in the previous example. Here is the output from running the code above:

$ python unpickle.py
['cucumber', 'pumpkin', 'carrot']

Pickling and Unpickling Custom Objects

As I mentioned before, using Pickle, you can serialize your own custom objects. Take a look at the following example:

import pickle

class Veggy():  
    def __init__(self):
        self.color = ''
    def set_color(self, color):
        self.color = color

cucumber = Veggy()  
cucumber.set_color('green')

with open('test_pickle.pkl', 'wb') as pickle_out:  
    pickle.dump(cucumber, pickle_out)

with open('test_pickle.pkl', 'rb') as pickle_in:  
    unpickled_cucumber = pickle.load(pickle_in)

print(unpickled_cucumber.color)  

As you can see, this example is almost as simple as the previous one. Between the lines 3 and 7 we define a simple class that contains one attribute and one method that changes this attribute. In line 9 we create an instance of that class and store it in the cucumber variable, and in line 10 we set its attribute color to "green".

Then, using the exact same functions as in the previous example, we pickle and unpickle our freshly created cucumber object. Running the code above results in the following output:

$ python unpickle_custom.py
green  

Remember, that we can only unpickle the object in an environment where the class Veggy is either defined or imported. If we create a new script and try to unpickle the object without importing the Veggy class, we'll get an "AttributeError". For example, execute the following script:

import pickle

with open('test_pickle.pkl', 'rb') as pickle_in:  
    unpickled_cucumber = pickle.load(pickle_in)

print(unpickled_cucumber.color)  

In the output of the script above, you will see the following error:

$ python unpickle_simple.py
Traceback (most recent call last):  
  File "<pyshell#40>", line 2, in <module>
    unpickled_cucumber = pickle.load(pickle_in)
AttributeError: Can't get attribute 'Veggy' on <module '__main__' (built-in)>  

Conclusion

As you can see, thanks to the Pickle module, serialization of Python objects is pretty simple. In our examples, we pickled a simple Python list – but you can use the exact same method to save a large spectrum of Python data types, as long as you make sure your objects contain only other pickleable objects.

Pickling has some disadvantages, the biggest of which might be the fact that you can only unpickle your data using Python – if you need a cross-language solution, JSON is definitely a better option. And finally, remember that pickles can be used to carry the code that you don't necessarily want to execute. Similarly to pickled food, as long as you get your pickles from trusted sources, you should be fine.

PyCharm 2018.2.4 is now available, with some small improvements. You can download this version from our website.

New in This Version

• Various small pipenv improvements
• A bug in our pytest with fixtures support was fixed: previously, if yield statements were used in the fixture, PyCharm would assume that the return type of the function was a Generator. Now, the correct return type is inferred, preventing false positives.
• And more, see the release notes

Download PyCharm 2018.2.4

Get PyCharm from the JetBrains website

If you’re on Ubuntu 16.04 or later, you can use snap to get PyCharm, and stay up to date. You can find the installation instructions on our website.

Preview PyCharm 2018.3

Are you interested in trying the next version of PyCharm already? We’re currently developing PyCharm 2018.3, and you can help us by letting us know how you like our work so far.

New in PyCharm 2018.3 EAP 3

• Faster generation of skeletons for Docker Compose interpreters. If you have used PyCharm Professional Edition with Docker Compose you’ve probably seen that sometimes it takes a bit of time for PyCharm to index your container. This is now a lot faster.
• And more, check out the release notes

To get the EAP version, visit the Early Access Preview (EAP) page on our website. You can also use JetBrains Toolbox to keep PyCharm – and other JetBrains products – up to date.

PyCharm 2018.3 is in development during the EAP phase, therefore not all new features are already available. More features will be added in the coming weeks. As PyCharm 2018.3 is pre-release software, it is not as stable as the release versions. Furthermore, we may decide to change and/or drop certain features as the EAP progresses.

All EAP versions will ship with a built-in EAP license, which means that these versions are free to use for 30 days after the day that they are built. As EAPs are released weekly, you’ll be able to use PyCharm Professional Edition EAP for free for the duration of the EAP program, as long as you upgrade at least once every 30 days.

By Michael Grant AI is undeniably a hot topic right now, and financial services companies are not immune to the hype. And in truth, they shouldn’t be: the applications of advanced AI within financial services are numerous, and the potential for cost savings and new value generation is high.At the same time, the financial services …
Read more →

The post AI Opportunities for Financial Services Companies appeared first on Anaconda.

In the previous part of this series, we started with the basics for kicking off a new Django project. We prepared our virtualenv, installed needed modules to it, created and integrated a new Heroku – project for it and learned how to work with variables in Heroku to control our application with an easy example. We also learned how to check our results locally before we publish it to our production space and how we can add an addon to our Heroku project by adding a PostgreSQL database to it.

Today, we will learn what an “app” is in Django and how to create it. Also, we will learn about and create a so-called URLconf / routing to direct specific URLs to specific parts of our code.

Project, App, Application, … what is all this? 

In Django, there are a few terms, which are a bit confusing at first. The fact that careless people tend to use them as exchangeable terms sometimes(including myself, like I did in the previous part by writing “Creating the Django app” even though we created a project ), confuses beginners even more. So: Let’s begin today’s article with a short definition of these terms:

A project is what we have created using the 

django-admin startproject dtbot .

(A Django project is) a collection of settings for an instance of Django, including database configuration, Django-specific options and application-specific settings.

The terms app and application are harder to distinguish. To make it even more confusing, an “app” is also called a “package“, sometimes. These two terms mean the same thing absolutely and are 100% interchangeable. If any, most people tend to use the term “app” as the thing that lives in your project tree and “package”, when they are talking about a packaged distribution of that code for shipping or download. But generally, these are describing the same thing.
The term “application” does not exist in the Django world as an own term, really. In my experience, people tend to talk about “the application” if “the project” is what they meant in the first place. Another thing which is confusing is the fact that “app” and “application” are not really two different words; “app” is just an abbreviation of the term “application” in the end. Anyways, they are used differently.
An “app” is something which is really doing something active in your project instead of defining settings, routes or basics for anything to base upon, like generating a page, receiving data, applying logic on that requests, and so on.

Again, this is how the Django Tutorial describes the difference between a project and an app:

A project is a collection of configuration and apps for a particular website. A project can contain multiple apps. An app can be in multiple projects.

Why multiple apps?

If you are not too familiar with this concept, it might look like creating several apps in one project is making everything more complicated than it is necessary. In the end, you might complain, you are about to create just such a tiny little application which seems like not being worth the efforts to structure everything in such a complicated way.

The last sentence of the previous quote gives an idea for this already: Reusability is a strong reason. Maybe you want to share the result of your development sooner or later. Or, after having finished this one bot, you might have a great idea for another one, dealing with your shopping list in some way instead of your household-budged. Or maybe these two should even interact with each other later? Or the second bot you create simply does not need huge parts of the functionality of your first bot – why should you carry around “dead” code which makes your bot’s code just more complicated and blown up? Wouldn’t it be great if you had created separated apps for things like:

• User registration
• Calculations and reporting
• Analyzing the message and creating the replies
• …

The point is: You can’t know at the beginning how your project evolves over time or what additional ideas you might have. Separating functionality into apps make it appear a bit overcomplicated, but as soon as you have made your first steps with this, it won’t feel like being complicated anymore. Just stick to it and stay tuned until we have created our app in a minute!

If you want to learn more about apps like: “When does it make sense to separate some functionality to separate apps?” I recommend reading this article about it: 0–100 in Django: Starting an app the right way

Creating the app

A new application is created, using a command from the manage.py script in the root of your project-dir:

(dtbot-hT9CNosh) ~/dtbot $ python manage.py startapp bot
(dtbot-hT9CNosh) ~/dtbot $

… that’s not too exciting, is it? To see what this command has changed in our project, I like to use Git to display all differences:

(dtbot-hT9CNosh) ~/dtbot $ git status
On branch master
Untracked files:
  (use "git add <file>..." to include in what will be committed)

    bot/

nothing added to commit but untracked files present (use "git add" to track)
(dtbot-hT9CNosh) ~/dtbot $ git add .
(dtbot-hT9CNosh) ~/dtbot $ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   bot/__init__.py
    new file:   bot/admin.py
    new file:   bot/apps.py
    new file:   bot/migrations/__init__.py
    new file:   bot/models.py
    new file:   bot/tests.py
    new file:   bot/views.py

(dtbot-hT9CNosh) ~/dtbot $

Seems as if it has created just one additional folder without touching any of our other files. Fine – this way, it isn’t messing things up.

Right now, this is of absolutely no use for us; we need to do some things before we can really start to build something in that app:

Writing a view 

… a what? What’s that?
A view is … more or less: Code. A function, to be even more precise, which decides what happens to a request that hits your app. The easiest view I can possibly think of is a static reply to any request. In other words: Answering any request with the same, static page.
Before I overcomplicate this with my explanations, let’s head for an example:

Views are created in the file 

views.py

bot/views.py

from django.shortcuts import render

# Create your views here.

Just remove that and replace it with the following:

from django.http import HttpResponse

def index(request):
    return HttpResponse("Hello, world. This is the bot app.")

Do not think about “How should I know this is what I need to import and use for a simple HTTP response???” too hard for now – just accept it. This is something that comes with the time; in the beginning, you need to read a lot of docs and lookup examples for nearly every baby-step. That’s normal, you are not stupid or so: Everyone needs to get used to this, first!

Apart from that, it’s pretty obvious what happens here, isn’t it? First, a module is imported, which seems to generate a response, which can be served by the web server to the client then.
A function named 

index

request

request

Alright! But – how to reach that now with our browser? We need to define a so-called URLconf for this, which is what follows next.

Creating a URLconf

A URLconf or “routing configuration” is simply a list of URIs, which points towards a view. For example, we could create a URLconf, which calls for all requests to the URL 

https://our-domain.com/bot/hello

index

bot

Open the file 

dbot/urls.py

from django.contrib import admin
from django.urls import path

urlpatterns = [
    path('admin/', admin.site.urls),
]

Again: Ignore the imports for now. Just take the fact that it works like this for granted for now:
To map the URL 

/bot/hello

index

bot/views.py

We are writing an app, which eventually can be taken and copied to other Django projects later. This app might have several URLs, pointing to different functions inside of it. Also, a Django project may have several apps installed.
Does it really make sense that the potentially complicated or even conflicting URLconf is handled in one central file of the project?
Would you really like to solve a naming conflict like one app demanding the URL 

/conf

Most certainly not. That’s why it’s a common pattern to create sub-paths for each app and “delegating” the URLconf of that branch to the app. This way, you need to create just one single line or each app you are using, instead of dealing with dozens per app and conflicting patterns.
To do that, we are changing the file 

dbot/urls.py

First, we add 

include

django.urls

from django.urls import path, include

Next, we register the path 

bot/

urlpatterns

urlpatterns = [
    path('admin/', admin.site.urls),
    path('bot/', include('bot.urls')),
]

This makes Django search for the file 

bot/urls.py

bot/

bot/hook

bot/urls.py

python manage.py startapp bot

from django.urls import path

from . import views

urlpatterns = [
    path('hello/', views.index),
]

And – we are done setting up our demo-URLconf for now!

To test this, run the HTTP server locally and access http://localhost:8000/bot/hello/ with your browser. This should display the text we entered to our 

index

Stop: Hammertime !!!

I have to admit that I underestimated the extent of this article a lot! That’s why I will make a stop here and postpone the rest of the pre-announced content like creating a database, showing additional Heroku – tools, etc. to the next part to not make this a too big and boring thing to read.

Outlook for the next part of the series

We just learned about some terminology, what an app is and how it is created and made available.

In the next article of this series, we will utilize this freshly gained knowledge to create the hook for our bot, finally. Also, we will create the database. And, because of the lesson I just learned: That’s it – nothing more 

If you liked or disliked this article, I’d love to read that in the comments!

Enjoy coding!

Marc Richter

Born in 1982, Marc Richter is an IT enthusiastic since 1994. He became addicted when he first put hands on their family’s pc and never stopped investigating and exploring new things since then.
He is married to Jennifer Richter and proud father of two wonderful children, Lotta and Linus.
His current professional focus is DevOps and Python development.

An exhaustive bio can be found at this blog post.

Found my articles useful? Maybe you would like to support my efforts and give me a tip then?

We're excited to announce a significant update to QtConsole—the package that powers Spyder's IPython Console interface—which the Spyder team maintains in collaboration with Project Jupyter. Two of the biggest changes—user-selectable syntax highlighting themes, and enhanced external editor/IDE integration—are already built right into Spyder, so they'll likely be of more interest if you use QtConsole standalone or with another editor/IDE. However, most of the other changes should prove quite useful within Spyder as well, and many were in fact suggested and even implemented by users of our IDE. Particular highlights include a block indent/unindent feature, Select-All (Ctrl-Shift-A) being made cell-specific, Ctrl-Backspace and Ctrl-Delete behaving more intelligently across whitespace and line boundaries, Ctrl-D allowing you to easily exit ipdb, input() and the like, and numerous smaller enhancements and bug fixes. If you'd like to learn more about what's new, please check out our article over on the Jupyter blog, where we go over the major changes in more detail, with plenty of screenshots and GIFs to illustrate each feature and how to use it.

To update to the newest version with your existing Spyder install, open an Anaconda Prompt (Windows), Terminal (macOS) or command line (Linux), activate the conda environment or virtualenv/venv of the Spyder install you are using, and run conda update qtconsole (or pip install --upgrade qtconsole, if not using Anaconda). If you'd like to try QtConsole out separate from Spyder or integrate it in with your own editor or IDE, it is also available as a standalone GUI by running jupyter qtconsole from the Python environment where it or Spyder is installed.

If you have any questions, problems or feedback, we'd love to hear from you. Report issues, request features or participate in QtConsole's development at its Github site, and check out its documentation for help using it. For the latest Spyder news, releases, previews and tips, you can follow our Facebook and Twitter, and help support the development on Spyder and its sister projects like QtConsole on OpenCollective.

Our new documentation and Spyder 4 beta 1 have been fully live for some time now; given the dramatic scale of the changes in both, their respective blog posts are still in the works. We'll also have an upcoming article on our official Spyder 4 feature roadmap and more, and Spyder 3.3.2 is due out soon, so keep in right here for your Spyder fix! Until then, happy Spydering and enjoy QtConsole 4.4!