#dev-log
1 messages ยท Page 4 of 1
Connected!
GitHub Actions run 3306779404 succeeded.
ed8b4f7 Edit reaction_check and wait_for_deletion t... - TizzySaurus
Further to this, before we can merge this, we should have a bot PR that implements this logic, so we can actually test the code.
Yep! I'll work on a PR for both bot and lance migration to these utils. :+1:
I think it would be nice if this supported randomcaseing replies to embeds, given this command already supports that through message links, although I don't really mind.
Could you update the docstring to say the argument can be text, a reply, or a message link?
was meant to be a request changes as would like this to be done ^
I think it would be nice if this supported
randomcaseing replies to embeds, given this command already supports that through message links, although I don't really mind.
This isn't really possible to implement without making the code very message, since clean_text_or_reply doesn't have this feature. Users will at least still have the option of doing via message links (and said message link could be in the replied message).
Nice, this seems like a good solution.
I'm wondering if the styling might look a bit better without empty lines between rules, thoughts?
This is already done in a different place (here https://github.com/python-discord/bot-core/blob/db0ff48a574f5b466f3e8dc25cc32c3a9bfc1370/botcore/_bot.py#L155), so shouldn't be needed here.
I don't think we need the nยฐ bit, just e.g. Rule 1 would be fine as that's how we style it elsewhere (in the #rules channel on the server)
c727ef3 Update randomcase docstring to state you can re... - TizzySaurus
GitHub Actions run 3306851750 succeeded.
Oh, that's strange because I searched in the logs and I didn't find it.
Maybe because I was having issues in the first iteration.
Removed !
GitHub Actions run 3306866649 was cancelled.
GitHub Actions run 3306868466 succeeded.
I'm wondering if the styling might look a bit better without empty lines between rules, thoughts?
Humm, I thought it's too jammed, here's an overview

[sir-lancebot] Branch dependabot/pip/pip\-licenses\-3\.5\.5 was force-pushed to `749fb00`
GitHub Actions run 3306901439 succeeded.
Connected!
GitHub Actions run 3306918627 succeeded.
I'm no expert in this particular feature, but it LGTM !
Question: Will this path ever be executed ?
Since we now pass active as True when bringing nominations
Shouldn't this be "Edit a nomination" ?
Since Nomination & NominationEntry are not the same entity
Suggestion: could possible_nominations and possible_nomination be a better fit as names ?
It was refreshed pretty much every time it was accessed which made it pretty pointless, as if you make an API call every time anyway it defeats the point of a cache. There were also a bunch of times where it was refreshed even though it didn't need to be, so i'd expect this PR actually makes less API calls now.
It would be possible to reimplement it properly (in _api.py so it's more contained), although it's not a very high-throughput cog so it's not really necessary and is just extra ...
If target is an int then it gets the nomination straight from that and it can be inactive, rather than if a member/user is passed in which case it does that search for active nominations only.
Good spot, yeah, I'll fix that.
Ah I see now, thanks !
And do we have metrics of number of api calls / duplicated calls ?
GitHub Actions run 3307380080 succeeded.
GitHub Actions run 3310148049 succeeded.
GitHub Actions run 3311785684 succeeded.
6b7d33e Update off-topic etiquette to reflect server size - gustavwilliam
[python-discord/site] New branch created: ot\-etiquette\-update
With more than 350k members, saying that we have โtens of thousands of membersโ seems like an understatement. This PR updates the etiquette to say โhundreds of thousands of membersโ.
GitHub Actions run 3317410220 succeeded.
Connected!
406d622 Add lemon holding back tears - gustavwilliam
[python-discord/branding] New branch created: lemoji/holding\-back\-tears
:lemon_holding_back_tears:
It's important that lemon doesn't always look happy, but he can't always cry either. Some more mature and complex emotionsโlike the emotion of holding back tearsโare also necessary. This PR adds lemon holding back tears.

GitHub Actions run 3318171546 succeeded.
A pure winking lemoji has since been added.
<img width="38" alt="Screenshot 2022-10-25 at 06 37 32" src="https://user-images.githubusercontent.com/65498475/197683780-9c22f8d6-5508-4ab4-8935-8bdfe75b703c.png">
@jb3 can we close this issue, or is there something left to do?
[python-discord/bot] New branch created: rules\-fix
6bde7d9 Update off-topic etiquette to reflect server si... - gustavwilliam
[python-discord/site] branch deleted: ot\-etiquette\-update
Shouldn't this be an empty tuple?
It's incorrect to merely not unpack it. The command expects one string now, not a tuple.
if args is None:
args = ()
else:
args = (args,)
Second case is important too since the rest of the code expects args to be an iterable of strings.
GitHub Actions run 3318370940 succeeded.
What about a simple embed like this?
<img width="538" alt="Screenshot 2022-10-25 at 07 27 09" src="https://user-images.githubusercontent.com/65498475/197689997-a88a11ff-f888-4e81-958e-93380b7b4e33.png">
Here's the raw text:
This help channel has been closed and it's no longer possible to send messages here. If your question wasn't answered yet, feel free to ask in a new help channel by checking out [#โ๏ฝhow-to-get-help](/guild/267624335836053506/channel/704250143020417084/). To maximize your chances of getting a response, check out th...
Here is a hotpatch if you're interested:
from disnake.ext.commands.view import StringView
from disnake.ext.commands.errors import ArgumentParsingError
_original_get_quoted_word = StringView.get_quoted_word
def get_quoted_word(self:StringView):
try:
_original_get_quoted_word(self)
except ArgumentParsingError:
raise RuntimeError
StringView.get_quoted_word = get_quoted_word
Shouldn't this be an empty tuple?
Fixed in latest push
I think it should be
if args is None: args = () else: args = (args,)Second case is important too since the rest of the code expects
argsto be an iterable of strings.
Have changed args to be derived from ctx.message instead
With the new ctx inspection this seems to be the easiest way to keep the tests working. It would be more elegant to rewrite the tests to use the ctx object, but in any case, the tests aren't currently effectively testing the convert portions anyways? (Hence the issue). So I think the test rewrite that also tests the converter can come later?
Err yes, that would probably be better. Trying to make the command work for both actual and test inputs is kinda wack, and properly modifying the test seems like a non-trivial amount of effort.
There seems to be code that handles ArgumentParsingError, so indisriminantely raising RuntimeError in its place seems like it could mess up the parsing of other things
There seems to be code that handles
ArgumentParsingError, so indisriminantely raisingRuntimeErrorin its place seems like it could mess up the parsing of other things
Yep, it would. Oops.
There seems to be code that handles
ArgumentParsingError, so indisriminantely raisingRuntimeErrorin its place seems like it could mess up the parsing of other thingsRapptz/discord.py@
01915fb/discord/ext/commands/core.py#L698-L705
Yeah the monkey patch seems to no longer infinitely loop but breaks string parsing in most other places as well:
<img ...
GitHub Actions run 3321450816 failed.
GitHub Actions run 3321500424 succeeded.
New much simpler fix in 71fdd6c (#2310) as discovered by @ChrisLovering in #dev-oops message
[python-discord/bot] New review comment on pull request #2310: Fix for rules greedy parsing freezing
I don't think this comment is needed, as *args in a command shouldn't be a thing that's used, and having a comment here doesn't stop someone adding it to a new command, that can only be done in PRs.
[python-discord/bot] New review comment on pull request #2310: Fix for rules greedy parsing freezing
I know you didn't add this code in this PR, but it feel wrong? Surely we don't want to break and stop processing the rest of the args if just one of them doesn't match. I think this would be better, so even if one doens't match, we still grab out the rest.
if (kw := word.lower()) in keyword_to_rule_number:
keywords.append(kw)
[python-discord/bot] New review comment on pull request #2310: Fix for rules greedy parsing freezing
I'm thinking maybe it's to do with time spent in checking messages if someone decides to do a rules with 4000 chars or something? Would it be more sensible to impose a parsing limit of, say 50 words?
c5c8e3d Remove comment, arg parse bug - ionite34
f0903dd Merge branch 'rules-fix' of https://github.com/... - ionite34
[python-discord/bot] New review comment on pull request #2310: Fix for rules greedy parsing freezing
Even in that case, it would still only take microseconds. All this loop does it try to convert to an int, on failure it calls .lower() and then does a dict lookup.
All of those are very fast things, so likely won't impact performance enough to warrant the increased complexity of adding a limit of 50 iterations.
Also, I am entirely fine with this being a separate issue/PR, rather than blocking this one.
GitHub Actions run 3321891324 failed.
GitHub Actions run 3321979420 succeeded.
[python-discord/bot] New review comment on pull request #2310: Fix for rules greedy parsing freezing
The behaviour was intended, so people can write a message after the invocation e.g. !rule 1 you didn't break the tos but you did break rule 1 shouldn't show the tos rule
I think the change in behaviour should be reverted.
I think the change in behaviour should be reverted. If we want to change it it can be done in a separate PR after discussing it, but it's out of scope for this PR given the original behaviour was intended
I think that makes sense yeah, usually there's some natural messages after the rules. I reversed the changes in 8f68607 (#2310)
I think the change in behaviour should be reverted. If we want to change it it can be done in a separate PR after discussing it, but it's out of scope for this PR given the original behaviour was intended
Ah right, we should definitely add a comment there explaining that use case then, as it currently just looks wrong to anyone who isn't aware of that.
GitHub Actions run 3322159696 succeeded.
New much simpler fix in
71fdd6c(#2310) as discovered by @ChrisLovering in #dev-oops message
would you please provide the context for this link that isn't public?
New much simpler fix in
71fdd6c(#2310) as discovered by @ChrisLovering in [canary.discord.com/channels/267624335836053506/675756741417369640/1034385695940296704](#dev-oops message)would you please provide the context for this link that isn't public?
It's just this diff that chris posted:
๐ 09...
646e219 port command_wraps/update_wrapper_globals from bot - Numerlor
fcf0e0f add typing-extensions - Numerlor
a3b0ffb Add decorator to block duplicate command invoca... - Numerlor
83f8b2e Check assignments nested in ifs when searching ... - Numerlor
c51a2d7 Only append ids from Name nodes - Numerlor
[python-discord/bot-core] New branch created: Python\-3\.11
This adds support for Python 3.11, making sure to keep support for Python 3.10 in case we're a little slow bumping the bots, but still want to make changes to bot-core.
[python-discord/bot-core] New tag created: v8\.3\.0\-beta
GitHub Actions run 3326313356 succeeded.
We should link
#how-to-get-helpin the dormant help channel embed.Is the justification for this because users will click on a channel in the Dormant category?
Yes.
646e219 port command_wraps/update_wrapper_globals from bot - Numerlor
fcf0e0f add typing-extensions - Numerlor
a3b0ffb Add decorator to block duplicate command invoca... - Numerlor
83f8b2e Check assignments nested in ifs when searching ... - Numerlor
c51a2d7 Only append ids from Name nodes - Numerlor
[python-discord/bot-core] branch deleted: update\-static
6ae7868 Use New Static Build Site API (#122) - HassanAbouelela
While we're at it, could we split up the deps file? A linting group, docs group, and dev group could be nice here. Additionally, if we wanted to we could have downstream projects use the same linting deps by installing that group and remove them from there.
30419e8 Don't cancel all CI lint&test jobs if one fails - ChrisLovering
[python-discord/snekbox] New branch created: bytes\-output
ef3375c Add missing doc dependency - ChrisLovering
31bdfee Ensure the main dep group is installed in CI - ChrisLovering
This can raise discord.errors.HTTPException for an invalid user ID (for example a snowflake too far into the future). This should be handled as the user not being found instead.
I'm 99% sure I can make this error in prod, but would rather save a Sentry alert.
Can discord.errors.HTTPException be raised for any other reason? I wouldn't want bot-core to gobble the error if the client should be handling a reason for raising that error themselves.
I think it will raise it for pretty much any invalid ID
We could make it's a 40X error and raise otherwise
Sounds like it's fine to change this accept to HTTPException then, since NotFound is a sub-class.
6ca77ac Add patreon role configuration - mathstrains21
a44e798 Create patreon.py and add setup - mathstrains21
526ce5f Merge branch 'python-discord:main' into patreon - mathstrains21
380dd5c Add patron message when someone gains a patron ... - mathstrains21
b38ec72 Merge branch 'patreon' of https://github.com/ma... - mathstrains21
GitHub Actions run 3332566333 succeeded.
GitHub Actions run 3332572352 succeeded.
GitHub Actions run 3332585206 succeeded.
GitHub Actions run 3332610067 succeeded.
GitHub Actions run 3332611275 succeeded.
GitHub Actions run 3332609002 succeeded.
No response from author. Changing this to up for grabs.
@Ash-02014 Greetings. What's your status on this PR?
If for whatever reason you're not able to finish this up, we can transfer it to another person.
Thanks!
GitHub Actions run 3332691201 succeeded.
@MaskDuck What's your status on this PR?
It seems that there are some unresolved requests for changes around these parts.
Thanks!
[python-discord/infra] New branch created: add\-role\-creation\-command
9f1b5e2 Add user creation command and associated files - jchristgit
The linter is WRONG! I know this because I wrote it.
@iamericfletcher Greetings. What's your status on this PR?
I'd like to see this merged. If you're not able to complete this, we can transfer it to another person.
Thanks!
@wookie184 have you had the chance to look at the format you requested?
@MarkKoz Hello. What's your status on this PR?
Thanks.
GitHub Actions run 3332780869 succeeded.
@kosayoda Hello. What's your status on this PR?
Thanks!
@bast0006 perhaps you could take over this PR?
@Qwerty-133 What's your status on this PR?
Thanks!
Jeez the review interface just completely broke on me, sorry about that.
Alright whatever I'm doing this manually, just in case this actually didn't work.
@JacobMonck @vivekashok1221 @ToxicKidz @Bluenix2 @onerandomusername please re-review.
Thanks!
GitHub Actions run 3332813179 succeeded.
@meatballs Hello. It seems you have a request for change on this PR.
Please resolve it, so we're able to get this merged.
Thanks!
@ddjerqq Greetings. There seems to be request for changes on this PR.
Would you mind fixing them up?
Thanks!
oh im so sorry, I forgot i was assigned to this! ill fix the issues asap
No problem. Thanks for the quick reply!
@ionite34 @ChrisLovering here's the - original issue where you'll find more details and context in the discussion / PR
Yes, I consider that feasible, but keep in mind that sentences must start with a capital letter. In line 6:
- *slicing* is a way of accessing a part of a sequence by specifying a start index, stop index, and step to take elements at. + *Slicing* is a way of accessing a part of a sequence by specifying a start index, stop index, and step to take elements at.Other than that, I'm blown away at your proposal and I'm definitely accepting it.
Thanks :) And yeah that cap...
13543c4 Bump sentry-sdk from 1.10.0 to 1.10.1 (#1130) - dependabot[bot]
[python-discord/sir-lancebot] branch deleted: randomcase\-reply\-enhancement
9d87134 Add ability to use replied message's content as... - TizzySaurus
GitHub Actions run 3332941390 succeeded.
GitHub Actions run 3332950124 succeeded.
@wookie184 have you had the chance to look at the format you requested?
I think it's alright and doesn't look too jammed, although I don't really mind. Let's leave it as is for now though and see what the next reviewer thinks.
Connected!
GitHub Actions run 3332978328 succeeded.
GitHub Actions run 3332979380 succeeded.
GitHub Actions run 3332974525 succeeded.
Connected!
GitHub Actions run 3332991154 succeeded.
c75984c Bump colorama from 0.4.5 to 0.4.6 (#1131) - dependabot[bot]
Closing this as I think the question was solved, if you're still having issues it's probably easiest if you ask for help on the server.
GitHub Actions run 3333002477 succeeded.
GitHub Actions run 3333006763 succeeded.
Thank you for taking the initiative to create this tag. I think slicing is a great candidate for having a tag, and that we've been without one for too long.
We need to be very intentional about what and how much information is conveyed through a tag. In that light, there's a lot that I'd like to see different about your proposed tag. Let me propose this alternative:
<pre>
aliases: ["slice", "seqslice", "seqslicing", "sequence-slice", "sequence-slicing"]
embed:
title: "Sequen...
@MarkKoz Hello. What's your status on this PR?
Thanks.
I do have some local changes but nothing was competed. I believe I ran into a difficult concurrency problem which led me to writing a custom lock, but I was having trouble achieving what I needed. I'll try to find it this weekend and see if this is something I can continue or not.
Connected!
@Diabolical5777 There's some requests for changes pending. If you're not able to finish up this PR, we can make it up for grabs.
Thanks!
Could we perhaps move this into it's own method? I feel like nested functions and using nonlocal just makes it more confusing and unpythonic.
Minors changes with the exception of extracting the check function into it's own method. Thanks for the PR!
I believe this should work and looks better.
for reaction in ('โ
', 'โ'):
I think it would be better if we were to extract this part out so it's clearer.
Also the prompt should have "members" at the end, other wise it just looks like:
Are you sure you want to ban 5? which doesn't make much sense.
prompt = await ctx.prompt(f"Are you sure you want to ban {len(members)} members?")
if not prompt:
GitHub Actions run 3334627592 succeeded.
What's the requested change? I can see an opinion but it's not one I agree with.
Actually, that's true.
I'll change it!
Agreed. It may be best to leave it out unless it can be explained briefly and clearly how "xxx -m pip install ..." means the package is available if using "xxx file.py"/"xxx -m mymodule" to run the code.
Explains well in detail about the module not found and how to fix but doesn't necessarily mention about what a module actually is. Seems more like a temporary fix rather than teaching the reader what exactly a module is and how to avoid module not found.
Tags must be limited in scope. Otherwise they become long and loose their effectiveness. I don't think it's possible to explain what a module is in this tag in addition to what the error is without making the content long and overwhelming....
GitHub Actions run 3335501674 succeeded.
What do you think about briefly clarifying here that the error happens upon importing the purportedly installed package?
Connected!
GitHub Actions run 3336008683 succeeded.
024919b Bump flake8-bugbear from 22.9.23 to 22.10.25 - dependabot[bot]
12a5cd5 Merge pull request #786 from python-discord/dep... - Xithrius
06c8f5c Bump psycopg2-binary from 2.9.4 to 2.9.5 - dependabot[bot]
3769330 Merge pull request #787 from python-discord/dep... - Xithrius
61c30d8 Bump pyjwt from 2.5.0 to 2.6.0 - dependabot[bot]
GitHub Actions run 3336055941 succeeded.
GitHub Actions run 3336435152 succeeded.
[python-discord/site] New branch created: messages\-in\-past\-n\-days\-endpoint
A GET endpoint that takes data from the body is a bit dodgy which made this a pain ๐ฉ . Am open to any improvements, I considered using a POST but not sure it's worth changing at this point.
Closes #783
GitHub Actions run 3338980122 succeeded.
GitHub Actions run 3339066086 succeeded.
Connected!
GitHub Actions run 3340491509 succeeded.
[python-discord/sir-lancebot] New branch created: Diabolical5777/main
[python-discord/sir-lancebot] branch deleted: Diabolical5777/main
[python-discord/site] New branch created: mbaruh\-bump\-psql
Legend man. LEGEND!
I have small comments. If the comments are introspected, I am approving.
A comment couldn't hurt here as to why we start with {None}. I can understand it, as Chris has lovingly explained it to me.
This part does not make sense to me. If the hash of the file changes, shouldn't we update it here? We don't seem to throw it away in that case either, but just stop updating.
Legend ๐ฅ๐ฅ๐ฅ๐ฅ๐ฅ
Did you test this? Does password authentication still work?
GitHub Actions run 3341051577 succeeded.
This was still being worked out re: conversation in #dev-core, right?
I docker-composed upped and it seems to work fine
We don't fetch the hashes here as documented in the approach methodology in the PR body since it would be too expensive in terms of ratelimits. There are ~100 tags, and it doesn't make sense to make an additional 100 requests to pre-load all the commits. When someone requests a tag, that commit data is fetched and saved, otherwise no commit data will be available until then.
[python-discord/bot] New branch created: mbaruh\-bump\-psql
GitHub Actions run 3341129993 succeeded.
Great Behaviour From Joe Banks In The Dog Park Today.
Yeah, I think I'll just change it to be a POST endpoint.
1e53870 Update pydis_site/apps/content/utils.py - HassanAbouelela
GitHub Actions run 3341374043 succeeded.
GitHub Actions run 3341622416 succeeded.
I believe it would be beneficial to add two more shorthands for invoking the 'Rules' embed: "hw" and "eng". "hw" is a common shorthand for "homework", so it should be associated with the embed for rule 8. Likewise, "eng" is a common abbreviation for "English", so it can be linked with rule 4.
There's a possible race condition here if a user clicks the button multiple times in very short succession (assuming that's possible with ratelimits). In that case, we send out responses multiple times before the self.clicked.append line is hit. The fix would probably be appending to clicked directly below the if statement block.
Since we expect uniqueness of the users, self.clicked should also probably be a set -> self.clicked = {author.id}.
When you click a button, Discord doesn't allow you to click it again until the app responds or times out
This assumes that Discord's side of implementation is bug and race condition-free.
As far as I recall, the Discord API documentation mentions somewhere that events may be delivered multiple times as well. I cannot find it though.
Finally found some free time which fingers crossed might last until as much as the end of the year! So I'll be working on this for the coming weeks. Actually I have already resumed on this, but I have to set up my dev environment all over again and had some problems with docker the last time I tried (honestly I can't even remember if I used the docker setup last year).
Raise by Roie#0089 here:
As of Discord.py 2.0, privileged intents are now required to be explicitly activated.
We would like to add something in the tag body to help clarify this - for example -
Starting from version 2.0, privileged intents must now be passed into the bot constructor as a required keyword argument intents and also be explicitly enabled on the developer portal.
[python-discord/site] Checks Successful on PR: #626 feat: Edit on GitHub button for content articles
GitHub Actions run 3345200421 succeeded.
[python-discord/site] Checks Successful on PR: #626 feat: Edit on GitHub button for content articles
GitHub Actions run 3345465068 succeeded.
[python-discord/site] Checks Successful on PR: #626 feat: Edit on GitHub button for content articles
GitHub Actions run 3345784323 succeeded.
To avoid any more situations like these:
Propose to add:
:warning: This action will apply ban to a staff member,
@user(User Name #8405). To confirm, rerun the command with--force
Description
The bot currently responds to message prefixed with multiple dots that clearly aren't intended as commands, see:

This behaviour is unhelpful and takes up space in the chat.
Expected Behaviour
Any message prefixed with at least three dots should be ignored, this could be changed to 2 dots depending on the frequency of typos. I've said three here since (in my ...
[python-discord/sir-lancebot] New branch created: bug/1109/wolfram\-api\-error\-handling
We could have the confirmation as a button instead of a flag.
What about instead of rerunning the command with --force, which may be abused, a confirmation dialog that you click to confirm?
I like the idea of the button. if the user has one of constants.STAFF_PARTNERS_COMMUNITY_ROLES reply to the user with a warning message and a confirmation button.
I would be willing to take this up
I would be willing to take this up
Sounds good, feel free to self assign
FYI, https://bot-core.pythondiscord.com/main/output/botcore.utils.interactions.html#botcore.utils.interactions.ViewWithUserAndRoleCheck might be a good view to subclass as it comes with some nice checks out of the box
Maybe. In this case the command itself (!ban) will only run if the use is authorized. After that it's only a simple matter of checking if the interaction user is the same as the one who triggered the command
Yea, this just adds a nice helper function to remove the button from the message on timeout
96cc195 Catch more status codes in Wolfram commands - ks129
[python-discord/sir-lancebot] Pull request opened: #1136 Catch more status codes in Wolfram commands
Relevant Issues
Closes #1109
<!-- Link the issue by typing: "Closes #" (Closes #0 to close issue 0 for example). -->
Description
Added catching of all non-200 HTTP codes that didn't get caught before.
Did you:
- [x] Join the Python Discord Community?
- [x] Read all the comments in this template?
- [x] Ensure there is an issue open, or link relevant discord discussions?
- [x] Read and agree to the [contributing guidelines](htt...
GitHub Actions run 3347034769 succeeded.
b893637 Pass args to the Python version switch button - ks129
Closes #2299
Pass arguments to new execution when switching the Python version.
GitHub Actions run 3347871908 succeeded.
How should I go about this?
[python-discord/sir-lancebot] branch deleted: bug/1109/wolfram\-api\-error\-handling
19384dc Catch more status codes in Wolfram commands (#1... - ks129
Connected!
GitHub Actions run 3349537300 succeeded.
GitHub Actions run 3349740414 succeeded.
GitHub Actions run 3349744012 succeeded.
GitHub Actions run 3349751666 succeeded.
GitHub Actions run 3349756432 succeeded.
Marking this as ready for review, feedback welcome!
So,we have to move update_page function before two add_listeners function?
So,we have to move update_page function before two add_listeners function?
Yep! Instead of
event listener
event listener
update page
we want
update page
event listener
event listener
this is my first pull request.Can you help me by telling if I have to select this option and start pull request?

this is my first pull request.Can you help me by telling if I have to select this option and start pull request?
It depends on how you make/made the changes. If you join the discord server (discord.gg/python) and @ me in the #dev-contrib channel I can help you out :)
Relevant Issues
<!-- Link the issue by typing: "Closes #" (Closes #0 to close issue 0 for example). -->
Closes#1122
Description
updated bot/exts/core/help.py file is updated as discussed in issue#1122
Did you:
- [x] Join the Python Discord Community?
- [x] Read all the comments in this template?
- [x] Ensure there is an issue open, or link relevant discord discussions?...
GitHub Actions run 3351882103 succeeded.
Closes #2314
Created a subclass of botcore.utils.Interactions.ViewWithUserAndRoleCheck that will be sent when a moderator attempts to ban staff (helper role or above) in bot/exts/moderation/infraction/_utils.py. Only the !ban command author and moderators are allowed to interact with this view. If cancelled, the view is deleted (NOTE: not the entire message). Similarly, if the timeout (10 seconds) is reached, the view will be deleted (once again, not the entire message). If confirme...
GitHub Actions run 3352958553 failed.
GitHub Actions run 3353085331 succeeded.
Why do you need to assign the message to self.message?
It doesn't seem used to me
Am I missing something? You're returning if the value is True aka even if the staff confirms the ban it will exit the function
What does this do? You don't pass message in any scenario and I can't see the purpose of it.
I also don't see it being used
The superclass uses it in their on_timeout function: https://github.com/python-discord/bot-core/blob/main/botcore/utils/interactions.py#L65-L70
async def on_timeout(self) -> None:
"""Remove the view from ``self.message`` if set."""
if self.message:
with contextlib.suppress(NotFound):
# Cover the case where this message has already been deleted by external means
await self.message.edit(view=None)
Right. Logical fallacy on my part. Will fix ASAP
What does this do? You don't pass
messagein any scenario and I can't see the purpose of it. I also don't see it being used
I see the point of self.message now, however you don't need to pass it into the super class
GitHub Actions run 3353131292 succeeded.
You're absolutely right. I was debating this myself, but I decided to just leave it and have a 1:1 between arguments of the parent class (ViewWithUserAndRoleCheck) and the subclass (StaffBanConfirmationView). It really can't hurt and it's there in case we ever need it if we decide to re-use the same class elsewhere (we might for other commands, like cleanban, warnings, mutes, etc)
async def send(self, channel: TextChannel, message_content: str) -> None:
In my opinion message_content doesn't need to be keyword
We can see what other people think as well
Probably want to use a general warning verbiage here as STAFF_PARTNERS_COMMUNITY_ROLES is more than just Helpers. I like that we warn for all of them.
message_content=f"{user} has an elevated role. Are you sure you want to ban them?",
GitHub Actions run 3354157460 succeeded.
GitHub Actions run 3354529176 succeeded.
Tested, LGTM. Also, I dedicate this PR in honor of @AbooMinister25
Lgtm, good job :)
Also tested this locally w/ a asyncio.sleep(5) in build_page() to simulate the race condition that caused the error this is solving, and it no longer occurs!
Connected!
GitHub Actions run 3356023047 succeeded.
Tried it out, there were no obvious issues, so lgmt.
[python-discord/bot] branch deleted: mbaruh\-bump\-psql
Connected!
GitHub Actions run 3356039478 succeeded.
Tested and seems to fix the bug, thanks ๐
Question: Can't the code used in confirm and cancel be moved to a "private" method instead ?
It's so similair, and the only thing changing is the value
async __set_value(self, interaction: Interaction, button: Button, value: bool):
await interaction.response.defer()
self.value = value
await super().on_timeout()
self.stop()
@discord.ui.button(label="Cancel", style=ButtonStyle.red)
async def cancel(self, interaction: Interaction, but...
@swfarnsworth Your approach could probably be the best one yet.
Note about the potentially confusing commit summary (because I can't edit it):
- Fixed the REPL example (assignments never return)
Assignment expressions (a := b) do return.
GitHub Actions run 3357136712 succeeded.
Since this provides no new information, it can be omitted.
I have no other requests other than removing the two lines indicated. Thank you for integrating my suggestions, and again for taking the initiative to create this tag!
When might we expect snekbox to have a 3.11 build?
The 3.11 image from the 3.11 branch is published (manually currently), and weโll probably upgrade main soon as long there arenโt any dependency issues or similar.
That image currently uses the release candidates for 3.11, I don't see one using 3.11 final
I just removed that.
For all intents and purposes, that shouldn't matter, however we'll use final when updating main.
GitHub Actions run 3359956625 succeeded.
[python-discord/snekbox] New branch created: 3\.11\-upgrade
This PR bumps the snekbox version to the latest stable python version.
- [x] Bump version in dockerfile
- [x] Bump version in documentation
- [x] Relock dependency versions
- [ ] Possibly look into bumping dependency versions?
- [ ] Upgrade and test runtime packages
I'll upgrade where possible to avoid the image having to compile a bunch of packages itself, to speed up builds, however we might have to revisit in the future as I imagine a lot of packages don't have wheels yet.
I might also go ahead and implement #149 since it's a relatively small change. I've already been using compose v2 and everything works as expected of course.
Can you check if these settings are redundant? If so, let's remove it from pre-commit-config.
Will test and report back
Possibly look into bumping dependency versions?
The dependencies only have lower bounds. I think they would only need to be updated if there is a package whose metadata indicates it works with 3.10 and higher, but in practice it doesn't actually support 3.11.
8abe0aa Drop Python Coveralls Dependency - HassanAbouelela
I think you're right on the package dep front.
2f0e717 Bump Pre-Commit Hooks - HassanAbouelela
Finished upgrading and testing runtime packages. All went fine. The following packages needed to build wheels:
forbiddenfruit, pendulum, yarl, multidict
We might want to upgrade them in the future, but overall very little building necessary
As far as I could tell, it did manage to successfully read and use the target-version from here. That said, the target-version flag has very little effect on the output in general, so being certain is relatievly difficult.
ce92e4d Switch To Compose v2 - HassanAbouelela
[python-discord/snekbox] New branch created: 3\.11\-upgrade2
Test PR since actions appear to be broken on #153
[python-discord/snekbox] branch deleted: 3\.11\-upgrade2
0919167 Fix Invalid GitHub Action - HassanAbouelela
What feature are you proposing?
When a user sends multiple messages, they get muted automatically with the python discord bot, and a message is sent, confirming that this user is muted. The feature that I am suggesting is deleting the message after a minute or so.
What is your justification for the proposed feature?
Topical channels that arenโt necessarily used very often may have periods of empty messages, and when a mute message is shown it makes the channel look untidy and messy.
@mbaruh may we have your official seal of approval?
GitHub Actions run 3368396231 succeeded.
It's unrelated to filters as far as I can tell, since the message is sent out of the infractions cog. So the implementation would be adding a check there whether the actor is a bot.
I'm wondering whether we're gonna end up disliking not having the message after a while, but I don't mind trialing it ๐
[python-discord/bot] New branch created: help\-channel\-rewrite
This leverages Discord's new forum channel feature, which removes the need for a lot of our custom logic, simplifying the help channel cog significantly.
Sadly this is a rewrite, so the diff isn't very useful. I'd recommend reviewing just the new code.
Draft until forum channels are fully available.
GitHub Actions run 3372383439 failed.
Draft until forum channels are fully available.
forum channels are out to 90% of community guilds and pydis has early access, why are you waiting for something that has no eta?
An important thing to note is that in general, guilds without the community feature don't have the option to have forum channels. So if you're looking on a guild that doesn't have community, it won't have forum channels.
GitHub Actions run 3374956285 succeeded.
Work has started on the new help system, and given the amount of work this issue will require, I don't think it makes sense to continue. It's not high priority anyway.
Draft until forum channels are fully available.
forum channels are out to 90% of community guilds and pydis has early access, why are you waiting for something that has no eta?
Because our test server, which is marked as community is yet to have them.
Ah, so your test server is in the 10%. Gotcha.
[python-discord/sir-lancebot] New branch created: Diabolical5777/main
[python-discord/sir-lancebot] branch deleted: Diabolical5777/main
[python-discord/sir-lancebot] branch deleted: mentions\-fix
[python-discord/sir-lancebot] branch deleted: fix\-928
[python-discord/sir-lancebot] branch deleted: sentry\_aiohttp
[python-discord/sir-lancebot] branch deleted: sebastiaan/backend/apply\-proper\-check\-name
[python-discord/sir-lancebot] branch deleted: sebastiaan/backend/test\-ci\-linting
[python-discord/sir-lancebot] branch deleted: redis\-persist
[python-discord/sir-lancebot] branch deleted: change\-permissions
[python-discord/sir-lancebot] branch deleted: issue\-command\-hotfix
[python-discord/sir-lancebot] branch deleted: latex\-limits
Context: branches that haven't been updated for 2 years.
[python-discord/bot] branch deleted: feat/1169/codespaces
[python-discord/bot] branch deleted: mfa\-token\-filter
[python-discord/modmail-plugins] branch deleted: test
[python-discord/modmail-plugins] branch deleted: kick\-plugin
[python-discord/modmail-plugins] branch deleted: ChrisLovering\-patch\-1
eb9aadd Bump deps to match latest modmail versions - ChrisLovering
GitHub Actions run 3377204472 succeeded.
GitHub Actions run 3377240955 succeeded.
b9c4162 Install libpangocairo in the Docker image - ChrisLovering
a739161 Ensure libpangovario is in the final image - ChrisLovering
GitHub Actions run 3377637411 succeeded.
@ChrisLovering Any news here?
17838d7 Initialise UserFriendlyDuration superclass - ChrisLovering
e38c22e Update close_message plugin with modmail conver... - ChrisLovering
GitHub Actions run 3378215240 succeeded.
[python-discord/bot] Checks Successful on PR: #2318 Update help channel system to use forum channels
GitHub Actions run 3378255132 succeeded.
GitHub Actions run 3378334287 succeeded.
[python-discord/bot] branch deleted: bug/2299/timeit
8bd4eac set rules command's help upon cog_load - Amrou Bellalouna
fb13976 reinstate the docstrings of "rules" and update ... - Amrou Bellalouna
57053b8 remove Information Cog loading log - Amrou Bellalouna
4a72d92 remove the "nยฐ " from rules help - Amrou Bellalouna
c087ebd remove blank line between different rule keywords - Amrou Bellalouna
GitHub Actions run 3378454357 succeeded.
Wha was the reasoning behind moving the send into this view, rather than doing the "normal" ctx.send with this view as a kwarg?
ae8350c Bump pillow from 9.2.0 to 9.3.0 (#1139) - dependabot[bot]
Connected!
GitHub Actions run 3379937065 succeeded.
Connected!
GitHub Actions run 3379970107 succeeded.
GitHub Actions run 3379982232 succeeded.
Connected!
GitHub Actions run 3380007393 succeeded.
I get this error clicking "Recieve Bookmark"
2022-11-02 18:09:50 | discord.ui.view | ERROR | Ignoring exception in view for item <Button style= url=None disabled=False label='Receive Bookmark' emoji=None row=None>
Traceback (most recent call last):
File "sir-lancebot-i1MlkyY3-py3.10\lib\site-packages\discord\ui\view.py", line 425, in _scheduled_task
await item.callback(interaction)
File "sir-lancebot\bot\exts\utilities\bookmark.py", line 56, in button_callback
if i...
I get this error clicking "Recieve Bookmark"
2022-11-02 18:09:50 | discord.ui.view | ERROR | Ignoring exception in view <SendBookmark timeout=180.0 children=1> for item <Button style=<ButtonStyle.success: 3> url=None disabled=False label='Receive Bookmark' emoji=None row=None> Traceback (most recent call last): File "sir-lancebot-i1MlkyY3-py3.10\lib\site-packages\discord\ui\view.py", line 425, in _scheduled_task await item.callback(interaction) File "...
798c499 Change the endpoint to be a POST not a GET - wookie184
Should be ready for review now
GitHub Actions run 3380356270 succeeded.
6a609a3 Move guides to a subdirectory - wookie184
2972b42 Edit creating-python-environment-windows.md to ... - wookie184
aa1cbc4 Minor improvements to wording and layout - wookie184
GitHub Actions run 3380629145 succeeded.
At the moment I'm not really convinced this is worth having, as I'm not sure what benefit this adds over just using the command.
It seems potentially confusing if it only worked on your own messages, but also I think allowing people to run it on other's code will often result in errors (when using the eval command the code needs to be completely standalone, often code people post wouldn't be).
Interesting. I will fix this.
The only reason I've included it is because setting the self.value to None by default. If I understand how subclassing works in Python, once you include an __init__ of your own in a subclass, it overrides the parent's __init__, yes?
None, really. More of a "convenience" thing than anything, if it's even any more convenient than doing it the other way ๐
It definitely could! Though in this case I'm not 100% sure if it's necessary to do so. It would be relatively little effort to extract the common logic into it's own function, but only 2 functions are sharing this logic.
Yes. We're not directly responding to button's interaction, but sending a separate message. If we want the ban to be a response of the button interaction, we'd have to pass it into the apply_ban function, which would need to have updated tests and update all references. I didn't think it to be worth it.
Connected!
GitHub Actions run 3381887569 succeeded.
Yea, but when we do send the seperate message, we don't use the interaction to do so right?
I wouldn't call it necessary of course.
The decision is totally up to you, thanks!
GitHub Actions run 3392910299 succeeded.
Should there be an explicit exception raised instead of the plain raise usages here?
Currently if this does raise, it would trace the following:
RuntimeError: No active exception to reraise
which might cause confusion later. And since we're matching a specific 400 code, it's pretty trivial for these matches to be non-exhaustive and hit the raise.
GitHub Actions run 3399593872 succeeded.
GitHub Actions run 3399613773 succeeded.
GitHub Actions run 3399614990 succeeded.
It's still in the except block so should just reraise that exception, right?
Looks great wookie, should be much easier to maintain now that it has typing!
Nice use of match case too.
[python-discord/bot-core] New branch created: prepare\-for\-pypi\-release
This renames the package to discord-bot-core, due to naming conflict on pypi, along with updating various peices of metadata in the pyproject.toml file.
[bot-core] Branch prepare\-for\-pypi\-release was force-pushed to `3871748`
[bot-core] Branch prepare\-for\-pypi\-release was force-pushed to `b835a78`
All looks good. If you choose to rename the package consider the approval still valid.
[bot-core] Branch prepare\-for\-pypi\-release was force-pushed to `293869e`
99cc91a Add six as a dev dep - ChrisLovering
[python-discord/bot-core] branch deleted: prepare\-for\-pypi\-release
[python-discord/bot-core] New tag created: v9\.0\.0
7756a97 Refactor to reusable workflow pattern in CI - ChrisLovering
GitHub Actions run 3400764909 succeeded.
Connected!
GitHub Actions run 3400791968 succeeded.
GitHub Actions run 3400869903 succeeded.
@shtlrs My PR has been merged so you can start implementing if you're still interested ๐
that would be incorrect, as it creates a naive datetime object, with the current time offset to UTC. Whereas, what we want here is the current time with UTC as the timezone info.
See the warning in the docs. https://docs.python.org/3/library/datetime.html#datetime.datetime.utcnow
Thoughts on changing this to return 0 for users with no messages?
I didn't do it originally because it would also return 0 for invalid IDs which could potentially be misleading, but now i'm thinking it would probably be more useful if it just returned 0 for the ID if nothing was found.
Looking at the last action run, there were over 50 warnings from github about using deprecated actions and warnings
This solves the simplest of them by replacing all of the ::set-output commands with the new syntax.
See the changelog for more information.
got another one here ๐
I've checked the changelogs and upgraded this on my own projects, this seems to have the single change of changing from node 12 to node 16 which solves another bunch of warnings.
I've changed this to upgrade every gha package that has an update which should solve most if not all of the deprecation warnings
eba537a upgrade actions/checkout to solve deprecation w... - onerandomusername
483eda3 update all gha packages - onerandomusername
a42aed2 downgrade docker/setup-buildx-action to a valid... - onerandomusername
eb4dd4c remove the unnecessary and possibly invalid kub... - onerandomusername
ffd073a Merge pull request #156 from onerandomusername/... - ChrisLovering
I missed an actions/checkout@v2 in test.yaml. Not a big deal, as azure/setup-kubectl will need a bump at some point once they release a new version that doesn't use the set-ouput command
this allows manual rebuilds of the container, eg in the event of a minor python version bump
@wookie184 Would adding a thread_id column for each nomination entry be considered here?
Just before we edit the nomination here after the creating the thread, we attach the newly created thread's id to the nomination entry, which will make retrieval faster.
And then, upon invoking the history, we would add a mention of that thread to the paginated resul...
Sounds good to me!
Previous threads can be added somewhere to the review text in _previous_nominations_review, and adding them to the history command too sounds good.
One note, I think the thread_id column would be on the "nominations" table instead of the "nomination entry" table, although maybe that's what you meant.
[python-discord/site] Pull request opened: #792 Add "thread\_id" as a column in the nomination table
Note
It would be better to wait for another PR in bot to see the full scope.
This is one of the changes required to achieve #2304
We want to be able to traceback threads of earlier nominations for historical purposes.
The purpose is to attach the nomination vote's thread id along with each nomination & display them later on when the history of a particular user is demanded.
GitHub Actions run 3402442840 failed.
@wookie184 Here's the first iteration of this.
However, I wanted your opinion on when should we allow editing the thread_id of a nomination.
And my guess is, it should follow the rest, e.g.:
- It shouldn't be allowed when we're ending a nomination
- It shouldn't be allowed on an inactive nomination
Let me know if I missed something
No, we don't. The message is just sent to the channel as a regular message. IIRC the interaction would "time out" even though we sent a message - since as far as Discord cares we didn't respond to their interaction
GitHub Actions run 3402876115 failed.
Here's a preview of what it would look like
History command

Get review command

Note to core devs:
This PR needs to be merged before this one
Closes #2304
As requested by @bast0006, we want to be able to go back easily in time and look for all the nomination threads of a particular user.
This currently links all the previous threads (as long as they haven't been deleted) to the nomination history of a particular user.
It also lists the thread ids in the .md file when getting a review of a user.
**Pre...
[python-discord/bot] New review comment on pull request #2319: 2304 link previous nomination threads
This could simply become: "Thread not found".
All opinions are welcome
One small suggestion to be considered once opinions have been given.
GitHub Actions run 3403622252 succeeded.
Iโll look into the CI issue soon, leaving this as a reminder.
However, I wanted your opinion on when should we allow editing the
thread_idof a nomination. And my guess is, it should follow the rest, e.g.:1. It shouldn't be allowed when we're ending a nomination 2. It shouldn't be allowed on an inactive nominationLet me know if I missed something
Hmm, I hadn't thought about validation. I don't really mind and don't think it matters too much, although those two things sound good for now. We can always make it mor...
GitHub Actions run 3402442840 failed.
After some testing i've found a bit of an issue, it seems discord will not render thread mentions if they aren't in the user's cache and they will show as #deleted-channel:
.
I think the best option would be to just show the jump_url of the thread instead as they work fine.
Description
I would propose increasing the pattern match for "spooky" in the Halloween reacts to include such fun alternatives as "spoopy", "spookier", "spoopiest", and such.
Reasoning
Following the spirit of the best season; "spoopy" is time honored meme'ry, ripe historic use. It seems a shame to ignore such valuable potential and, indeed, causes me to feel a pang of sadness when a happy little ghost fails to appear whilst I am being spoopy.
.
Could we also use the get_or_fetch_channel utility function (I forget where it's defined, something like bot.utils.channel). This would avoid an API call if the thread is cached.
Haven't tried it out yet but looks good, just a couple comments.
If the thread was deleted thread_id would still be set, so I think we can just say *Not created* here, so it reads something like Vote thread: *Not Created*
I think we need to use the jump URL here too. It's a bit annoying as it's quite long and we can't use the link syntax because it's not in an embed, but I think it should be fine.
GitHub Actions run 3414722983 succeeded.
GitHub Actions run 3416529071 succeeded.
As [discussed in #dev-contrib](#dev-contrib message) I wanted to write a guide for the site on how to add Python to Path since it comes up so often in help channels. wookie already wrote a lot of good stuff on that and other Windows matters (see https://github.com/python-discord/site/pull/773) which here I expanded on and added lots of instructional screenshots.
**The changes I've made are as follows (they're all on the `add...
GitHub Actions run 3420209203 succeeded.
### I `pip` installed a package but when running my code I get a `ModuleNotFoundError`
so try to actually run your code the way it is to ensure that it actually errors.
Actually, some editors can still show that error even if you're showing the correct virtual environment with the installed package.
I don't know what the package was, but I remember this scenario so I just had to ignore it.
We can add a section here that helps people identify the currently active virtual environment in PyCharm.
If you look at the bottom right, you will see your project root's name between parenthesis along with the python version like this.

If you click on that, you can see the full path to your virtual env here

title: Why **not** to Install Python from the Microsoft Store
Or maybe even put it in full capital
Markdown doesn't work in titles sadly, but I'm fine with caps NOT. I had it like that at one point.
Good point. I'll clarify that "normal" probably means Command Prompt or PowerShell.
Is that this https://stackoverflow.com/questions/34365044/pycharm-does-not-recognize-cv2-as-a-module ?
Where the fix is something like from cv2 import cv2. Could add a note to that SO link.
Sure. I added some images and info mentioning these.
Discord.py itself has good docs about this.
I think that we could use those to clarify how they should be activated from portal, then we could add a snippet detailing how to pass them to the bot upon instantiation, while making it explicit that's its only needed for version 2.x
GitHub Actions run 3431805746 succeeded.
Don't focus too much on differentiating between v1 and v2, for all intents and purposes just consider v1 defunct and focus on tailoring the tag content for v2. This is especially important with such a long tag.
This is already stated in the current !intents tag via the 2nd paragraph, no?

To resolve #2313, this PR adds a short disclaimer near the top of the intents tag indicating that discord.py v2.0.0 requires its users to specify intents.
The starting paragraphs have also been revised to provide a clearer distinction between Discord's standard and privileged intents.
The code snippet now demonstrates the message_content intent since it is (generally) a requirement when writing prefix commands, especially with commands.Bot.
GitHub Actions run 3438982279 succeeded.
@TizzySaurus Only partially. The current tag does explain that privileged intents have to be enabled in the dev portal before it can be used in code. However, due to v2.0's breaking API changes, the tag should also say that intents must be defined in code regardless of whether those privileged intents are needed.
966b0f6 Add shtlrs to list of contributors - wookie184
[python-discord/.github] New branch created: wookie184\-add\-shtlrs
Currently the latest version of discord.py's documentation is referenced, which is being synchronized to the development branch of discord.py (i.e. master branch). Their branch may introduce changes to the documentation that are irrelevant / inaccessible to users that installed discord.py from PyPI. To avoid potential confusion with those links, this PR changes them to use the stable version of the docs instead.
This also fixes the link to BucketType in the [customcooldown](https://g...
GitHub Actions run 3439197681 succeeded.
cbbd444 Change discord.py links in tags to use stable v... - thegamecracks
dc9413f Fix reference link in customcooldown.md - thegamecracks
7244f4b Merge pull request #2321 from thegamecracks/dis... - wookie184
GitHub Actions run 3439266133 succeeded.
Connected!
2b6fe6e Add Support For Attributes In Docstrings - HassanAbouelela
[python-discord/bot-core] New branch created: fix\-attributes
This allows class attributes to be defined in docstrings without causing an exception while linking the source code.
Due to the non-static nature of attributes, it's not trivial to link their actual definition, so the chosen lines will actually be all the lines of the parent class.
This resolves the issues experienced by #158. Thanks Chris for debugging this issue ๐
With the changes from #160 and the suggested changes, the docs build correctly:

type (str): Name of the locked resource's type.
id (typing.Hashable): ID of the locked resource.
a7e908a Clean Up Formatting Of Project Name In Docs - HassanAbouelela
[python-discord/bot-core] New comment on pull request #160: Add Support For Attributes In Docstrings
Added in another quick change to bring the docs style more in-line with how it's supposed to look.
| Before | After |
|---|---|
![]() |
![]() |
[python-discord/.github] branch deleted: wookie184\-add\-shtlrs
This looks good, thank you !
I just think that there are some subtle details we could add to make it more explicit.
Suggestion: it has become mandatory for developers to explicitly define the values of these intents in their code.
We might want to add the fact that the privileged intents are initialized to False by default here, to make sure no ones expects it to be the other way around.
We don't have access to the standard intents in the developer portal. What do you think about mentioning that ? We'd want to have people ask the question "Why don't I see these standard intents, am I doing something wrong ?"
We could say the the ones we can define in the portal are the privileged ones.
And maybe, if we want, we could add the link to a detailed technical list of these intents.
[python-discord/bot-core] branch deleted: fix\-attributes
GitHub Actions run 3440710166 succeeded.
PR Author
Workflow Run
Source Branch
Bump-modmail-limits
Maybe it would help to have a code comment explaining what .default() does?
# Enable all standard intents and the `message_content` intent
intents = Intents.default()
intents.message_content = True
Yeah, pointing to the discord.Intents reference is a good idea. I'll link to it in the first paragraph.
I would think that how it's written right now would sufficiently imply that standard intents aren't part of the dev portal, but I can add a short sentence to clarify that.
GitHub Actions run 3443904493 succeeded.
I think this would be quite similar to a recent tag we had about how to ask a question.
The problem was it became somewhat toxic and people started spamming it.
We have alot of new joiners in our community, so this is a scenario that we can expect quite often.
So it would be history repeating itself IMO.
I think it's better if we leave potential helpers ask the question themselves, it would also help us to explicitly identify people that show '' hostility '' towards beginners.
Ah, haven't seen that previous tag before, hence haven't seen the effect it had.
Don't want it to get repeated and get more toxicity than the toxicity there already is that can't be avoided.
Will close the issue for that reason and the one you've mentioned - thanks for your input :)
I can take this one up if approved!
I think the idea
@ChrisLovering proposed is simple and enough.
IIRC the api doesn't allow filtering on the creation date, but we could fetch the active ones and treat them in memory.
The rest should be quite simple.
Idk if we already interact with the Github API or not, and whether this should be in Python Bot or in Bot-core.
[python-discord/bot] Checks Successful on PR: #2318 Update help channel system to use forum channels
GitHub Actions run 3445260191 succeeded.
You can use https://github.com/python-discord/bot/blob/main/bot/exts/recruitment/talentpool/_api.py#L34 to get a lsit of active nominations (if you set active=True) then you can look to see which are stale and then archive the votes.
We don't have generic helpers for interacting with the GitHub API as far as I know. We've got a few cogs that interact with GitHub though.
Yes that's the endpoint I was referring to.
And that's also what I meant by there isn't a way to get active nominations based on a certain date and thus, we treat them in memory.
Do you have an example in mind of these cogs? Otherwise I can look them up myself.
For the emoji, is the one you mentioned up for discussion? ( just curious to see if there's one that might fit better)
I guess we could have the user ids as comma-separated-values, but we'd be running the risk of having too long query strings :/
I think it's fine to have this as a POST endpoint, even though it "sounds" wrong.
The only way to make this a GET would be to fetch the data of one user, but it would basically be a waste of bandwidth.
I'm saying this because I don't know what was discussed in #dev-core, so just shooting out ideas.
As for
environments.md:- Added
envsalias - Moved
Python Environmentsto the embed's title field - Unwrapped
sys.executablesince it's a REPL example
- Added
identity.md: Converted the example with lists to a snippet from a REPL session.inline.md: Added info about including a backtick in an inline code snippet.listcomps.md:ifin list comprehensions is an expression, not a statement, so I changed that.local-file.md: Short explanation ofrb, changed modal verb i...
GitHub Actions run 3446962130 succeeded.
Thoughts on changing this to return 0 for users with no messages?
I didn't do it originally because it would also return 0 for invalid IDs which could potentially be misleading, but now I'm thinking it would probably be more useful if it just returned 0 for the ID if nothing was found.
I think it would be a good idea to return 0 for users with no messages.
Currently, if at least one id is invalid, the request won't be successful and will return with the encountered errors.
...
Statements must be separated by newlines or semicolons, that's why.
Neither statement nor expression seem like appropriate descriptions since the if is not a standalone thing in the context of a comprehension. The documentation calls them "if clauses".
That's a substantial reduction of the amount of code we had.
I unfortunately cannot test this since I don't have access to the forum feature.
I left some comments here & there, thanks Chris !
I think this needs to be changed to state that it sends a jump URL of the help post/thread to the owner or sthg like that
if starter_message can be null when it's not cached, wouldn't we want to try to fetch it anyways since it'll have the same id as the thread ?
blank=True only makes sense on string fields, as far as I'm aware? https://docs.djangoproject.com/en/4.1/ref/models/fields/#blank
GitHub Actions run 3451297253 succeeded.
You're correct, it's mostly used for validation purposes.
Having it as nullable should suffice.
I'll remove it
GitHub Actions run 3451393539 succeeded.
I could modify so it's "clause", not "expression" nor "statement".
proposed regex sounds good, go ahead!
closes #2226
This is still a draft since some details regarding GitHub helpers need haven't been discussed thoroughly.
The idea is to fetch active nominations that are more than 2 weeks old, and create admin issues for them in Github so that staff will do the follow up.
As soon as a vote is tracked, we add a "๐ฉ" reaction (which will probably change) to it to make sure we don't create duplicate issues for it.
GitHub Actions run 3451698043 was cancelled.
@ChrisLovering Here's a draft PR for #2226.
The only missing part is the Github issue part since i'm not quite aware of the repo/project structure for admins.
I suppose it needs to be configured from out config.yml file ?
GitHub Actions run 3451701812 succeeded.
I was referring to the case where we can't tell if the ID is correct or not. For cases where it's not an integer or is negative the API user has clearly done something wrong so I think it makes sense to return an error response.
The issue is that with the current query we can't tell between users with no messages in that period and users that don't exist (but with the ID in the correct form). I think i'll change it so that does return 0 anyway though, as it's probably more useful.
We should also catch the error if the channel isn't found here. Also, we can't use the []() syntax for links as this isn't sent in an embed.
We should catch the error if the channel isn't found. Could write it something like this:
thread_jump_url = "*Not created*"
if nomination.thread_id:
try:
thread = await get_or_fetch_channel(nomination.thread_id)
except discord.HTTPException:
thread_jump_url = "*Not found*"
else:
thread_jump_url = f'[Jump to thread!]({thread.jump_url})'
or
...
I was referring to the case where we can't tell if the ID is correct or not. For cases where it's not an integer or is negative the API user has clearly done something wrong so I think it makes sense to return an error response.
The issue is that with the current query we can't tell between users with no messages in that period and users that don't exist (but with the ID in the correct form). I think i'll change it so that does return 0 anyway though, as it's probably more useful.
...
Fwiw, you can target one PR to another branch (i.e it would look something like main <- nomination history PR branch <- this PR branch).
What that would do is basically try applying the changes from the final branch (3) in this chain to the middle branch (2), so when you check out the 3rd branch, it would have all the changes from branch 2 as well, but the PR itself will only have the changes of branch 3.
For the admin repo, there's an issue template which Chris can probably fetch for...
Looks great! I have some suggestions, feel free to disagree with any of them :)
i'm not sure the capitalisation is necessary
[python.org Downloads page](https://www.python.org/downloads/) using the default options,
Maybe better to force them to read the full instructions, only stressing adding to path here? Pretty minor though, fine how it is
It might be worth mentioning that people may need to use microsoft store if they don't have permissions necessary for the official installer.
Thanks for this, the changes look good.
Side note: I didn't realise we have two tags for virtual environments, maybe we should combine them into one (not in this PR)
I think italics was fine here personally, is there a reason for this change?
Looks good to me, could you fix the merge conflict?
No response from author. Changing to up for grabs.
Redis could work, although it's not ideal to rely on it for persistence. It might be fine for this though, unless there's a nice way we can store it in the site database, not entirely sure how would be best to represent a queue in the database though.
No response from author. Changing to up for grabs.
I would be for sending a message somewhere and retrying. I also wouldn't mind not retrying, but I don't think it should add too much complexity to include it.
The linter error needs fixing
Personally I'm not really a fan of deleting bot responses after a timeout, it's confusing to look back over. The response is only a single line long so I don't think it's harmful.
GitHub Actions run 3452320030 succeeded.
a9cf7cf Update intents.md - thegamecracks
5095880 Add further clarification to intents.md - thegamecracks
330a063 Merge branch 'main' into intents-tag - thegamecracks
db00ac1 Merge pull request #2320 from thegamecracks/int... - wookie184
Consistency with other tags.
Connected!
GitHub Actions run 3452339312 succeeded.
GitHub Actions run 3452557324 succeeded.
@HassanAbouelela Thanks for the tip, I didn't know that was feasible.
I see that we already have a keys section in our config, and we have a GitHub key as well but I think we'll need a new one because of permission levels, so I'll add a new key for it.
As for the default behavior, I have just thought of a warning log and an early return when that value of that key is null.
GitHub Actions run 3452637926 succeeded.
Still this
Also, we can't use the
[]()syntax for links as this isn't sent in an embed.
I really don't mind NOT/Not/not any which way. (Though in general I was going for capitalized titles https://capitalizemytitle.com/ which most other guides follow, so "Not" works.)
Hmm, I see a python.exe in my C:\Users\<user>\AppData\Local\Microsoft\WindowsApps. When the store version is installed that exe runs python, and there's a pip.exe in there too, but when it's not installed it opens the store - aka it is the app execution alias. So I've been assuming it gets looked up on the path normally. If you toggle off the app execution alias that python.exe is removed.
So I think it's ok. I double checked and with `C:\Users<user>\AppData\Local\Microsoft\WindowsA...
I agree that's worth mentioning, I'll add a sentence about it.
I was able to install python.org Python on a new user on my PC without any admin requirements, but there could very well be other restrictions that are put on work/school computers or whatever.
I'd prefer to mention it. Lots of times I see tutorials that don't mention the software versions involved or date of writing and I have to guess if it'll work for my setup.
Mentioning Win 11 might help people from clicking away thinking "oh this must be a Win 10 guide since Win 11 is new".
(Though btw I have not explicitly tested the guides in Win 11 since I'm still on Win 10.)
I like this wording better too. Changing it.
GitHub Actions run 3453381030 succeeded.
GitHub Actions run 3453389032 succeeded.
GitHub Actions run 3453394466 succeeded.
Yeah, I only used "Path" (and usually "the Path") since in the actual environment variables that's the case it shows up as, though a few times I use "PATH" since the python installer calls it that.
I wish the env var was uppercase PATH since then it is more distict and matches how it's usually talked about online.
GitHub Actions run 3453397976 succeeded.
You can but, as I discovered, you'll still need the installer around to finally make the changes. This is mentioned in parentheses just before the "Verifying your changes" section.
I figured, since they need it anyway, better to just run the installer than look for python on Apps & features.
GitHub Actions run 3453423264 succeeded.
Eh, I like the little context of showing how old Python is.
I'll change it to "If instead...". (Though I definitely overuse though transition words in my writing style :P)
I think it's important to mention the "Manage app execution alias" setting somewhere - I didn't even know about it until writing the guides. (Though it is mentioned in /microsoft-store/#confusing-app-execution-alias-behaviour come to think of it.)
Whether to suggest it or not I have no opinion on. Though I believe it does work more or less like a normal path entry as explained here: https://github.com/python-discord/site/pull/794#discussion_r1020826357
I think I've seen the issue a few times in a help channel, though can't recall exactly what was imported.
I do feel it's useful to explain why dashes (such a common character to name files/folder/packages with) don't work the same in Python syntax - even in imports.
Good ideal. I'll make microsoft-store/#uninstalling a section and change this link.
GitHub Actions run 3453481543 succeeded.
GitHub Actions run 3453484669 succeeded.
GitHub Actions run 3453487754 succeeded.
I'll "hit" to "from". Just like to make it clear for those who often only read the first paragraph of a tutorial (i.e. often me).
GitHub Actions run 3453506505 succeeded.
One thing I wanted to be sure to resolve is whether or not the yellow downloads button on https://www.python.org/downloads/ really does download the best version the suits the computer, since I said it did in the "Recommended Installed" tutorial:
Go to python.org/downloads and click the big yellow "Download Python 3.x.x" button near the top of the page. That should start the download of the latest Windows Python installer that best suits your computer....
Description
After a member invokes the "topic" command, they have the ability to re-roll the embed to choose a different conversation prompt. When they do this, the previous contents of the message is overwritten. Instead, the content should be edited to include the new prompt with the old prompt(s) above it, with a number corresponding to the order it was created in.
Reasoning
When the person who invokes the command sees a topic they don't want to comment on, they tend to re-r...
GitHub Actions run 3453743105 succeeded.
GitHub Actions run 3453745471 succeeded.
Love it. I've only got 2 small requests for ya. Thanks!
We could advise users on how to install discord.py as they would normally, as it's now on PyPi
Emphasize this. A lot. I see too many times people asking "why can't I see my slash commands on Discord"? The answer, nine times out of ten, is that they forgot to sync.
[python-discord/site] New branch created: maskduck\-another\-random/main
[python-discord/site] branch deleted: maskduck\-another\-random/main
Unable to push to branch, re-creating in new PR.
0d59f04 Migrated from #discord-bot pin - Xithrius
[python-discord/site] New branch created: fix\-verification\-ssl
GitHub Actions run 3453803339 succeeded.
GitHub Actions run 3453847001 succeeded.
GitHub Actions run 3453875999 succeeded.
LGTM, but we might wanna recheck the links we're mentioning in a future PR
I just realized that the last link doesn't work D:
30e4799 Bump cryptography from 38.0.1 to 38.0.3 - dependabot[bot]
779ca88 Bump pymdown-extensions from 9.7 to 9.8 - dependabot[bot]
6406912 Merge pull request #795 from python-discord/dep... - jchristgit
80bce59 Merge branch 'main' into dependabot/pip/pymdown... - Xithrius
ec421e2 Merge pull request #793 from python-discord/dep... - jchristgit
[python-discord/site] branch deleted: fix\-verification\-ssl
This is already possible with the native discord UI, the command is not necessary for the creator.
Sorry for the amount of comments. Most of them are nit picks so it should be quite simple to do deal with.
However, there is one thing about the intents that I think should be addresses.
Thank you ! :D
Upon resumption of the most popular discord API wrapper library for python, `discord.py`, while catching on to the latest features of the discord API, there have been numerous changes with addition of features to the library. Some additions to the library are -> Buttons support, Select Menus Support, Forms (AKA Modals), Slash Commands (AKA Application Commands) and a bunch of more handy features! All the changes can be found [here](https://discordpy.readthedocs.io/en/latest/mig...
I suggest we change this to
As soon as you type "/", you can easily see all the commands a bot has. It also comes with autocomplete, validation and error, which will all help you get the command right the first time.
AH, I see what is going on. Discord.py usually deals with the response to the callback automatically, but since you're calling self.timeout() manually, that s stopping the interaction, so Discord.y does not respond to Discord to say the interaction was handled.
I think what we want to do here is
await interaction.message.edit(view=None)
self.stop()
At the end of both button callbacks You could even edit the embed at the same time for feedback to the person who interacted...
c3455e6 fixup: consistently name event payloads - ChrisLovering
[python-discord/bot] Checks Successful on PR: #2318 Update help channel system to use forum channels
GitHub Actions run 3455105530 succeeded.
Marked as do not merge as there are fixup commits I'd like to squash before this is merged.
[python-discord/bot] Checks Successful on PR: #2318 Update help channel system to use forum channels
GitHub Actions run 3455112125 succeeded.
GitHub Actions run 3455260347 was cancelled.
GitHub Actions run 3455261350 succeeded.
GitHub Actions run 3455297690 succeeded.
[python-discord/bot] Checks Successful on PR: #2318 Update help channel system to use forum channels
GitHub Actions run 3455382052 succeeded.
[python-discord/bot] Checks Successful on PR: #2318 Update help channel system to use forum channels
GitHub Actions run 3455517818 succeeded.
[python-discord/bot-core] New branch created: d\.py\-2\.1
This also bumps some dev-deps to latest
Major version is just to drop python 2 support
Major version deprecates and removes some options that we don't use.
Major version drops support for multiprocessing
Connected!
5ef42cd Make snekbox 3.11 stable default, with 3.10 option - ChrisLovering
[python-discord/bot] New branch created: snekbox\-3\.11\-default
e0b97fb Make snekbox 3.11 stable default, with 3.10 option - ChrisLovering
GitHub Actions run 3455724739 succeeded.
[python-discord/bot] Checks Successful on PR: #2318 Update help channel system to use forum channels
GitHub Actions run 3455772550 succeeded.
Ah yeah I should have clarified I only meant the all caps "NOT". "Not" is good.
Interesting, I get a bunch of things but not python.exe so assumed it's just because that was left to the alias:

does it depend on the version?
Fair, fwiw i'm on windows 11 and everything seems to be the same.
oh sorry I misread what you wrote, I understand now
I see, I didn't realise it was a normal path entry.
I also just realised that if you install python from the ms store it adds the other entries (pip, etc) as app execution aliases (there are loads...)



