Move to month

Signed-off-by: Bernát Gábor <bgabor8@bloomberg.net>

Author: gaborbernat

.pre-commit-config.yaml

@@ -0,0 +1,15 @@
+repos:
+ - repo: https://github.com/pre-commit/pre-commit-hooks
+ rev: v4.6.0
+ hooks:
+ - id: end-of-file-fixer
+ - id: trailing-whitespace
+ - repo: https://github.com/rbubley/mirrors-prettier
+ rev: "v3.3.3"
+ hooks:
+ - id: prettier
+ exclude: layouts/shortcodes/project.html|layouts/shortcodes/img.html
+ additional_dependencies:
+ - prettier@3.3.3
+ - "@prettier/plugin-xml@3.4.1"
+ args: ["--print-width=120", "--prose-wrap=always"]

assets/css/syntax.css

@@ -39,8 +39,8 @@ For the following projects, while I do hold the write commit bit, I only help wi
 
 1. {{< project name="build" org="pypa" ci="test">}}
 1. {{< project name="pytest-memray" org="bloomberg" ci="build">}}
-1. {{< project name="tox-conda" org="tox-dev" ci="check">}}
 1. {{< project name="ipydatagrid" org="jupyter-widgets" ci="check">}}
+1. {{< project name="tox-conda" org="tox-dev" ci="check">}}
 1. {{< project name="attrs-strict" org="bloomberg" ci="check">}}
 
 You can find my Curriculum Vitae (or résumé) on the following link

content/about.md

@@ -12,11 +12,11 @@ title = "Python packaging - Past, Present, Future"
 Have you ever wondered what happens exactly when you run pip install? This post will give you a detailed overview of the
 steps involved in the past, and how it all changes with the adoption of PEP-517 and PEP-518.
 
-[In my previous post]({{< ref "pep-517-and-python-packaging" >}}) I've described how it's possible to install three
-types of content: source tree, source distribution, and wheels. Only the last two types are uploaded to PyPI, the
-central Python repository. However, one could get its hands on a source tree (by feeding, for example, a git protocol
-for pip). The advantage of wheels over the others is that it does not require any build operation to happen on the user
-machine; it's just downloading and extract.
+[In my previous post]({{< ref "pep-517-and-python-packaging" >}}) I've described how it's possible to install three types
+of content: source tree, source distribution, and wheels. Only the last two types are uploaded to PyPI, the central Python
+repository. However, one could get its hands on a source tree (by feeding, for example, a git protocol for pip). The advantage
+of wheels over the others is that it does not require any build operation to happen on the user machine; it's just downloading
+and extract.
 
 ## Building python packages
 
@@ -222,7 +222,7 @@ builds. The specifications for these standards were written up and debated in lo
 proposals were deemed good enough to benefit the most, but some less mainstream use cases could have been overlooked.
 
 If your use case is such, don't worry the PEPs are open to enhancement at any point if we deem required. [In my next
-post of this series here]({{< ref "growing-pain" >}}) I'll go over some of the pain points the community bumped into
-while releasing these two PEPs. These should serve as lessons learned and show that there's still some work to be done.
-It's not everything perfect yet. However, we're getting better. Join the packaging community if you can help out, and
-let's make things better together!
+post of this series here]({{< ref "growing-pain" >}}) I'll go over some of the pain points the community bumped into while
+releasing these two PEPs. These should serve as lessons learned and show that there's still some work to be done. It's not
+everything perfect yet. However, we're getting better. Join the packaging community if you can help out, and let's make things
+better together!

content/posts/pep-517-518/index.md

@@ -227,5 +227,5 @@ The difference between a source tree, a source distribution, and a wheel:
 
 {{< figure src="smart_pug.webp">}}
 
-[Read the next post of the series here]({{< ref "pep-517-518" >}}) to determine what happens when we install a package.
-Thanks for reading!
+[Read the next post of the series here]({{< ref "pep-517-518" >}}) to determine what happens when we install a package. Thanks
+for reading!

content/posts/pep-517-and-python-packaging/index.md

@@ -423,12 +423,16 @@ The upside of this is that:
 Now there are also some hefty penalties to pay:
 
 <div class='cross'>
- 
-- You just duplicated your codebase, as every function now has two definitions (note you don't need to replicate your body or default arguments, the ``...`` - ellipsis - is used as a placeholder for these). 
-- Now, you have some extra files that need to be packaged and shipped with your code. 
-- It's impossible to annotate contents inside functions (this means both methods inside methods and local variables). 
-- There is no check that your implementation file matches your stub's signature (furthermore, IDEs always use the stub definition). 
-- However, the heaviest penalty is that you cannot type check the code you're type hinting via a stub. Stub file type hints were designed to be used to type-check code that uses the library. But not too type check the codebase itself what your type hinting. 
+
+- You just duplicated your codebase, as every function now has two definitions (note you don't need to replicate your
+ body or default arguments, the `...` - ellipsis - is used as a placeholder for these).
+- Now, you have some extra files that need to be packaged and shipped with your code.
+- It's impossible to annotate contents inside functions (this means both methods inside methods and local variables).
+- There is no check that your implementation file matches your stub's signature (furthermore, IDEs always use the stub
+ definition).
+- However, the heaviest penalty is that you cannot type check the code you're type hinting via a stub. Stub file type
+hints were designed to be used to type-check code that uses the library. But not too type check the codebase itself what
+your type hinting.
 </div>
 
 The last two drawback makes it incredibly hard to check that the type hinted codebase via a stub file is in sync or not.
