Tests pass 😄, @taemery could you help test this on GAE?

Very nice @rahiel :)

+1 @rahiel. Maybe we should add an INFO log mentioning this is a deprecated function and will be removed in the future?

Also, let's move the extended classes to a different submodule, here follows some suggestions:

• ext
• extensions
• contrib

Looking forward to hearing some input from y'all.

I can test this tomorrow, don't merge yet

GAE works! I can put my stamp of approval on this pull request

Thanks @taemery 😊.

+1 @rahiel. Maybe we should add an INFO log mentioning this is a deprecated function and will be removed in the future?

@leandrotoledo there isn't an alternate interface to Updater yet. I also hoped we could avoid changing the library's API.

Also, let's move the extended classes to a different submodule, here follows some suggestions:

That is probably cleaner, but I think the Updater class is now a core part of python-telegram-bot, aren't more people using that to make Bots now? The library now has part that is just a wrapper around the Telegram bot api, and a more elaborate bot framework. If it's just these two classes, they can stay in the same module. (My original PR moved the extended classes over to a new submodule, but I thought it was unnecessary.)

And Updater will be lazily loaded after this PR, so people not using it shouldn't be bothered by it.

That is probably cleaner, but I think the Updater class is now a core part of python-telegram-bot, aren't more people using that to make Bots now?

Agree. I didn't mean though we should make people use Updater less and less. These are great helpers for this library and people, indeed, are using it more. Although IMHO we should, somehow, distinguish between core classes - as in Objects and Methods described on Telegram Bot API webservice, and the extra layers created by the developers of python-telegram-bot, these are on different layers when we talk about the wrapper vs helper classes.

And Updater will be lazily loaded after this PR, so people not using it shouldn't be bothered by it.

Until people get used to it, lazying importing it from a submodule shouldn't bother either.

My 2cents.

@leandrotoledo I agree, the separation is good. If we decide on a name for the submodule, I can move the extended classes over. (I wasn't happy having a telegram.updater.Updater instance before, that's why I rolled it back 😅)

I'm down for telegram.ext.*, who is with (or against) it?

I'm down for telegram.ext.*, who is with (or against) it?

I also like the sound of telegram.ext. I changed some of the tests to import from telegram.ext, but kept an import of Updater from telegramto test for backwards compatibility.

Great work @rahiel, just a minor comment/suggestion:

import warnings
...
warnings.warn("Call to deprecated function, please refer to telegram.ext when using Updater from now on.", category=DeprecationWarning)

Everything else does look good to be merged!

@leandrotoledo the docs mention that DeprecationWarnings are ignored by default, I couldn't see it when using telegram.Updater, I put a normal warning instead.

@rahiel good catch.
All good, merging. Cheers!