+ For end-users, the most important parts of the software are functionality and UI/UX.
+ But for developers, there is one more important aspect - code style.
+ While ugly code can do everything that it has to do, developing it further may be a difficult task,
+ especially if a developer didn't write an original code.
+ Which one of the following do you prefer to read and work with?
+
+
+
+ MyPath = '/file.txt'
+ from pathlib import *
+ import os.path,sys
+ def check(p):
+ """Uses os.path.exist """
+ return os.path.exists(p)
+
+ def getF(
+ p):
+ """Not sure what this do, this just worked.
+ """
+ return Path(p
+ )
+ result=[check(MyPath),getF(MyPath)]
+
+
+
or
+
+
+ import os.path
+ from pathlib import Path
+
+ FILE_PATH = '/file.txt'
+
+
+ def check_file_exists(path: str) -> bool:
+ """Checks does file exists in path. Uses os.path.exists."""
+ return os.path.exists(path)
+
+
+ def get_path_object(path: str) -> Path:
+ """
+ Returns Path object of the path provided in arguments.
+
+ This is here for backward compatibility, will be removed in the future.
+ """
+ return Path(path)
+
+ result = [
+ check_file_exists(FILE_PATH),
+ get_path_object(FILE_PATH),
+ ]
+
+
+
+
+ The second is definitely easier to read and understand.
+ These scripts are small and if you read even first, you can understand what this code does pretty fast,
+ but what if the project has thousands and thousands of files in a really complex folder structure?
+ Do you want then code what looks like the first example?
+ You can save hours sometimes if you write beautiful code that follows style rules.
+
+
+ The most important document of Python code style is PEP 8.
+ This gives the majority of all Python code style rules. This article will cover the most important rules of PEP 8.
+
+
+
Linters
+
+ But everyone makes mistakes and there are so many style rules that can be really difficult to remember and always follow.
+ Luckily, we have amazing tools that help us - linters. While there are many linters,
+ we'd like code jam participants to use flake8.
+ Flake8 points out to you rules what you did break in your code so you can fix them.
+
+
+
Rules
+
Basics
+
For indentation, you should use 4 spaces. Using tabs is not suggested, but if you do, you can't mix spaces and tabs.
+
+ PEP 8 defines a maximum line length of 79 characters, however,
+ we are not so strict - we let teams choose a maximum line length between 79 and 119 characters.
+
+
2 blank lines should be left before functions and classes. Single blank lines are used to split sections and make logical breaks.
+
+
Naming
+
Module, file, function, and variable names (except type variables) should be lowercase and use underscores.
Class and type variable names should use the camel case style.
+
+
+ from typing import List
+
+
+ class MyClass:
+ pass
+
+ ListOfMyClass = List[MyClass]
+
+
+
Constant names should be all uppercase, and words should be separated with underscores.
+
+
+ MY_CONSTANT = 1
+
+
+
+ You should avoid single-character names, as these might be confusing.
+ But if you still do, you should avoid characters that may look like zero or one in some fonts:
+ "O" (uppercase o), "l" (lowercase L), and "I" (uppercase i).
+
+
+
Operators
+
+ If you have a chain of mathematic operations that you split into multiple lines,
+ you should put the operator at the beginning of the line and not to the end of the line.
+
If you compare against None, you should use is and is not, but not compare equality.
+
+
+ # No
+ if variable == None:
+ print("Variable is None")
+
+ # Yes
+ if variable is None:
+ print("Variable is None")
+
+
+
+ You should prefer using is not over not is .
+ Using second makes it harder to understand the expression.
+
+
+
+ # No
+ if not variable is None:
+ print("Variable is not None")
+
+ # Yes - it is much easier to read and understand this than previous
+ if variable is not None:
+ print("Variable is not None")
+
+
+
+
Imports
+
Imports should be at top of the file, the only things that should be before them are module comments and docstrings.
+
You shouldn't import multiple modules in one line, but give each module import its own line instead.
+
+
+ # No
+ import pathlib, os
+
+ # Yes
+ import os
+ import pathlib
+
+
+
Wildcard imports should be avoided in most cases. They make unclear where what comes from.
+
+
+ # No
+ from pathlib import *
+
+ # Yes
+ from pathlib import Path
+
+
+
You should use isort imports order specification, what means:
+
+
+ Group by type: order of import types should be __future__ imports, standard library imports,
+ third-party library imports, and finally project imports.
+
+
+ Group by import way: inside each group, first should come imports in format import <package>
+ and after them from <package> import <items>.
+
+
+ Order imports alphabetically: inside each import way group, imports should be ordered by package names.
+
+
+ Order individual import items by type and alphabetically: in from <package> import <items> format,
+ <items> should be ordered alphabetically, starting with bare module imports.
+
+
+
+
Comments
+
+ Comments are really important because they help everyone understand, what code does.
+ But as important as having comments is keeping them up-to-date.
+ Out-to-date, wrong comments confuse readers.
+
+
Comments content should start with a capital letter and be a full sentence(s).
+
There are three types of comments:
+
+
+ Block comments: Probably most common comment type. Should be indented to the same level as the code they describe.
+ Each line in the block comment has to start with # what should be followed by a single space,
+ except for text indention inside the comment. To separate paragraphs, use one line containing only #.
+
+
+ if variable is None or variable == 1:
+ # If variable is None, something went wrong previously.
+ #
+ # Here starts a new important paragraph.
+
+
+
+
+ Inline comments: You should prefer block comments over inline comments and use inline comments only where it is really necessary.
+ Never use inline comments to explain obvious things what line do. If you want to use an inline comment on a variable, think first,
+ maybe you can use a better variable name instead. After code and before the start of inline comments should be at least two spaces.
+ Just like block comments, inline comments also have to start with # what should be followed by a single space.
+
+
+ # Do not use inline comments to explain things
+ # that the reader can understand even without the inline comment.
+ my_variable = "Value!" # Assign value to my_variable
+
+ # Here better variable name can be used like shown in the second line.
+ x = "Walmart" # Shop name
+ shop_name = "Walmart"
+
+ # Sometimes, if something is not obvious, then inline comments are useful.
+ # Example is from PEP 8.
+ x = x + 1 # Compensate for border
+
+
+
+
+ Docstrings: Last, but not least important comment type is docstring, which is a short version of documentation string.
+ Docstring rules haven't been defined by PEP 8, but by PEP 257 instead.
+ Docstrings should start and end with three quotes ("""). There are two types of docstrings: one-line docstrings and multiline docstrings.
+ One-line docstrings have to start and end in the same line, while multiline docstrings start and end in different lines.
+ Multiline docstring has two parts: summary line and a longer description, which are separated by one empty line.
+ The multiline sentence starting and ending quotes should be at different lines than the content.
+
+
+ # This is a one-line docstring.
+ """This is one line module docstring."""
+
+
+ # This is a multiline docstring.
+ def my_function():
+ """
+ This is the summary line.
+
+ This is the description.
+ """
+
+
+
+
+
+
Too much for you?
+
+ Is all this PEP 8 rules stuff making your head exploding? We have something for you! We have a song!
+ We have The PEP 8 Song (featuring lemonsaurus)!
+ Great way to get started with writing beautiful code.
+
--
cgit v1.2.3
From fac0a2bce2f8c06111f68446ad7df7f3003d3383 Mon Sep 17 00:00:00 2001
From: ks129 <45097959+ks129@users.noreply.github.com>
Date: Thu, 8 Jul 2021 20:18:56 +0300
Subject: Add The Code Style Guide to CJ 8 sidebar
---
pydis_site/templates/events/sidebar/code-jams/8.html | 1 +
1 file changed, 1 insertion(+)
(limited to 'pydis_site')
diff --git a/pydis_site/templates/events/sidebar/code-jams/8.html b/pydis_site/templates/events/sidebar/code-jams/8.html
index ff5131c2..e68c913d 100644
--- a/pydis_site/templates/events/sidebar/code-jams/8.html
+++ b/pydis_site/templates/events/sidebar/code-jams/8.html
@@ -4,6 +4,7 @@
RulesApproved FrameworksGitHub Bootcamp
+ The Code Style Guide
--
cgit v1.2.3
From 25a50578cd7f77dd468bcee2cfd398aa42da972d Mon Sep 17 00:00:00 2001
From: ks129 <45097959+ks129@users.noreply.github.com>
Date: Thu, 8 Jul 2021 20:33:10 +0300
Subject: Remove trailing whitespace from The Code Style Guide
---
pydis_site/templates/events/pages/code-jams/the-code-style-guide.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
(limited to 'pydis_site')
diff --git a/pydis_site/templates/events/pages/code-jams/the-code-style-guide.html b/pydis_site/templates/events/pages/code-jams/the-code-style-guide.html
index 33b36d99..3176babf 100644
--- a/pydis_site/templates/events/pages/code-jams/the-code-style-guide.html
+++ b/pydis_site/templates/events/pages/code-jams/the-code-style-guide.html
@@ -175,7 +175,7 @@
print("Variable is not None")
-
+
Imports
Imports should be at top of the file, the only things that should be before them are module comments and docstrings.
You shouldn't import multiple modules in one line, but give each module import its own line instead.
--
cgit v1.2.3
From 23b1e46342e743cdb1ec8e0bb30e4696a3018079 Mon Sep 17 00:00:00 2001
From: ks129 <45097959+ks129@users.noreply.github.com>
Date: Fri, 9 Jul 2021 00:00:15 +0300
Subject: Add missing slash at b tag ending
Co-authored-by: Numerlor <25886452+Numerlor@users.noreply.github.com>
---
pydis_site/templates/events/pages/code-jams/the-code-style-guide.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
(limited to 'pydis_site')
diff --git a/pydis_site/templates/events/pages/code-jams/the-code-style-guide.html b/pydis_site/templates/events/pages/code-jams/the-code-style-guide.html
index 3176babf..eb8ab9da 100644
--- a/pydis_site/templates/events/pages/code-jams/the-code-style-guide.html
+++ b/pydis_site/templates/events/pages/code-jams/the-code-style-guide.html
@@ -199,7 +199,7 @@
from pathlib import Path
-
You should use isort imports order specification, what means:
+
You should use isort imports order specification, what means:
Group by type: order of import types should be __future__ imports, standard library imports,
--
cgit v1.2.3
From 1ff45d2831eff3a48bd7718bb95b9e73d513713e Mon Sep 17 00:00:00 2001
From: ks129 <45097959+ks129@users.noreply.github.com>
Date: Fri, 9 Jul 2021 00:03:04 +0300
Subject: Use better wording for head explosion question
---
pydis_site/templates/events/pages/code-jams/the-code-style-guide.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
(limited to 'pydis_site')
diff --git a/pydis_site/templates/events/pages/code-jams/the-code-style-guide.html b/pydis_site/templates/events/pages/code-jams/the-code-style-guide.html
index eb8ab9da..be022ffc 100644
--- a/pydis_site/templates/events/pages/code-jams/the-code-style-guide.html
+++ b/pydis_site/templates/events/pages/code-jams/the-code-style-guide.html
@@ -288,7 +288,7 @@
Too much for you?
- Is all this PEP 8 rules stuff making your head exploding? We have something for you! We have a song!
+ Do all these style rules make your head explode? We have something for you! We have a song!
We have The PEP 8 Song (featuring lemonsaurus)!
Great way to get started with writing beautiful code.
- Comments are really important because they help everyone understand, what code does.
+ Comments are really important because they help everyone understand what code does.
But as important as having comments is keeping them up-to-date.
Out-to-date, wrong comments confuse readers.
- Group by import way: inside each group, first should come imports in format import <package>
+ Group by import method: inside each group, first should come imports in format import <package>
and after them from <package> import <items>.
- Order imports alphabetically: inside each import way group, imports should be ordered by package names.
+ Order imports alphabetically: inside each import method group, imports should be ordered by package names.
Order individual import items by type and alphabetically: in from <package> import <items> format,
--
cgit v1.2.3
From 761aa067d19f669e56c32dc4c24b8242cd23a668 Mon Sep 17 00:00:00 2001
From: ks129 <45097959+ks129@users.noreply.github.com>
Date: Fri, 9 Jul 2021 00:09:32 +0300
Subject: Add missing colon
Co-authored-by: Numerlor <25886452+Numerlor@users.noreply.github.com>
---
pydis_site/templates/events/pages/code-jams/the-code-style-guide.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
(limited to 'pydis_site')
diff --git a/pydis_site/templates/events/pages/code-jams/the-code-style-guide.html b/pydis_site/templates/events/pages/code-jams/the-code-style-guide.html
index fabf5444..5e4a957e 100644
--- a/pydis_site/templates/events/pages/code-jams/the-code-style-guide.html
+++ b/pydis_site/templates/events/pages/code-jams/the-code-style-guide.html
@@ -202,7 +202,7 @@
You should use isort imports order specification, what means:
- Group by type: order of import types should be __future__ imports, standard library imports,
+ Group by type: order of import types should be: __future__ imports, standard library imports,
third-party library imports, and finally project imports.
Inline comments: You should prefer block comments over inline comments and use inline comments only where it is really necessary.
- Never use inline comments to explain obvious things what line do. If you want to use an inline comment on a variable, think first,
+ Never use inline comments to explain obvious things like what a line does. If you want to use an inline comment on a variable, think first,
maybe you can use a better variable name instead. After code and before the start of inline comments should be at least two spaces.
- Just like block comments, inline comments also have to start with # what should be followed by a single space.
+ Just like block comments, inline comments also have to start with # followed by a single space.
# Do not use inline comments to explain things
@@ -267,7 +267,7 @@
Docstrings should start and end with three quotes ("""). There are two types of docstrings: one-line docstrings and multiline docstrings.
One-line docstrings have to start and end in the same line, while multiline docstrings start and end in different lines.
Multiline docstring has two parts: summary line and a longer description, which are separated by one empty line.
- The multiline sentence starting and ending quotes should be at different lines than the content.
+ The multiline sentence start and end quotes should be at different lines than the content.
# This is a one-line docstring.
--
cgit v1.2.3
From bdc492f79880b3ebb7be6e15020142e44c8dbdd6 Mon Sep 17 00:00:00 2001
From: ks129 <45097959+ks129@users.noreply.github.com>
Date: Fri, 9 Jul 2021 00:12:35 +0300
Subject: Escape HTML in The Code Style Guide
---
pydis_site/templates/events/pages/code-jams/the-code-style-guide.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
(limited to 'pydis_site')
diff --git a/pydis_site/templates/events/pages/code-jams/the-code-style-guide.html b/pydis_site/templates/events/pages/code-jams/the-code-style-guide.html
index a26a973c..4258cd94 100644
--- a/pydis_site/templates/events/pages/code-jams/the-code-style-guide.html
+++ b/pydis_site/templates/events/pages/code-jams/the-code-style-guide.html
@@ -161,7 +161,7 @@
- You should prefer using is not over not is .
+ You should prefer using <item one> is not <item two> over not <item one> is <item two>.
Using second makes it harder to understand the expression.
--
cgit v1.2.3
From dea0924f8160c5452e0c52657aeaacc488b606e2 Mon Sep 17 00:00:00 2001
From: ks129 <45097959+ks129@users.noreply.github.com>
Date: Fri, 9 Jul 2021 00:26:58 +0300
Subject: Remove leading spaces and unnecessary newlines from code blocks
HTML
tag is adding indention also to result, so I had to remove these.
---
.../pages/code-jams/the-code-style-guide.html | 252 ++++++++-------------
1 file changed, 100 insertions(+), 152 deletions(-)
(limited to 'pydis_site')
diff --git a/pydis_site/templates/events/pages/code-jams/the-code-style-guide.html b/pydis_site/templates/events/pages/code-jams/the-code-style-guide.html
index 4258cd94..d3359ebb 100644
--- a/pydis_site/templates/events/pages/code-jams/the-code-style-guide.html
+++ b/pydis_site/templates/events/pages/code-jams/the-code-style-guide.html
@@ -16,52 +16,44 @@
especially if a developer didn't write an original code.
Which one of the following do you prefer to read and work with?
-
-
- MyPath = '/file.txt'
- from pathlib import *
- import os.path,sys
- def check(p):
- """Uses os.path.exist """
- return os.path.exists(p)
-
- def getF(
- p):
- """Not sure what this do, this just worked.
- """
- return Path(p
- )
- result=[check(MyPath),getF(MyPath)]
-
-
+
MyPath = '/file.txt'
+from pathlib import *
+import os.path,sys
+def check(p):
+ """Uses os.path.exist """
+ return os.path.exists(p)
+
+def getF(
+ p):
+ """Not sure what this do, this just worked.
+ """
+ return Path(p
+ )
+result=[check(MyPath),getF(MyPath)]
or
-
-
- import os.path
- from pathlib import Path
+
import os.path
+from pathlib import Path
- FILE_PATH = '/file.txt'
+FILE_PATH = '/file.txt'
- def check_file_exists(path: str) -> bool:
- """Checks does file exists in path. Uses os.path.exists."""
- return os.path.exists(path)
+def check_file_exists(path: str) -> bool:
+ """Checks does file exists in path. Uses os.path.exists."""
+ return os.path.exists(path)
- def get_path_object(path: str) -> Path:
- """
- Returns Path object of the path provided in arguments.
+def get_path_object(path: str) -> Path:
+ """
+ Returns Path object of the path provided in arguments.
- This is here for backward compatibility, will be removed in the future.
- """
- return Path(path)
+ This is here for backward compatibility, will be removed in the future.
+ """
+ return Path(path)
- result = [
- check_file_exists(FILE_PATH),
- get_path_object(FILE_PATH),
- ]
-
-
Class and type variable names should use the camel case style.
-
-
- from typing import List
+
from typing import List
- class MyClass:
- pass
+class MyClass:
+ pass
- ListOfMyClass = List[MyClass]
-
-
+ListOfMyClass = List[MyClass]
Constant names should be all uppercase, and words should be separated with underscores.
-
-
- MY_CONSTANT = 1
-
-
+
MY_CONSTANT = 1
You should avoid single-character names, as these might be confusing.
But if you still do, you should avoid characters that may look like zero or one in some fonts:
@@ -131,74 +111,54 @@
If you have a chain of mathematic operations that you split into multiple lines,
you should put the operator at the beginning of the line and not to the end of the line.
If you compare against None, you should use is and is not, but not compare equality.
-
-
- # No
- if variable == None:
- print("Variable is None")
-
- # Yes
- if variable is None:
- print("Variable is None")
-
-
+
# No
+if variable == None:
+ print("Variable is None")
+
+# Yes
+if variable is None:
+ print("Variable is None")
You should prefer using <item one> is not <item two> over not <item one> is <item two>.
Using second makes it harder to understand the expression.
-
-
- # No
- if not variable is None:
- print("Variable is not None")
-
- # Yes - it is much easier to read and understand this than previous
- if variable is not None:
- print("Variable is not None")
-
-
+
# No
+if not variable is None:
+ print("Variable is not None")
+
+# Yes - it is much easier to read and understand this than previous
+if variable is not None:
+ print("Variable is not None")
Imports
Imports should be at top of the file, the only things that should be before them are module comments and docstrings.
You shouldn't import multiple modules in one line, but give each module import its own line instead.
-
-
- # No
- import pathlib, os
-
- # Yes
- import os
- import pathlib
-
-
+
# No
+import pathlib, os
+
+# Yes
+import os
+import pathlib
Wildcard imports should be avoided in most cases. They make unclear where what comes from.
-
-
- # No
- from pathlib import *
-
- # Yes
- from pathlib import Path
-
-
You should use isort imports order specification, what means:
@@ -231,35 +191,27 @@
Block comments: Probably most common comment type. Should be indented to the same level as the code they describe.
Each line in the block comment has to start with # what should be followed by a single space,
except for text indention inside the comment. To separate paragraphs, use one line containing only #.
-
-
- if variable is None or variable == 1:
- # If variable is None, something went wrong previously.
- #
- # Here starts a new important paragraph.
-
-
+
if variable is None or variable == 1:
+ # If variable is None, something went wrong previously.
+ #
+ # Here starts a new important paragraph.
Inline comments: You should prefer block comments over inline comments and use inline comments only where it is really necessary.
Never use inline comments to explain obvious things like what a line does. If you want to use an inline comment on a variable, think first,
maybe you can use a better variable name instead. After code and before the start of inline comments should be at least two spaces.
Just like block comments, inline comments also have to start with # followed by a single space.
-
-
- # Do not use inline comments to explain things
- # that the reader can understand even without the inline comment.
- my_variable = "Value!" # Assign value to my_variable
-
- # Here better variable name can be used like shown in the second line.
- x = "Walmart" # Shop name
- shop_name = "Walmart"
-
- # Sometimes, if something is not obvious, then inline comments are useful.
- # Example is from PEP 8.
- x = x + 1 # Compensate for border
-
-
+
# Do not use inline comments to explain things
+# that the reader can understand even without the inline comment.
+my_variable = "Value!" # Assign value to my_variable
+
+# Here better variable name can be used like shown in the second line.
+x = "Walmart" # Shop name
+shop_name = "Walmart"
+
+# Sometimes, if something is not obvious, then inline comments are useful.
+# Example is from PEP 8.
+x = x + 1 # Compensate for border
Docstrings: Last, but not least important comment type is docstring, which is a short version of documentation string.
@@ -268,21 +220,17 @@
One-line docstrings have to start and end in the same line, while multiline docstrings start and end in different lines.
Multiline docstring has two parts: summary line and a longer description, which are separated by one empty line.
The multiline sentence start and end quotes should be at different lines than the content.
-
-
- # This is a one-line docstring.
- """This is one line module docstring."""
+
# This is a one-line docstring.
+"""This is one line module docstring."""
- # This is a multiline docstring.
- def my_function():
- """
- This is the summary line.
+# This is a multiline docstring.
+def my_function():
+ """
+ This is the summary line.
- This is the description.
- """
-
-
- Inline comments: You should prefer block comments over inline comments and use inline comments only where it is really necessary.
- Never use inline comments to explain obvious things like what a line does. If you want to use an inline comment on a variable, think first,
- maybe you can use a better variable name instead. After code and before the start of inline comments should be at least two spaces.
- Just like block comments, inline comments also have to start with # followed by a single space.
+
+ Inline comments: You should prefer block comments over inline comments and use inline comments only where it is really necessary.
+ Never use inline comments to explain obvious things like what a line does.
+
+
If you want to use an inline comment on a variable, think first, maybe you can use a better variable name instead.
+
+ After code and before the start of inline comments should be at least two spaces.
+ Just like block comments, inline comments also have to start with # followed by a single space.
+
# Do not use inline comments to explain things
# that the reader can understand even without the inline comment.
my_variable = "Value!" # Assign value to my_variable
@@ -214,12 +219,17 @@ shop_name = "Walmart"
x = x + 1 # Compensate for border
- Docstrings: Last, but not least important comment type is docstring, which is a short version of documentation string.
- Docstring rules haven't been defined by PEP 8, but by PEP 257 instead.
- Docstrings should start and end with three quotes ("""). There are two types of docstrings: one-line docstrings and multiline docstrings.
- One-line docstrings have to start and end in the same line, while multiline docstrings start and end in different lines.
- Multiline docstring has two parts: summary line and a longer description, which are separated by one empty line.
- The multiline sentence start and end quotes should be at different lines than the content.
+
+ Docstrings: Last, but not least important comment type is docstring, which is a short version of documentation string.
+ Docstring rules haven't been defined by PEP 8, but by PEP 257 instead.
+ Docstrings should start and end with three quotes (""").
+
+
There are two types of docstrings: one-line docstrings and multiline docstrings.
+
+ One-line docstrings have to start and end in the same line, while multiline docstrings start and end in different lines.
+ Multiline docstring has two parts: summary line and a longer description, which are separated by one empty line.
+ The multiline docstring start and end quotes should be at different lines than the content.
+
# This is a one-line docstring.
"""This is one line module docstring."""
--
cgit v1.2.3
From 944343cddc573d757784027463242298511ebf6a Mon Sep 17 00:00:00 2001
From: Janine vN
Date: Thu, 8 Jul 2021 18:57:13 -0400
Subject: Update dates & times for code jam The dates and times on the main
event page have been updated to reflect the changes.
---
pydis_site/templates/events/pages/code-jams/8/_index.html | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
(limited to 'pydis_site')
diff --git a/pydis_site/templates/events/pages/code-jams/8/_index.html b/pydis_site/templates/events/pages/code-jams/8/_index.html
index c510c250..34171969 100644
--- a/pydis_site/templates/events/pages/code-jams/8/_index.html
+++ b/pydis_site/templates/events/pages/code-jams/8/_index.html
@@ -12,12 +12,12 @@
{% block event_content %}
Twice a year we host a code jam for members of our server to participate in. The code jam is an event where we place you
- in a team with 5 other random server members. You then have 7 days to code some sort of application or program in Python.
+ in a team with 5 other random server members. You then have 8 days to code some sort of application or program in Python.
Your program must use the specified technology/framework and incorporate the theme chosen by the server.
- After the 7 days is complete, your team has 2 days to finish documentation and create a video presentation showcasing
- and walking through the program that your team has created. More details and specifics of this will be released within the next 2 weeks.
+ After the 8 days is complete, your team has 3 days to finish documentation and create a video presentation showcasing
+ and walking through the program that your team has created.
--
cgit v1.2.3
From 451b04fb57573364c525bdaee18d380faee832a5 Mon Sep 17 00:00:00 2001
From: Janine vN
Date: Thu, 8 Jul 2021 19:06:05 -0400
Subject: Add textual to conditionally approved list
Adds Textual, the TUI framework that uses Rich as its renderer to as an
allowed library. It's still under active development though and is not
stable.
---
pydis_site/templates/events/pages/code-jams/8/frameworks.html | 5 +++++
1 file changed, 5 insertions(+)
(limited to 'pydis_site')
diff --git a/pydis_site/templates/events/pages/code-jams/8/frameworks.html b/pydis_site/templates/events/pages/code-jams/8/frameworks.html
index 532fb71f..34ac4f0a 100644
--- a/pydis_site/templates/events/pages/code-jams/8/frameworks.html
+++ b/pydis_site/templates/events/pages/code-jams/8/frameworks.html
@@ -73,6 +73,11 @@
Supports: Linux, Mac, and Windows
Documentation is good and overall is very OOP focused
Robust with many features and example snippets
+
To supplement Rich the following library is approved, although no guarantees are made for stability.
+
+
Textual - a TUI framework using Rich as the render.
+ It is still under active development, is only available on Mac/Linux, and is not stable yet.
+ For end-users, the most important parts of the software are functionality and UI/UX.
+ But for developers, there is one more important aspect - code style.
+ While ugly code can do everything that it has to do, developing it further may be a difficult task,
+ especially if a developer didn't write an original code.
+ Which one of the following do you prefer to read and work with?
+
+
MyPath = '/file.txt'
+from pathlib import *
+import os.path,sys
+def check(p):
+ """Uses os.path.exist """
+ return os.path.exists(p)
+
+def getF(
+ p):
+ """Not sure what this do, this just worked.
+ """
+ return Path(p
+ )
+result=[check(MyPath),getF(MyPath)]
+
or
+
import os.path
+from pathlib import Path
+
+FILE_PATH = '/file.txt'
+
+
+def check_file_exists(path: str) -> bool:
+ """Checks does file exists in path. Uses os.path.exists."""
+ return os.path.exists(path)
+
+
+def get_path_object(path: str) -> Path:
+ """
+ Returns Path object of the path provided in arguments.
+
+ This is here for backward compatibility, will be removed in the future.
+ """
+ return Path(path)
+
+result = [
+ check_file_exists(FILE_PATH),
+ get_path_object(FILE_PATH),
+]
+
+
+ The second is definitely easier to read and understand.
+ These scripts are small and if you read even first, you can understand what this code does pretty fast,
+ but what if the project has thousands and thousands of files in a really complex folder structure?
+ Do you want then code what looks like the first example?
+ You can save hours sometimes if you write beautiful code that follows style rules.
+
+
+ The most important document of Python code style is PEP 8.
+ This gives the majority of all Python code style rules. This article will cover the most important rules of PEP 8.
+
+
+
Linters
+
+ But everyone makes mistakes and there are so many style rules that can be really difficult to remember and always follow.
+ Luckily, we have amazing tools that help us - linters. While there are many linters,
+ we'd like code jam participants to use flake8.
+ Flake8 points out to you rules what you did break in your code so you can fix them.
+
+
+
Rules
+
Basics
+
For indentation, you should use 4 spaces. Using tabs is not suggested, but if you do, you can't mix spaces and tabs.
+
+ PEP 8 defines a maximum line length of 79 characters, however,
+ we are not so strict - we let teams choose a maximum line length between 79 and 119 characters.
+
+
2 blank lines should be left before functions and classes. Single blank lines are used to split sections and make logical breaks.
+
+
Naming
+
Module, file, function, and variable names (except type variables) should be lowercase and use underscores.
Class and type variable names should use the camel case style.
+
from typing import List
+
+
+class MyClass:
+ pass
+
+ListOfMyClass = List[MyClass]
+
Constant names should be all uppercase, and words should be separated with underscores.
+
MY_CONSTANT = 1
+
+ You should avoid single-character names, as these might be confusing.
+ But if you still do, you should avoid characters that may look like zero or one in some fonts:
+ "O" (uppercase o), "l" (lowercase L), and "I" (uppercase i).
+
+
+
Operators
+
+ If you have a chain of mathematic operations that you split into multiple lines,
+ you should put the operator at the beginning of the line and not to the end of the line.
+
If you compare against None, you should use is and is not, but not compare equality.
+
# No
+if variable == None:
+ print("Variable is None")
+
+# Yes
+if variable is None:
+ print("Variable is None")
+
+ You should prefer using <item one> is not <item two> over not <item one> is <item two>.
+ Using second makes it harder to understand the expression.
+
+
# No
+if not variable is None:
+ print("Variable is not None")
+
+# Yes - it is much easier to read and understand this than previous
+if variable is not None:
+ print("Variable is not None")
+
+
Imports
+
Imports should be at top of the file, the only things that should be before them are module comments and docstrings.
+
You shouldn't import multiple modules in one line, but give each module import its own line instead.
+
# No
+import pathlib, os
+
+# Yes
+import os
+import pathlib
+
Wildcard imports should be avoided in most cases. They make unclear where what comes from.
You should use isort imports order specification, what means:
+
+
+ Group by type: order of import types should be: __future__ imports, standard library imports,
+ third-party library imports, and finally project imports.
+
+
+ Group by import method: inside each group, first should come imports in format import <package>
+ and after them from <package> import <items>.
+
+
+ Order imports alphabetically: inside each import method group, imports should be ordered by package names.
+
+
+ Order individual import items by type and alphabetically: in from <package> import <items> format,
+ <items> should be ordered alphabetically, starting with bare module imports.
+
+
+
+
Comments
+
+ Comments are really important because they help everyone understand what code does.
+ But as important as having comments is keeping them up-to-date.
+ Out-to-date, wrong comments confuse readers.
+
+
Comments content should start with a capital letter and be a full sentence(s).
+
There are three types of comments:
+
+
+ Block comments: Probably most common comment type. Should be indented to the same level as the code they describe.
+ Each line in the block comment has to start with # what should be followed by a single space,
+ except for text indention inside the comment. To separate paragraphs, use one line containing only #.
+
if variable is None or variable == 1:
+ # If variable is None, something went wrong previously.
+ #
+ # Here starts a new important paragraph.
+
+
+
+ Inline comments: You should prefer block comments over inline comments and use inline comments only where it is really necessary.
+ Never use inline comments to explain obvious things like what a line does.
+
+
If you want to use an inline comment on a variable, think first, maybe you can use a better variable name instead.
+
+ After code and before the start of inline comments should be at least two spaces.
+ Just like block comments, inline comments also have to start with # followed by a single space.
+
+
# Do not use inline comments to explain things
+# that the reader can understand even without the inline comment.
+my_variable = "Value!" # Assign value to my_variable
+
+# Here better variable name can be used like shown in the second line.
+x = "Walmart" # Shop name
+shop_name = "Walmart"
+
+# Sometimes, if something is not obvious, then inline comments are useful.
+# Example is from PEP 8.
+x = x + 1 # Compensate for border
+
+
+
+ Docstrings: Last, but not least important comment type is docstring, which is a short version of documentation string.
+ Docstring rules haven't been defined by PEP 8, but by PEP 257 instead.
+ Docstrings should start and end with three quotes (""").
+
+
There are two types of docstrings: one-line docstrings and multiline docstrings.
+
+ One-line docstrings have to start and end in the same line, while multiline docstrings start and end in different lines.
+ Multiline docstring has two parts: summary line and a longer description, which are separated by one empty line.
+ The multiline docstring start and end quotes should be at different lines than the content.
+
+
# This is a one-line docstring.
+"""This is one line module docstring."""
+
+
+# This is a multiline docstring.
+def my_function():
+ """
+ This is the summary line.
+
+ This is the description.
+ """
+
+
+
+
Too much for you?
+
+ Do all these style rules make your head explode? We have something for you! We have a song!
+ We have The PEP 8 Song (featuring lemonsaurus)!
+ Great way to get started with writing beautiful code.
+
- For end-users, the most important parts of the software are functionality and UI/UX.
- But for developers, there is one more important aspect - code style.
- While ugly code can do everything that it has to do, developing it further may be a difficult task,
- especially if a developer didn't write an original code.
- Which one of the following do you prefer to read and work with?
-
-
MyPath = '/file.txt'
-from pathlib import *
-import os.path,sys
-def check(p):
- """Uses os.path.exist """
- return os.path.exists(p)
-
-def getF(
- p):
- """Not sure what this do, this just worked.
- """
- return Path(p
- )
-result=[check(MyPath),getF(MyPath)]
-
or
-
import os.path
-from pathlib import Path
-
-FILE_PATH = '/file.txt'
-
-
-def check_file_exists(path: str) -> bool:
- """Checks does file exists in path. Uses os.path.exists."""
- return os.path.exists(path)
-
-
-def get_path_object(path: str) -> Path:
- """
- Returns Path object of the path provided in arguments.
-
- This is here for backward compatibility, will be removed in the future.
- """
- return Path(path)
-
-result = [
- check_file_exists(FILE_PATH),
- get_path_object(FILE_PATH),
-]
-
-
- The second is definitely easier to read and understand.
- These scripts are small and if you read even first, you can understand what this code does pretty fast,
- but what if the project has thousands and thousands of files in a really complex folder structure?
- Do you want then code what looks like the first example?
- You can save hours sometimes if you write beautiful code that follows style rules.
-
-
- The most important document of Python code style is PEP 8.
- This gives the majority of all Python code style rules. This article will cover the most important rules of PEP 8.
-
-
-
Linters
-
- But everyone makes mistakes and there are so many style rules that can be really difficult to remember and always follow.
- Luckily, we have amazing tools that help us - linters. While there are many linters,
- we'd like code jam participants to use flake8.
- Flake8 points out to you rules what you did break in your code so you can fix them.
-
-
-
Rules
-
Basics
-
For indentation, you should use 4 spaces. Using tabs is not suggested, but if you do, you can't mix spaces and tabs.
-
- PEP 8 defines a maximum line length of 79 characters, however,
- we are not so strict - we let teams choose a maximum line length between 79 and 119 characters.
-
-
2 blank lines should be left before functions and classes. Single blank lines are used to split sections and make logical breaks.
-
-
Naming
-
Module, file, function, and variable names (except type variables) should be lowercase and use underscores.
Class and type variable names should use the camel case style.
-
from typing import List
-
-
-class MyClass:
- pass
-
-ListOfMyClass = List[MyClass]
-
Constant names should be all uppercase, and words should be separated with underscores.
-
MY_CONSTANT = 1
-
- You should avoid single-character names, as these might be confusing.
- But if you still do, you should avoid characters that may look like zero or one in some fonts:
- "O" (uppercase o), "l" (lowercase L), and "I" (uppercase i).
-
-
-
Operators
-
- If you have a chain of mathematic operations that you split into multiple lines,
- you should put the operator at the beginning of the line and not to the end of the line.
-
If you compare against None, you should use is and is not, but not compare equality.
-
# No
-if variable == None:
- print("Variable is None")
-
-# Yes
-if variable is None:
- print("Variable is None")
-
- You should prefer using <item one> is not <item two> over not <item one> is <item two>.
- Using second makes it harder to understand the expression.
-
-
# No
-if not variable is None:
- print("Variable is not None")
-
-# Yes - it is much easier to read and understand this than previous
-if variable is not None:
- print("Variable is not None")
-
-
Imports
-
Imports should be at top of the file, the only things that should be before them are module comments and docstrings.
-
You shouldn't import multiple modules in one line, but give each module import its own line instead.
-
# No
-import pathlib, os
-
-# Yes
-import os
-import pathlib
-
Wildcard imports should be avoided in most cases. They make unclear where what comes from.
You should use isort imports order specification, what means:
-
-
- Group by type: order of import types should be: __future__ imports, standard library imports,
- third-party library imports, and finally project imports.
-
-
- Group by import method: inside each group, first should come imports in format import <package>
- and after them from <package> import <items>.
-
-
- Order imports alphabetically: inside each import method group, imports should be ordered by package names.
-
-
- Order individual import items by type and alphabetically: in from <package> import <items> format,
- <items> should be ordered alphabetically, starting with bare module imports.
-
-
-
-
Comments
-
- Comments are really important because they help everyone understand what code does.
- But as important as having comments is keeping them up-to-date.
- Out-to-date, wrong comments confuse readers.
-
-
Comments content should start with a capital letter and be a full sentence(s).
-
There are three types of comments:
-
-
- Block comments: Probably most common comment type. Should be indented to the same level as the code they describe.
- Each line in the block comment has to start with # what should be followed by a single space,
- except for text indention inside the comment. To separate paragraphs, use one line containing only #.
-
if variable is None or variable == 1:
- # If variable is None, something went wrong previously.
- #
- # Here starts a new important paragraph.
-
-
-
- Inline comments: You should prefer block comments over inline comments and use inline comments only where it is really necessary.
- Never use inline comments to explain obvious things like what a line does.
-
-
If you want to use an inline comment on a variable, think first, maybe you can use a better variable name instead.
-
- After code and before the start of inline comments should be at least two spaces.
- Just like block comments, inline comments also have to start with # followed by a single space.
-
-
# Do not use inline comments to explain things
-# that the reader can understand even without the inline comment.
-my_variable = "Value!" # Assign value to my_variable
-
-# Here better variable name can be used like shown in the second line.
-x = "Walmart" # Shop name
-shop_name = "Walmart"
-
-# Sometimes, if something is not obvious, then inline comments are useful.
-# Example is from PEP 8.
-x = x + 1 # Compensate for border
-
-
-
- Docstrings: Last, but not least important comment type is docstring, which is a short version of documentation string.
- Docstring rules haven't been defined by PEP 8, but by PEP 257 instead.
- Docstrings should start and end with three quotes (""").
-
-
There are two types of docstrings: one-line docstrings and multiline docstrings.
-
- One-line docstrings have to start and end in the same line, while multiline docstrings start and end in different lines.
- Multiline docstring has two parts: summary line and a longer description, which are separated by one empty line.
- The multiline docstring start and end quotes should be at different lines than the content.
-
-
# This is a one-line docstring.
-"""This is one line module docstring."""
-
-
-# This is a multiline docstring.
-def my_function():
- """
- This is the summary line.
-
- This is the description.
- """
-
-
-
-
Too much for you?
-
- Do all these style rules make your head explode? We have something for you! We have a song!
- We have The PEP 8 Song (featuring lemonsaurus)!
- Great way to get started with writing beautiful code.
-
- Block comments: Probably most common comment type. Should be indented to the same level as the code they describe.
- Each line in the block comment has to start with # what should be followed by a single space,
- except for text indention inside the comment. To separate paragraphs, use one line containing only #.
+
Block comments
+
+ Probably most common comment type. Should be indented to the same level as the code they describe.
+ Each line in the block comment has to start with # what should be followed by a single space,
+ except for text indention inside the comment. To separate paragraphs, use one line containing only #.
+
if variable is None or variable == 1:
# If variable is None, something went wrong previously.
#
# Here starts a new important paragraph.
+
Inline comments
- Inline comments: You should prefer block comments over inline comments and use inline comments only where it is really necessary.
+ You should prefer block comments over inline comments and use inline comments only where it is really necessary.
Never use inline comments to explain obvious things like what a line does.
If you want to use an inline comment on a variable, think first, maybe you can use a better variable name instead.
@@ -219,8 +223,9 @@ shop_name = "Walmart"
x = x + 1 # Compensate for border
+
Docstrings
- Docstrings: Last, but not least important comment type is docstring, which is a short version of documentation string.
+ Last, but not least important comment type is docstring, which is a short version of documentation string.
Docstring rules haven't been defined by PEP 8, but by PEP 257 instead.
Docstrings should start and end with three quotes (""").
--
cgit v1.2.3
From 3f1db69bea7a87073b1f58d7dac3e62fcb6438e8 Mon Sep 17 00:00:00 2001
From: ks129 <45097959+ks129@users.noreply.github.com>
Date: Fri, 9 Jul 2021 15:01:04 +0300
Subject: List comment types before
list
---
pydis_site/templates/events/pages/code-jams/code-style-guide.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
(limited to 'pydis_site')
diff --git a/pydis_site/templates/events/pages/code-jams/code-style-guide.html b/pydis_site/templates/events/pages/code-jams/code-style-guide.html
index 0d948cbc..fbcb7612 100644
--- a/pydis_site/templates/events/pages/code-jams/code-style-guide.html
+++ b/pydis_site/templates/events/pages/code-jams/code-style-guide.html
@@ -185,7 +185,7 @@ from pathlib import Path
Out-to-date, wrong comments confuse readers.
Comments content should start with a capital letter and be a full sentence(s).
-
There are three types of comments:
+
There are three types of comments: block comments, inline comments, and docstrings.
Block comments
--
cgit v1.2.3
From b76edd9b5e2fd0b64b1adc6c6f2679d5a75d69ec Mon Sep 17 00:00:00 2001
From: ks129 <45097959+ks129@users.noreply.github.com>
Date: Fri, 9 Jul 2021 15:12:52 +0300
Subject: Improve wording in The Code Style Guide
---
.../events/pages/code-jams/code-style-guide.html | 43 ++++++++++++----------
1 file changed, 24 insertions(+), 19 deletions(-)
(limited to 'pydis_site')
diff --git a/pydis_site/templates/events/pages/code-jams/code-style-guide.html b/pydis_site/templates/events/pages/code-jams/code-style-guide.html
index fbcb7612..31156da2 100644
--- a/pydis_site/templates/events/pages/code-jams/code-style-guide.html
+++ b/pydis_site/templates/events/pages/code-jams/code-style-guide.html
@@ -13,7 +13,7 @@
For end-users, the most important parts of the software are functionality and UI/UX.
But for developers, there is one more important aspect - code style.
While ugly code can do everything that it has to do, developing it further may be a difficult task,
- especially if a developer didn't write an original code.
+ especially if the developer didn't write the original code.
Which one of the following do you prefer to read and work with?
MyPath = '/file.txt'
@@ -57,14 +57,15 @@ result = [
The second is definitely easier to read and understand.
- These scripts are small and if you read even first, you can understand what this code does pretty fast,
+ These scripts are small and even with the first code snippet you can understand what the code does pretty quickly,
but what if the project has thousands and thousands of files in a really complex folder structure?
- Do you want then code what looks like the first example?
- You can save hours sometimes if you write beautiful code that follows style rules.
+ Do you want to work with code that looks like the first example?
+ You can save hours sometimes if you write beautiful code that follows the style guidelines.
- The most important document of Python code style is PEP 8.
- This gives the majority of all Python code style rules. This article will cover the most important rules of PEP 8.
+ The most important code style document for Python is PEP 8.
+ This Python Enhancement Proposal lays out the majority of all Python code style guidelines.
+ This article will cover the most important aspects of PEP 8.
Linters
@@ -75,12 +76,12 @@ result = [
Flake8 points out to you rules what you did break in your code so you can fix them.
-
Rules
+
Guidelines
Basics
For indentation, you should use 4 spaces. Using tabs is not suggested, but if you do, you can't mix spaces and tabs.
PEP 8 defines a maximum line length of 79 characters, however,
- we are not so strict - we let teams choose a maximum line length between 79 and 119 characters.
+ we are not so strict - teams are welcome to choose a maximum line length between 79 and 119 characters.
2 blank lines should be left before functions and classes. Single blank lines are used to split sections and make logical breaks.
@@ -109,7 +110,7 @@ ListOfMyClass = List[MyClass]
Operators
If you have a chain of mathematic operations that you split into multiple lines,
- you should put the operator at the beginning of the line and not to the end of the line.
+ you should put the operator at the beginning of the line and not the end of the line.
# No
result = (
@@ -124,7 +125,7 @@ result = (
+ 2
* 3
)
-
If you compare against None, you should use is and is not, but not compare equality.
+
If you ever check if something is equivalent to None, you should use is and is not instead of the == operator.
# No
if variable == None:
print("Variable is None")
@@ -134,7 +135,7 @@ if variable is None:
print("Variable is None")
You should prefer using <item one> is not <item two> over not <item one> is <item two>.
- Using second makes it harder to understand the expression.
+ Using the latter makes it harder to understand what the expression is trying to do.
# No
if not variable is None:
@@ -153,13 +154,13 @@ import pathlib, os
# Yes
import os
import pathlib
-
Wildcard imports should be avoided in most cases. They make unclear where what comes from.
+
Wildcard imports should be avoided in most cases. It clutters the namespace and makes it less clear where functions or classes are coming from.
# No
from pathlib import *
# Yes
from pathlib import Path
-
You should use isort imports order specification, what means:
+
You should use isort imports order specification, which means:
Group by type: order of import types should be: __future__ imports, standard library imports,
@@ -181,8 +182,12 @@ from pathlib import Path
Comments
Comments are really important because they help everyone understand what code does.
- But as important as having comments is keeping them up-to-date.
- Out-to-date, wrong comments confuse readers.
+ In general, comments should explain why you are doing something if it's not obvious.
+ You should aim to write code that makes it obvious what it is doing and you can use the comments to explain why and provide some context.
+
+
+ Keep in mind that just as important as having comments, is making sure they stay up to date.
+ Out-of-date and incorrect comments confuse readers of your code (including future you).
Comments content should start with a capital letter and be a full sentence(s).
There are three types of comments: block comments, inline comments, and docstrings.
@@ -191,8 +196,8 @@ from pathlib import Path
Block comments
Probably most common comment type. Should be indented to the same level as the code they describe.
- Each line in the block comment has to start with # what should be followed by a single space,
- except for text indention inside the comment. To separate paragraphs, use one line containing only #.
+ Each line in the block comment has to start with # and should be followed by a single space.
+ To separate paragraphs, use one line containing only #.
if variable is None or variable == 1:
# If variable is None, something went wrong previously.
@@ -227,13 +232,13 @@ x = x + 1 # Compensate for border
Last, but not least important comment type is docstring, which is a short version of documentation string.
Docstring rules haven't been defined by PEP 8, but by PEP 257 instead.
- Docstrings should start and end with three quotes (""").
+
Docstrings should start and end with three quotes (""").
There are two types of docstrings: one-line docstrings and multiline docstrings.
One-line docstrings have to start and end in the same line, while multiline docstrings start and end in different lines.
Multiline docstring has two parts: summary line and a longer description, which are separated by one empty line.
- The multiline docstring start and end quotes should be at different lines than the content.
+ The multiline docstring start and end quotes should be on different lines than the content.
# This is a one-line docstring.
"""This is one line module docstring."""
--
cgit v1.2.3
From 0bfa8c16ba0bdee49403a1e67487bf9a47053f6d Mon Sep 17 00:00:00 2001
From: Matteo Bertucci
Date: Fri, 9 Jul 2021 17:42:48 +0200
Subject: Code jam: switch the right menu to ongoing
---
pydis_site/templates/events/index.html | 2 +-
pydis_site/templates/events/pages/code-jams/_index.html | 2 +-
.../templates/events/sidebar/code-jams/ongoing-code-jam.html | 8 ++++++++
.../templates/events/sidebar/code-jams/upcoming-code-jam.html | 8 --------
pydis_site/templates/events/sidebar/ongoing-event.html | 8 ++++++++
pydis_site/templates/events/sidebar/upcoming-event.html | 8 --------
6 files changed, 18 insertions(+), 18 deletions(-)
create mode 100644 pydis_site/templates/events/sidebar/code-jams/ongoing-code-jam.html
delete mode 100644 pydis_site/templates/events/sidebar/code-jams/upcoming-code-jam.html
create mode 100644 pydis_site/templates/events/sidebar/ongoing-event.html
delete mode 100644 pydis_site/templates/events/sidebar/upcoming-event.html
(limited to 'pydis_site')
diff --git a/pydis_site/templates/events/index.html b/pydis_site/templates/events/index.html
index 64bf2c25..daad1c9c 100644
--- a/pydis_site/templates/events/index.html
+++ b/pydis_site/templates/events/index.html
@@ -121,6 +121,6 @@
{% endblock %}
{% block sidebar %}
- {% include "events/sidebar/upcoming-event.html" %}
+ {% include "events/sidebar/ongoing-event.html" %}
{% include "events/sidebar/events-list.html" %}
{% endblock %}
diff --git a/pydis_site/templates/events/pages/code-jams/_index.html b/pydis_site/templates/events/pages/code-jams/_index.html
index fcbfa4d9..22a86db3 100644
--- a/pydis_site/templates/events/pages/code-jams/_index.html
+++ b/pydis_site/templates/events/pages/code-jams/_index.html
@@ -66,7 +66,7 @@
{% endblock %}
{% block sidebar %}
- {% include "events/sidebar/code-jams/upcoming-code-jam.html" %}
+ {% include "events/sidebar/code-jams/ongoing-code-jam.html" %}
{% include "events/sidebar/code-jams/previous-code-jams.html" %}
{% include "events/sidebar/code-jams/useful-information.html" %}
{% endblock %}
diff --git a/pydis_site/templates/events/sidebar/code-jams/ongoing-code-jam.html b/pydis_site/templates/events/sidebar/code-jams/ongoing-code-jam.html
new file mode 100644
index 00000000..f4fa3a37
--- /dev/null
+++ b/pydis_site/templates/events/sidebar/code-jams/ongoing-code-jam.html
@@ -0,0 +1,8 @@
+{% load static %}
+
+
--
cgit v1.2.3
From 877d3c219b56ad170a382e397b3f174d9ee8b948 Mon Sep 17 00:00:00 2001
From: Matteo Bertucci
Date: Fri, 9 Jul 2021 17:44:49 +0200
Subject: Code jam: use case name in code style
---
pydis_site/templates/events/pages/code-jams/code-style-guide.html | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
(limited to 'pydis_site')
diff --git a/pydis_site/templates/events/pages/code-jams/code-style-guide.html b/pydis_site/templates/events/pages/code-jams/code-style-guide.html
index 31156da2..4ff5baaf 100644
--- a/pydis_site/templates/events/pages/code-jams/code-style-guide.html
+++ b/pydis_site/templates/events/pages/code-jams/code-style-guide.html
@@ -91,7 +91,7 @@ result = [
def my_function():
my_variable = "value"
-
Class and type variable names should use the camel case style.
+
Class and type variable names should use the PascalCase style.
from typing import List
@@ -99,7 +99,7 @@ class MyClass:
pass
ListOfMyClass = List[MyClass]
-
Constant names should be all uppercase, and words should be separated with underscores.
+
Constant names should use the SCREAMING_SNAKE_CASE style.
MY_CONSTANT = 1
You should avoid single-character names, as these might be confusing.
--
cgit v1.2.3
From c52c606e6ae09291378c6eae17938d642dc2e463 Mon Sep 17 00:00:00 2001
From: Johannes Christ
Date: Sun, 11 Jul 2021 22:56:17 +0200
Subject: Improvements & fixes to homepage repository display.
These changes mainly aim to prevent multiple concurrent requests from
deadlocking the table due to the lazy evaluation imposed by `objects.all()`,
and introduce some quality of life changes whilst doing so.
To prevent unwanted locks, the following is done:
- Instead of evaluating the first item of `objects.all()` only in order to
determine when the table was most recently updated, we query for the least
recent updated entry and use that instead. As we use `.first()`, the model
instance is loaded directly.
The following quality of life changes are introduced:
- Instead of manual "update or create" logic for repositories retrieved from
the API, use Django's `update_or_create` instead.
- Instead of manual bulk creation of entries on initial data retrieve, Django's
`bulk_create` method is used instead.
- To allow for local testing of this endpoint without having to manually set up
GitHub REST authorization, anonymous GitHub access is used when no
`GITHUB_TOKEN` is configured.
---
pydis_site/apps/home/views/home.py | 62 +++++++++++++++++++-------------------
1 file changed, 31 insertions(+), 31 deletions(-)
(limited to 'pydis_site')
diff --git a/pydis_site/apps/home/views/home.py b/pydis_site/apps/home/views/home.py
index b3767d37..23b6ab24 100644
--- a/pydis_site/apps/home/views/home.py
+++ b/pydis_site/apps/home/views/home.py
@@ -19,7 +19,6 @@ class HomeView(View):
github_api = "https://api.github.com/users/python-discord/repos?per_page=100"
repository_cache_ttl = 3600
- headers = {"Authorization": f"token {GITHUB_TOKEN}"}
# Which of our GitHub repos should be displayed on the front page, and in which order?
repos = [
@@ -35,6 +34,16 @@ class HomeView(View):
"""Clean up stale RepositoryMetadata."""
RepositoryMetadata.objects.exclude(repo_name__in=self.repos).delete()
+ # If no token is defined (for example in local development), then
+ # it does not make sense to pass the Authorization header. More
+ # specifically, GitHub will reject any requests from us due to the
+ # invalid header. We can make a limited number of anonymous requests
+ # though, which is useful for testing.
+ if GITHUB_TOKEN:
+ self.headers = {"Authorization": f"token {GITHUB_TOKEN}"}
+ else:
+ self.headers = {}
+
def _get_api_data(self) -> Dict[str, Dict[str, str]]:
"""
Call the GitHub API and get information about our repos.
@@ -74,35 +83,30 @@ class HomeView(View):
def _get_repo_data(self) -> List[RepositoryMetadata]:
"""Build a list of RepositoryMetadata objects that we can use to populate the front page."""
- database_repositories = []
-
- # First, let's see if we have any metadata cached.
- cached_data = RepositoryMetadata.objects.all()
+ # First off, load the timestamp of the least recently updated entry.
+ oldest_entry = RepositoryMetadata.objects.order_by("last_updated").first()
- # If we don't, we have to create some!
- if not cached_data:
+ # If we did not retrieve any results here, we should import them!
+ if oldest_entry is None:
# Try to get new data from the API. If it fails, we'll return an empty list.
# In this case, we simply don't display our projects on the site.
api_repositories = self._get_api_data()
# Create all the repodata records in the database.
- for api_data in api_repositories.values():
- repo_data = RepositoryMetadata(
+ return RepositoryMetadata.objects.bulk_create(
+ RepositoryMetadata(
repo_name=api_data["full_name"],
description=api_data["description"],
forks=api_data["forks_count"],
stargazers=api_data["stargazers_count"],
language=api_data["language"],
)
-
- repo_data.save()
- database_repositories.append(repo_data)
-
- return database_repositories
+ for api_data in api_repositories.values()
+ )
# If the data is stale, we should refresh it.
- if (timezone.now() - cached_data[0].last_updated).seconds > self.repository_cache_ttl:
+ if (timezone.now() - oldest_entry.last_updated).seconds > self.repository_cache_ttl:
# Try to get new data from the API. If it fails, return the cached data.
api_repositories = self._get_api_data()
@@ -110,22 +114,18 @@ class HomeView(View):
return RepositoryMetadata.objects.all()
# Update or create all RepoData objects in self.repos
- for repo_name, api_data in api_repositories.items():
- try:
- repo_data = RepositoryMetadata.objects.get(repo_name=repo_name)
- repo_data.description = api_data["description"]
- repo_data.language = api_data["language"]
- repo_data.forks = api_data["forks_count"]
- repo_data.stargazers = api_data["stargazers_count"]
- except RepositoryMetadata.DoesNotExist:
- repo_data = RepositoryMetadata(
- repo_name=api_data["full_name"],
- description=api_data["description"],
- forks=api_data["forks_count"],
- stargazers=api_data["stargazers_count"],
- language=api_data["language"],
- )
- repo_data.save()
+ database_repositories = []
+ for api_data in api_repositories.values():
+ repo_data, _created = RepositoryMetadata.objects.update_or_create(
+ repo_name=api_data["full_name"],
+ defaults={
+ 'repo_name': api_data["full_name"],
+ 'description': api_data["description"],
+ 'forks': api_data["forks_count"],
+ 'stargazers': api_data["stargazers_count"],
+ 'language': api_data["language"],
+ }
+ )
database_repositories.append(repo_data)
return database_repositories
--
cgit v1.2.3
From c114398445e11b43cb0ee3e1fe6b70158747ea26 Mon Sep 17 00:00:00 2001
From: Chris Lovering
Date: Mon, 12 Jul 2021 13:16:25 +0100
Subject: Rename repl.it to replit and update links
replit recently updated branding to replit.com, so we now reflect that in our site too.
---
pydis_site/apps/resources/resources/tools/ides/repl_it.yaml | 5 -----
pydis_site/apps/resources/resources/tools/ides/replit.yaml | 5 +++++
2 files changed, 5 insertions(+), 5 deletions(-)
delete mode 100644 pydis_site/apps/resources/resources/tools/ides/repl_it.yaml
create mode 100644 pydis_site/apps/resources/resources/tools/ides/replit.yaml
(limited to 'pydis_site')
diff --git a/pydis_site/apps/resources/resources/tools/ides/repl_it.yaml b/pydis_site/apps/resources/resources/tools/ides/repl_it.yaml
deleted file mode 100644
index 8cd14e14..00000000
--- a/pydis_site/apps/resources/resources/tools/ides/repl_it.yaml
+++ /dev/null
@@ -1,5 +0,0 @@
-description: A free, collaborative, in-browser IDE to code in 50+ languages —
- without spending a second on setup.
-name: repl.it
-title_url: https://repl.it/
-position: 3
diff --git a/pydis_site/apps/resources/resources/tools/ides/replit.yaml b/pydis_site/apps/resources/resources/tools/ides/replit.yaml
new file mode 100644
index 00000000..844c5016
--- /dev/null
+++ b/pydis_site/apps/resources/resources/tools/ides/replit.yaml
@@ -0,0 +1,5 @@
+description: A free, collaborative, in-browser IDE to code in 50+ languages —
+ without spending a second on setup.
+name: replit
+title_url: https://replit.com/
+position: 3
--
cgit v1.2.3
From c404a011a5cf951255c256e35d348331be784e18 Mon Sep 17 00:00:00 2001
From: Hassan Abouelela
Date: Thu, 15 Jul 2021 06:31:13 +0300
Subject: Fixes Broken Doc Link
Fixes a local link that points to a non-existent resource.
Signed-off-by: Hassan Abouelela
---
.../content/resources/guides/pydis-guides/contributing/sir-lancebot.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
(limited to 'pydis_site')
diff --git a/pydis_site/apps/content/resources/guides/pydis-guides/contributing/sir-lancebot.md b/pydis_site/apps/content/resources/guides/pydis-guides/contributing/sir-lancebot.md
index 601cfa4a..068b08ae 100644
--- a/pydis_site/apps/content/resources/guides/pydis-guides/contributing/sir-lancebot.md
+++ b/pydis_site/apps/content/resources/guides/pydis-guides/contributing/sir-lancebot.md
@@ -97,7 +97,7 @@ The first time you run this command, it may take a few minutes while Docker down
$ docker-compose up
```
-If you get any Docker related errors, reference the [Possible Issues](./docker/possible-issues) section of the Docker page.
+If you get any Docker related errors, reference the [Possible Issues](../docker#possible-issues) section of the Docker page.
{: .notification .is-warning }
## Run on the host
--
cgit v1.2.3
From cb268732223bef67bae1b1809e283a5b9a4a60d7 Mon Sep 17 00:00:00 2001
From: onerandomusername
Date: Thu, 15 Jul 2021 02:04:19 -0400
Subject: Documents expected emoji format
---
.../guides/pydis-guides/contributing/sir-lancebot/env-var-reference.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
(limited to 'pydis_site')
diff --git a/pydis_site/apps/content/resources/guides/pydis-guides/contributing/sir-lancebot/env-var-reference.md b/pydis_site/apps/content/resources/guides/pydis-guides/contributing/sir-lancebot/env-var-reference.md
index 5c472eb2..2a7ef0d6 100644
--- a/pydis_site/apps/content/resources/guides/pydis-guides/contributing/sir-lancebot/env-var-reference.md
+++ b/pydis_site/apps/content/resources/guides/pydis-guides/contributing/sir-lancebot/env-var-reference.md
@@ -32,7 +32,7 @@ Additionally, you may find the following environment variables useful during dev
| `REDIS_PASSWORD` | |
| `USE_FAKEREDIS` | If the FakeRedis module should be used. Set this to true if you don't have a Redis database setup. |
| `BOT_SENTRY_DSN` | The DSN of the sentry monitor. |
-| `TRASHCAN_EMOJI` | The emoji to use for the trashcan during paginated embeds |
+| `TRASHCAN_EMOJI` | The full emoji to use for the trashcan. Format should be like the output of `\:emoji:`. |
---
--
cgit v1.2.3
From 3a1f4230cc9f660ff118f9bbf5591ea8aa87ef07 Mon Sep 17 00:00:00 2001
From: Johannes Christ
Date: Thu, 15 Jul 2021 20:44:52 +0200
Subject: Address review comment.
---
pydis_site/apps/home/views/home.py | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
(limited to 'pydis_site')
diff --git a/pydis_site/apps/home/views/home.py b/pydis_site/apps/home/views/home.py
index 23b6ab24..0f26cef3 100644
--- a/pydis_site/apps/home/views/home.py
+++ b/pydis_site/apps/home/views/home.py
@@ -84,10 +84,13 @@ class HomeView(View):
def _get_repo_data(self) -> List[RepositoryMetadata]:
"""Build a list of RepositoryMetadata objects that we can use to populate the front page."""
# First off, load the timestamp of the least recently updated entry.
- oldest_entry = RepositoryMetadata.objects.order_by("last_updated").first()
+ last_update = (
+ RepositoryMetadata.objects.values_list("last_updated", flat=True)
+ .order_by("last_updated").first()
+ )
# If we did not retrieve any results here, we should import them!
- if oldest_entry is None:
+ if last_update is None:
# Try to get new data from the API. If it fails, we'll return an empty list.
# In this case, we simply don't display our projects on the site.
@@ -106,7 +109,7 @@ class HomeView(View):
)
# If the data is stale, we should refresh it.
- if (timezone.now() - oldest_entry.last_updated).seconds > self.repository_cache_ttl:
+ if (timezone.now() - last_update).seconds > self.repository_cache_ttl:
# Try to get new data from the API. If it fails, return the cached data.
api_repositories = self._get_api_data()
--
cgit v1.2.3
From 7dee7b6aa1d5017e873d955de5fe7cb4a514926e Mon Sep 17 00:00:00 2001
From: mbaruh
Date: Sat, 31 Jul 2021 22:59:48 +0300
Subject: Added list of cj8 submissions in subpage
---
.../templates/events/pages/code-jams/8/_index.html | 7 +-
.../events/pages/code-jams/8/submissions.html | 484 +++++++++++++++++++++
.../templates/events/sidebar/code-jams/8.html | 1 +
3 files changed, 488 insertions(+), 4 deletions(-)
create mode 100644 pydis_site/templates/events/pages/code-jams/8/submissions.html
(limited to 'pydis_site')
diff --git a/pydis_site/templates/events/pages/code-jams/8/_index.html b/pydis_site/templates/events/pages/code-jams/8/_index.html
index 34171969..55bdc95b 100644
--- a/pydis_site/templates/events/pages/code-jams/8/_index.html
+++ b/pydis_site/templates/events/pages/code-jams/8/_index.html
@@ -52,11 +52,10 @@
The Qualifier must be submitted through the Code Jam sign-up form.
--
cgit v1.2.3
From 65adf37f8d40e31d6c10f3dd3840d27299a6d993 Mon Sep 17 00:00:00 2001
From: Ethan
Date: Thu, 12 Aug 2021 12:07:12 -0700
Subject: Fix data reviews URL
---
pydis_site/templates/home/timeline.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
(limited to 'pydis_site')
diff --git a/pydis_site/templates/home/timeline.html b/pydis_site/templates/home/timeline.html
index d9069aca..0cfdcb4e 100644
--- a/pydis_site/templates/home/timeline.html
+++ b/pydis_site/templates/home/timeline.html
@@ -111,7 +111,7 @@
pretty much as soon as our new bot and site starts collecting some data. To this day, we keep our privacy policy up to date with all
changes, and since April 2020 we've started doing monthly data reviews.
+ href="https://www.notion.so/6784e3a9752444e89d19e65fd4510d8d?v=69268794b9d2454a9c28e1550e2923c2">monthly data reviews.
May 21st, 2018
--
cgit v1.2.3
From b3d7265e913b5b09729a9ff5bd83a55e8b0ea0fc Mon Sep 17 00:00:00 2001
From: Ethan
Date: Thu, 12 Aug 2021 13:09:57 -0700
Subject: Update pydis_site/templates/home/timeline.html
Co-authored-by: Matteo Bertucci
---
pydis_site/templates/home/timeline.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
(limited to 'pydis_site')
diff --git a/pydis_site/templates/home/timeline.html b/pydis_site/templates/home/timeline.html
index 0cfdcb4e..b404d6c0 100644
--- a/pydis_site/templates/home/timeline.html
+++ b/pydis_site/templates/home/timeline.html
@@ -111,7 +111,7 @@
pretty much as soon as our new bot and site starts collecting some data. To this day, we keep our privacy policy up to date with all
changes, and since April 2020 we've started doing monthly data reviews.
+ href="https://pythondiscord.notion.site/6784e3a9752444e89d19e65fd4510d8d">monthly data reviews.
May 21st, 2018
--
cgit v1.2.3
From aa00efc6048c4bca46acabe18ee6d1b08f52e0e5 Mon Sep 17 00:00:00 2001
From: Numerlor <25886452+Numerlor@users.noreply.github.com>
Date: Mon, 30 Aug 2021 22:53:52 +0200
Subject: Allow empty value for inventory url field
---
.../api/migrations/0072_doc_allow_blank_base_url.py | 19 +++++++++++++++++++
pydis_site/apps/api/models/bot/documentation_link.py | 1 +
2 files changed, 20 insertions(+)
create mode 100644 pydis_site/apps/api/migrations/0072_doc_allow_blank_base_url.py
(limited to 'pydis_site')
diff --git a/pydis_site/apps/api/migrations/0072_doc_allow_blank_base_url.py b/pydis_site/apps/api/migrations/0072_doc_allow_blank_base_url.py
new file mode 100644
index 00000000..d4899354
--- /dev/null
+++ b/pydis_site/apps/api/migrations/0072_doc_allow_blank_base_url.py
@@ -0,0 +1,19 @@
+# Generated by Django 3.0.14 on 2021-08-30 21:09
+
+from django.db import migrations, models
+import pydis_site.apps.api.models.bot.documentation_link
+
+
+class Migration(migrations.Migration):
+
+ dependencies = [
+ ('api', '0071_increase_message_content_4000'),
+ ]
+
+ operations = [
+ migrations.AlterField(
+ model_name='documentationlink',
+ name='base_url',
+ field=models.URLField(blank=True, help_text='The base URL from which documentation will be available for this project. Used to generate links to various symbols within this package.', validators=[pydis_site.apps.api.models.bot.documentation_link.ends_with_slash_validator]),
+ ),
+ ]
diff --git a/pydis_site/apps/api/models/bot/documentation_link.py b/pydis_site/apps/api/models/bot/documentation_link.py
index 3dcc71fc..9941907c 100644
--- a/pydis_site/apps/api/models/bot/documentation_link.py
+++ b/pydis_site/apps/api/models/bot/documentation_link.py
@@ -30,6 +30,7 @@ class DocumentationLink(ModelReprMixin, models.Model):
"The base URL from which documentation will be available for this project. "
"Used to generate links to various symbols within this package."
),
+ blank=True,
validators=(ends_with_slash_validator,)
)
inventory_url = models.URLField(
--
cgit v1.2.3
From 58e061109f3ce09e1d8687f61ad22a335deb893a Mon Sep 17 00:00:00 2001
From: Numerlor <25886452+Numerlor@users.noreply.github.com>
Date: Mon, 30 Aug 2021 23:04:40 +0200
Subject: Move base_url field to the end
In most cases this won't need to be specified,
so it makes more sense to move it out of the way
---
pydis_site/apps/api/admin.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
(limited to 'pydis_site')
diff --git a/pydis_site/apps/api/admin.py b/pydis_site/apps/api/admin.py
index 449e660e..2aca38a1 100644
--- a/pydis_site/apps/api/admin.py
+++ b/pydis_site/apps/api/admin.py
@@ -48,8 +48,8 @@ class BotSettingAdmin(admin.ModelAdmin):
class DocumentationLinkAdmin(admin.ModelAdmin):
"""Admin formatting for the DocumentationLink model."""
- fields = ("package", "base_url", "inventory_url")
- list_display = ("package", "base_url", "inventory_url")
+ fields = ("package", "inventory_url", "base_url")
+ list_display = ("package", "inventory_url", "base_url")
list_editable = ("base_url", "inventory_url")
search_fields = ("package",)
--
cgit v1.2.3
From 89d7dacf3337fed0685aad4409e86b3e137246ad Mon Sep 17 00:00:00 2001
From: Joe Banks
Date: Thu, 2 Sep 2021 21:15:31 +0000
Subject: Add Django Prometheus to installed apps and middleware
---
Dockerfile | 1 +
pydis_site/settings.py | 14 +++++++++++---
2 files changed, 12 insertions(+), 3 deletions(-)
(limited to 'pydis_site')
diff --git a/Dockerfile b/Dockerfile
index c07fc2e2..46f45bf3 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -26,6 +26,7 @@ COPY . .
# Set dummy variables so collectstatic can load settings.py
RUN \
+ BUILDING_DOCKER=yes \
SECRET_KEY=dummy_value \
DATABASE_URL=postgres://localhost \
METRICITY_DB_URL=postgres://localhost \
diff --git a/pydis_site/settings.py b/pydis_site/settings.py
index 7df7ad85..61f3b6f8 100644
--- a/pydis_site/settings.py
+++ b/pydis_site/settings.py
@@ -23,7 +23,8 @@ from pydis_site.constants import GIT_SHA
env = environ.Env(
DEBUG=(bool, False),
- SITE_DSN=(str, "")
+ SITE_DSN=(str, ""),
+ BUILDING_DOCKER=(bool, False)
)
sentry_sdk.init(
@@ -84,10 +85,15 @@ INSTALLED_APPS = [
'django_filters',
'django_simple_bulma',
'rest_framework',
- 'rest_framework.authtoken'
+ 'rest_framework.authtoken',
]
+if not env("BUILDING_DOCKER"):
+ INSTALLED_APPS.append("django_prometheus")
+
+# Ensure that Prometheus middlewares are first and last here.
MIDDLEWARE = [
+ 'django_prometheus.middleware.PrometheusBeforeMiddleware',
'django_hosts.middleware.HostsRequestMiddleware',
'django.middleware.security.SecurityMiddleware',
@@ -100,7 +106,9 @@ MIDDLEWARE = [
'django.middleware.clickjacking.XFrameOptionsMiddleware',
'django_hosts.middleware.HostsResponseMiddleware',
+ 'django_prometheus.middleware.PrometheusAfterMiddleware'
]
+
ROOT_URLCONF = 'pydis_site.urls'
TEMPLATES = [
@@ -131,7 +139,7 @@ WSGI_APPLICATION = 'pydis_site.wsgi.application'
DATABASES = {
'default': env.db(),
- 'metricity': env.db('METRICITY_DB_URL'),
+ 'metricity': env.db(),
}
# Password validation
--
cgit v1.2.3
From b051c454ac853a145fa961f4409fcadd8b1d5dbc Mon Sep 17 00:00:00 2001
From: Joe Banks
Date: Thu, 2 Sep 2021 21:15:52 +0000
Subject: Add Django Prometheus to URLs
---
pydis_site/apps/home/urls.py | 1 +
1 file changed, 1 insertion(+)
(limited to 'pydis_site')
diff --git a/pydis_site/apps/home/urls.py b/pydis_site/apps/home/urls.py
index 1e2af8f3..bb77220b 100644
--- a/pydis_site/apps/home/urls.py
+++ b/pydis_site/apps/home/urls.py
@@ -7,6 +7,7 @@ app_name = 'home'
urlpatterns = [
path('', HomeView.as_view(), name='home'),
path('', include('pydis_site.apps.redirect.urls')),
+ path('', include('django_prometheus.urls')),
path('admin/', admin.site.urls),
path('resources/', include('pydis_site.apps.resources.urls')),
path('pages/', include('pydis_site.apps.content.urls')),
--
cgit v1.2.3
From 4a6ea09f3849f86d8307526e23362ea93365ebef Mon Sep 17 00:00:00 2001
From: Joe Banks
Date: Thu, 2 Sep 2021 21:27:54 +0000
Subject: Revert change to Metricity DB URL
Co-Authored-By: jchristgit
---
pydis_site/settings.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
(limited to 'pydis_site')
diff --git a/pydis_site/settings.py b/pydis_site/settings.py
index 61f3b6f8..6f49763b 100644
--- a/pydis_site/settings.py
+++ b/pydis_site/settings.py
@@ -139,7 +139,7 @@ WSGI_APPLICATION = 'pydis_site.wsgi.application'
DATABASES = {
'default': env.db(),
- 'metricity': env.db(),
+ 'metricity': env.db('METRICITY_DB_URL'),
}
# Password validation
--
cgit v1.2.3
From fa68a1063d4de205cb34c1f17eda62926b23b9db Mon Sep 17 00:00:00 2001
From: Chris Lovering
Date: Fri, 3 Sep 2021 10:40:16 +0100
Subject: Timeout when fetching GitHub repository metadata
Not having this timeout could cause a worker to hang indefinitely
---
pydis_site/apps/home/views/home.py | 15 +++++++++++----
pydis_site/constants.py | 2 ++
2 files changed, 13 insertions(+), 4 deletions(-)
(limited to 'pydis_site')
diff --git a/pydis_site/apps/home/views/home.py b/pydis_site/apps/home/views/home.py
index 0f26cef3..bbb4b815 100644
--- a/pydis_site/apps/home/views/home.py
+++ b/pydis_site/apps/home/views/home.py
@@ -9,7 +9,7 @@ from django.utils import timezone
from django.views import View
from pydis_site.apps.home.models import RepositoryMetadata
-from pydis_site.constants import GITHUB_TOKEN
+from pydis_site.constants import GITHUB_TOKEN, TIMEOUT_PERIOD
log = logging.getLogger(__name__)
@@ -51,9 +51,16 @@ class HomeView(View):
If we're unable to get that info for any reason, return an empty dict.
"""
repo_dict = {}
-
- # Fetch the data from the GitHub API
- api_data: List[dict] = requests.get(self.github_api, headers=self.headers).json()
+ try:
+ # Fetch the data from the GitHub API
+ api_data: List[dict] = requests.get(
+ self.github_api,
+ headers=self.headers,
+ timeout=TIMEOUT_PERIOD
+ ).json()
+ except requests.exceptions.Timeout:
+ log.error("Request to fetch GitHub repository metadata for timed out!")
+ return repo_dict
# Process the API data into our dict
for repo in api_data:
diff --git a/pydis_site/constants.py b/pydis_site/constants.py
index e6a63d12..e913f40f 100644
--- a/pydis_site/constants.py
+++ b/pydis_site/constants.py
@@ -2,3 +2,5 @@ import os
GIT_SHA = os.environ.get("GIT_SHA", "development")
GITHUB_TOKEN = os.environ.get("GITHUB_TOKEN")
+# How long to wait for synchronous requests before timing out
+TIMEOUT_PERIOD = int(os.environ.get("TIMEOUT_PERIOD", 5))
--
cgit v1.2.3
From 8a4b1a15262a91d486c4b95e19533d4d44dd7c2b Mon Sep 17 00:00:00 2001
From: Joe Banks
Date: Sat, 4 Sep 2021 10:32:10 +0100
Subject: Add pod IPs to allowed hosts
---
pydis_site/settings.py | 3 +++
1 file changed, 3 insertions(+)
(limited to 'pydis_site')
diff --git a/pydis_site/settings.py b/pydis_site/settings.py
index 6f49763b..0aa66322 100644
--- a/pydis_site/settings.py
+++ b/pydis_site/settings.py
@@ -14,6 +14,7 @@ import os
import secrets
import sys
from pathlib import Path
+from socket import gethostname, gethostbyname
import environ
import sentry_sdk
@@ -59,6 +60,8 @@ else:
'api.pythondiscord.com',
'staff.pythondiscord.com',
'pydis-api.default.svc.cluster.local',
+ gethostname(),
+ gethostbyname(gethostname())
]
)
SECRET_KEY = env('SECRET_KEY')
--
cgit v1.2.3
From cc6fed3b13ba1aa9ec3cf84227048c9d04ebecda Mon Sep 17 00:00:00 2001
From: Joe Banks
Date: Sat, 4 Sep 2021 10:34:52 +0100
Subject: Correct import order
---
pydis_site/settings.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
(limited to 'pydis_site')
diff --git a/pydis_site/settings.py b/pydis_site/settings.py
index 0aa66322..d2cd8698 100644
--- a/pydis_site/settings.py
+++ b/pydis_site/settings.py
@@ -14,7 +14,7 @@ import os
import secrets
import sys
from pathlib import Path
-from socket import gethostname, gethostbyname
+from socket import gethostbyname, gethostname
import environ
import sentry_sdk
--
cgit v1.2.3
+ +
-diff --git a/pydis_site/templates/events/sidebar/ongoing-event.html b/pydis_site/templates/events/sidebar/ongoing-event.html new file mode 100644 index 00000000..37dfdf77 --- /dev/null +++ b/pydis_site/templates/events/sidebar/ongoing-event.html @@ -0,0 +1,8 @@ +{% load static %} + +