Tag Suggestions

[sco1]

PyDis' Python bot uses !tags to provide brief, canonical explanations for common questions, programming pitfalls, and other Python related topics.

Use this issue to suggest additional tags, bonus points if you help out with the body of the tag as well!

edit: Since there's often an overlap between what's desired for a tag vs. the ability for a wiki article to be more comprehensive, I've expanded the scope of this to also include suggestions for Wiki articles (implemented soon) so you don't have to decide whether or not this belongs as a tag or as a Wiki article.

[sco1]

Heroku

With its free tier, Heroku is a great resource for getting started with a variety of different web-based Python projects. However, the free tier comes with some limitations that make it not scale particularly well, or make it not well suited for certain applications (like discord bots).

This tag should expand on these limitations, and also link to the VPS section of our Resources page (pending) for more info and some possible alternatives for growing your hosting.

[lemonsaurus]

These were suggested back on GitLab, and were never written. If anyone would like write something up for these, we'd be happy for the contribution.

• async
• decorators
• dict comprehensions
• staticmethod

[gdude2002]

My suggestion is an explainer on why discord.py isn't suitable for beginners, and what people need to know in order to work effectively with it.

I'm not sure what to use as the tag name. discord-is-hard? Something like that? And then maybe the content could be along the lines of..

Before talking a Discord bot using the `discord.py` library, please bear 
in mind that **`discord.py` is not beginner-friendly**. We recommend that 
anyone attempting to work with it first attempts to gain some intermediate 
Python experience.

We recommend that all users attempting to work with `discord.py` are 
familiar with the following: **asyncio**, **classes**, **decorators**, 
**pip**, and **how to read Python documentation**.