@@ -912,10 +916,10 @@ things:
 - finally, appending to the correct parameter into the docstring.
 
 For example `Any` maps to `` py:data:`~typing.Any` ``. Things can get even more complicated for compound types such as
-`Mapping[str, bool]` needs to be translated for example too
-`` :class:`~typing.Mapping`\\[:class:`str`, :class:`bool`] ``. Getting the translation here right (e.g. having `class`
-or `data` namespace) is essential so that the `intersphinx` plugin will work correctly (a plugin that links types
-directly to their respective Python standard library documentation link).
+`Mapping[str, bool]` needs to be translated for example too ``:class:`~typing.Mapping`\\[:class:`str`, :class:`bool`]``.
+Getting the translation here right (e.g. having `class` or `data` namespace) is essential so that the `intersphinx`
+plugin will work correctly (a plugin that links types directly to their respective Python standard library documentation
+link).
 
 In order to use it one needs to install it via `pip install sphinx-autodoc-types>=2.1.1` and then enable in inside the
 `conf.py` file:

content/posts/type-hints/index.md

@@ -26,7 +26,7 @@
 {{/* only use images smaller than or equal to the src (original) image size, as Hugo will upscale small images */}}
 {{/* set the sizes attribute to (min-width: 35em) 1200px, 100vw unless overridden in shortcode */}}
 
-<img 
+<img
  {{ with .Get "sizes" }}sizes='{{.}}'{{ else }}sizes="(min-width: 35em) 1200px, 100vw"{{ end }}
  srcset='
  {{ if ge $src.Width "500" }}
@@ -42,8 +42,8 @@
  {{ with $large.RelPermalink }}, {{.}} 1500w {{ end }}
  {{ end }}'
  {{ if .Get (print $medium) }}
- src="{{ $medium.RelPermalink }}" 
+ src="{{ $medium.RelPermalink }}"
  {{ else }}
- src="{{ $src.RelPermalink }}" 
+ src="{{ $src.RelPermalink }}"
  {{ end }}
- {{ with .Get "alt" }}alt="{{.}}"{{ else }}alt=""{{ end }}>
+ {{ with .Get "alt" }}alt="{{.}}"{{ else }}alt=""{{ end }}>

layouts/shortcodes/img.html

@@ -1,5 +1,19 @@
-<a href="https://pepy.tech/project/{{.Get "name"}}" target="_blank" rel="noopener"><img src="https://static.pepy.tech/badge/{{.Get "name"}}/week" alt="PyPI - Downloads"></a>
-<a href="https://github.com/{{.Get "org"}}/{{.Get "name"}}/actions/workflows/{{.Get "ci"}}.yml" target="_blank" rel="noopener"><img src="https://github.com/{{.Get "org"}}/{{.Get "name"}}/actions/workflows/{{.Get "ci"}}.yml/badge.svg" alt="check"></a>
+<a href="https://github.com/{{.Get "org"}}/{{.Get "name"}}/actions/workflows/{{.Get "ci"}}.yml" target="_blank" rel="noopener">
+ <img src="https://github.com/{{.Get "org"}}/{{.Get "name"}}/actions/workflows/{{.Get "ci"}}.yml/badge.svg" alt="check">
+</a>
+
+<a href="https://pypi.org/project/{{.Get "name"}}" target="_blank" rel="noopener">
+ <img src="https://img.shields.io/pypi/v/{{.Get "name"}}?style=flat-square" alt="PyPI">
+</a>
+
+<a href="https://pepy.tech/project/{{.Get "name"}}" target="_blank" rel="noopener">
+ <img src="https://static.pepy.tech/badge/{{.Get "name"}}/month" alt="PyPI - Downloads">
+</a>
+
+<a href="https://github.com/{{.Get "org"}}/{{.Get "name"}}/commits">
 <img src="https://img.shields.io/github/last-commit/{{.Get "org"}}/{{.Get "name"}}?logo=python&amp;style=flat-square" alt="GitHub last commit">
-<a href="https://pypi.org/project/{{.Get "name"}}" target="_blank" rel="noopener"><img src="https://img.shields.io/pypi/v/{{.Get "name"}}?style=flat-square" alt="PyPI"></a>
-<a href="https://github.com/{{.Get "org"}}/{{.Get "name"}}">{{.Get "name"}}</a>
+</a>
+
+<a href="https://github.com/{{.Get "org"}}/{{.Get "name"}}">
+{{.Get "name"}}
+</a>

layouts/shortcodes/project.html

@@ -1,3 +1 @@
-<div class="toc">
- {{ .Page.TableOfContents }}
-</div>
+<div class="toc">{{ .Page.TableOfContents }}</div>