If you're a beginner and you'd like some help getting started with Python, 
then feel free to check out our 
[resources page](https://pythondiscord.com/info/resources) - where we've 
compiled a list of goodies that we regularly recommend to aspiring 
Python developers.

I admit I'm not 100% confident that that list encompasses everything. Thoughts?

Note that you'll need to remove the extra newlines if you decide to copy this Markdown over to Discord.

[scragly]

Rather than a codeblock of markdown, I feel it's easier to get a feel for it's appearance and how it reads if it was just normal styled text. I don't get distracted by having to replace styles in my head this way, so I've also put it here for reference.

Before talking a Discord bot using the discord.py library, please bear in mind that discord.py is not beginner-friendly. We recommend that anyone attempting to work with it first attempts to gain some intermediate Python experience.

We recommend that all users attempting to work with discord.py are familiar with the following: asyncio, classes, decorators, pip, and how to read Python documentation.

If you're a beginner and you'd like some help getting started with Python, then feel free to check out our resources page - where we've compiled a list of goodies that we regularly recommend to aspiring Python developers.

"Before talking a Discord bot" sounds weird, and also sweeps across other non-discord.py projects which we don't really touch on for the moment. "Before working on a bot with discord.py" may be preferred here.

The list doesn't encompass everything, but that's not the purpose. What you have touches on the more commonly lacking aspects that people don't think to address; the most common issues I've seen being hit are lacking knowledge of classes/instances, asyncio concepts, namespace/scope and interpreter environments (such as installing with pip install discord.py and having it show as not installed when running the script with py scriptname.py). Maybe we could direct each point to their respective official documentation/tutorial also.

For more extensive listings of required knowledge, I do have a section in my guide here:
https://gist.github.com/scragly/095b5278a354d46e86f02d643fc3d64b#required-knowledge
Eventually, I'll be migrating and expanding this (currently basic) guide when we have the django wiki up.

One thing I want to say though is that there's quite a few people whose first exposure to Python is through working with discord.py projects. I myself am included in that. I really hope that such a tag as this doesn't end up being overused, or the default response whenever someone doesn't know something. In fact, if there was even a slim chance of this happening, I'd prefer that this tag simply did not exist, and leaving it to normal human responses to address cases like this.

[gdude2002]

😆

Before talking a Discord bot

Totally my fault, I meant to say "Before working on"!

As discussed in the meta channel, it seems we all agree that a more friendly and lengthy FAQ is a better option. Given that, should we wait for the Django rewrite, or update the FAQ before that happens?

[lemonsaurus]

the FAQ hasn't been ported to Django yet (that would be my job!), so I think it's okay to PR this in before that happens.

[fiskenslakt]

Today I was asked to explain the purpose of if __name__ == '__main__': and after typing out the explanation, I wondered if it might be worth having a tag for this.

The explanation is simple, but to be explained thoroughly, it requires a fair amount of typing. For example, after explaining how __name__ works, demonstrate by showing 2 files, one where __name__ is printed, and another where that file is imported.

[GhostofGoes]

The Python REPL is something I've explained a lot, and it would be useful to have a tag for.

Basically:

• What REPL stands for
• What the REPL console is
• How it's different from running the code in a file

[sco1]

Since there's often an overlap between what's desired for a tag vs. the ability for a wiki article to be more comprehensive, I've expanded the scope of this to also include suggestions for Wiki articles (implemented soon) so you don't have to decide whether or not this belongs as a tag or as a Wiki article.

[fiskenslakt]

putting these here so i remember to do them

anyone is welcome to beat me to it (please 😓)

• REPL
• exit()
• if __name__ == '__main__'
• off-topic
• metasyntactic variables (foo, bar, etc)
• paste (link to paste.pydis.com, explain about saving and url changing)
• xy problem
• parameters vs. arguments
• codeblock [UPDATED] (added info about backticks and other bad formatting)
• self
• classes
• star imports
• inline codeblock
• operator precedence
• bankers rounding
• difference between single and double quotes (talk about consistency and escapes)
• positional and keyword arguments
• *args and **kwargs
• calling function name vs. referencing function name (common gotcha)
• mutable default arguments
• pathlib
• return statement (how it works, it's purpose, etc)
• scope
• indentation (its importance, syntax, etc) [suggested by martmists]
• variables (how references work, link to ned's stuff about this)
• opening files (how open() and its modes work)
• seek (how seeking through a file works)
• relative paths (what they are, how cwd works)
• typing (info on type hints)
• magic methods (in general)
• namespaces
• floating-point arithmetic (precision errors, .1 + .2)
• mutability
• bytecode
• variable swapping
• explicit and implicit line joining
• yield/yield from
• concurrency (multi-threading/processing, asynchronous)
• bitwise arithmetic
• bare asterisk in function signature (keyword only arguments)
• bare forward slash in function signature (positional only arguments)
• integer caching
• properties (@property decorator)
• comparing strings (lexicographical order)
• ternary
• arrays vs lists
• current directory (explain that interpreter looks for files in directory it was invoked in)
• lambda
• generators
• iterators
• __init__
• __str__
• __repr__
• inheritance
• Method Resolution Order
• global interpreter lock
• import (where it looks, packages vs modules, from syntax, etc)
• super()
• bytecode (compilation, interpretation, .pyc files, dis module, etc)
• circular imports
• freezing (pyinstaller and the like, how it works maybe, etc)
• performance (how to speed up your code, timeit module, profile module, more efficient algs, better data structures, multi-threading/processing, C extensions, Cython, pypy)
  this one will obviously have to be fairly brief, mostly providing links for more information
• debugging (pdb, -i flag, assert, well placed print's)
• eval/exec
• IDLE (why it sucks, any other relevant info, etc)
• shebang (sharp bang line #! in source code)

I <3 tags

[MarkKoz]

A common question with Qt is how to have two widgets interact with each other when they're defined in separate modules. I think the topic may be too complex for writing the explanation ourselves. I want to try to find a resource that can cover this clearly but that may be difficult to find. Maybe this is a better fit for the wiki in the future 🤔 .