Fixed pre-commit merge issues.

freakboy3742 · freakboy3742 · commit d930ed7b4873 · 2026-01-27T12:03:32.000+08:00
diff --git a/docs/en/news/posts/2016/buzz/hello-website.md b/docs/en/news/posts/2016/buzz/hello-website.md
@@ -19,6 +19,6 @@ The new website uses [Lektor](https://www.getlektor.com), a static site generato
 
 Although we're launching the site today, it's not complete. There's still content that needs to be written, and styling that needs to be fixed. However, we think that the new site is better than the old one, and therefore it's not worth delaying the launch any longer.
 
-This also gives you - the BeeWare community - a great opportunity to contribute. If you find something that is missing from the site, or something that you think could be expressed better, or designed better, the entire site is [available on GitHub](https://github.com/beeware/beeware.github.io/tree/lektor). Fork the repository, make the change you think that is needed, and submit a pull request (against the  `Lektor` branch - not  `master`). All contributions are welcome, and as with all BeeWare contributions, website contributions make the submitter all eligible to receive an exclusive [BeeWare Challenge Coin](/contributing/challenge-coins.md).
+This also gives you - the BeeWare community - a great opportunity to contribute. If you find something that is missing from the site, or something that you think could be expressed better, or designed better, the entire site is [available on GitHub](https://github.com/beeware/beeware.github.io/tree/lektor). Fork the repository, make the change you think that is needed, and submit a pull request (against the `Lektor` branch - not `master`). All contributions are welcome, and as with all BeeWare contributions, website contributions make the submitter all eligible to receive an exclusive [BeeWare Challenge Coin](/contributing/challenge-coins.md).
 
 We hope you enjoy the new site; if you've got any feedback, let us know [with a ticket](https://github.com/beeware/beeware.github.io/issues/) or [on our Discord server](https://beeware.org/bee/chat/).
diff --git a/docs/en/news/posts/2017/buzz/2017-google-summer-of-code-final-report-adam-boniecki.md b/docs/en/news/posts/2017/buzz/2017-google-summer-of-code-final-report-adam-boniecki.md
@@ -13,7 +13,7 @@ With Google Summer of Code 2017 program nearing its end, it is time to summarize
 
 Batavia is a part of BeeWare's collection of projects. As it is still in its early stage of development, for my part I offered to implement a number of features missing from Batavia, ranging from elemental data types, through JSON manipulation and language constructs such as generators. I posted my proposal in [this GitHub thread](https://github.com/beeware/batavia/issues/483) and kept it updated with my progress on a weekly basis.
 
-Note that by the end of GSoC, we have decided to diverge from the proposal and forgo implementation of  `contextlib` in favor of support for Python 3.6 2-byte wide opcodes.
+Note that by the end of GSoC, we have decided to diverge from the proposal and forgo implementation of `contextlib` in favor of support for Python 3.6 2-byte wide opcodes.
 
 Overall it was great learning experience and fun. Big thanks to my mentors Russell Keith-Magee and Katie McLaughlin, and the whole BeeWare community.
 
@@ -37,7 +37,7 @@ Overall it was great learning experience and fun. Big thanks to my mentors Russe
 - [Support for yield from in Python 3.5+](https://github.com/beeware/batavia/pull/599)
 - [Bug fix for yield from and Python 3.6+](https://github.com/beeware/batavia/pull/646)
 
-###  `with` statement
+### `with` statement
 
 - [SETUP\_WITH and WITH\_CLEANUP opcodes](https://github.com/beeware/batavia/pull/594)
 - [WITH\_CLEANUP\_START and WITH\_CLEANUP\_FINISH for Python 3.5+](https://github.com/beeware/batavia/pull/620)
diff --git a/docs/en/news/posts/2018/buzz/2018-google-summer-of-code-final-report-yap-boon-peng.md b/docs/en/news/posts/2018/buzz/2018-google-summer-of-code-final-report-yap-boon-peng.md
@@ -7,15 +7,15 @@ categories:
 - Buzz
 ---
 
-In the blink of an eye, Google Summer of Code (GSoC) 2018 has come to an end. During the three months long coding period, I have contributed several patches in VOC repository of BeeWare, all working towards the ultimate end goal of running  `asyncio` module in VOC. In this blog post (which is my first actual blog post by the way 😄), I will document what I have done so far, why I couldn't make it to the end goal (yea, unfortunately I couldn't get  `asyncio` to work at the end of GSoC 2018), and what's left that needs to be done in order to achieve the end goal (or at least make part of  `asyncio` work).
+In the blink of an eye, Google Summer of Code (GSoC) 2018 has come to an end. During the three months long coding period, I have contributed several patches in VOC repository of BeeWare, all working towards the ultimate end goal of running `asyncio` module in VOC. In this blog post (which is my first actual blog post by the way 😄), I will document what I have done so far, why I couldn't make it to the end goal (yea, unfortunately I couldn't get `asyncio` to work at the end of GSoC 2018), and what's left that needs to be done in order to achieve the end goal (or at least make part of `asyncio` work).
 
 <!-- more -->
 
 ## Building Foundation
 
-The first error that the transpiler throws when attempting to compile  `asyncio` module was "No handler for  `YieldFrom`", so it makes sense to start from this issue first.
+The first error that the transpiler throws when attempting to compile `asyncio` module was "No handler for `YieldFrom`", so it makes sense to start from this issue first.
 
-Another feature related to generator was  `Yield` expression. Before GSoC 2018,  `Yield` statement in VOC was just a statement, meaning  `yield` could not be used as expression. Generator methods such as `generator.send`, `generator.throw` and `generator.close` were not supported as well. Those features are what make asynchronous programming with generator possible, so I spent a few weeks to extend generator functionality in VOC, laying down the path to  `asyncio` module.
+Another feature related to generator was `Yield` expression. Before GSoC 2018, `Yield` statement in VOC was just a statement, meaning `yield` could not be used as expression. Generator methods such as `generator.send`, `generator.throw` and `generator.close` were not supported as well. Those features are what make asynchronous programming with generator possible, so I spent a few weeks to extend generator functionality in VOC, laying down the path to `asyncio` module.
 
 PRs related to generator are listed below:
 
@@ -25,9 +25,9 @@ PRs related to generator are listed below:
 
 ## `Nonlocal` Statement
 
- `Nonlocal` statement was another syntax not supported by VOC. After completion of generator's features, implementing this is the next step towards compiling  `asyncio` module.
+ `Nonlocal` statement was another syntax not supported by VOC. After completion of generator's features, implementing this is the next step towards compiling `asyncio` module.
 
-Implementing this feature took about 3 ~ 4 weeks as this is not as trivial as it seems. I took several approaches on this, while some of them do work, the code is not pretty and  `hacky`, which could come back to bite me/other contributors in the long run. After many discussions with Russell, I refactored the closure mechanism in VOC and took a much cleaner approach in  `nonlocal` implementations. I must admit that I took some short-cuts for the sake of "making `nonlocal` works" in the process of implementing  `nonlocal` statement, resulting in poor design and messy codes. Many thanks to Russell, who helped me to improve my coding style and told me not to be discouraged when I'm stuck. 😄
+Implementing this feature took about 3 ~ 4 weeks as this is not as trivial as it seems. I took several approaches on this, while some of them do work, the code is not pretty and `hacky`, which could come back to bite me/other contributors in the long run. After many discussions with Russell, I refactored the closure mechanism in VOC and took a much cleaner approach in `nonlocal` implementations. I must admit that I took some short-cuts for the sake of "making `nonlocal` works" in the process of implementing `nonlocal` statement, resulting in poor design and messy codes. Many thanks to Russell, who helped me to improve my coding style and told me not to be discouraged when I'm stuck. 😄
 
 Related PRs:
 
@@ -36,7 +36,7 @@ Related PRs:
 
 ## The Collections Module
 
-Next item on my hit list was pure Java implementations of the  `collections` module.  `asyncio` module depends on 3 data structures from  `collections`, namely  `defauldict`,  `Deque` and  `OrderedDict`. Two of them ( `defaultdict` and  `Deque`) are implemented in C in CPython, plus they have good analog in Java, so it makes senses to implement the module in Java. Porting  `defauldict`,  `Deque` and  `OrderedDict` to Java in VOC is relatively straight-forward, taking about 1.5 weeks to complete.
+Next item on my hit list was pure Java implementations of the `collections` module. `asyncio` module depends on 3 data structures from `collections`, namely `defauldict`, `Deque` and `OrderedDict`. Two of them ( `defaultdict` and `Deque`) are implemented in C in CPython, plus they have good analog in Java, so it makes senses to implement the module in Java. Porting `defauldict`, `Deque` and `OrderedDict` to Java in VOC is relatively straight-forward, taking about 1.5 weeks to complete.
 
 Related PRs:
 
@@ -71,14 +71,14 @@ Related PRs:
 
 ## Towards The Ultimate End Goal
 
-Unfortunately, three months of GSoC coding period was not enough for me to bring  `asyncio` module to VOC. The `nonlocal` statement implementation was the biggest blocker for me mainly because I didn't think thoroughly before writing code. If I were to plan carefully and lay out a general coding direction, I would've completed it in much shorter time and have time for other implementations. An advice for the aspiring and upcoming GSoC-er, don't rush your code, make sure you know 100% about what you're doing before diving into the codes.
+Unfortunately, three months of GSoC coding period was not enough for me to bring `asyncio` module to VOC. The `nonlocal` statement implementation was the biggest blocker for me mainly because I didn't think thoroughly before writing code. If I were to plan carefully and lay out a general coding direction, I would've completed it in much shorter time and have time for other implementations. An advice for the aspiring and upcoming GSoC-er, don't rush your code, make sure you know 100% about what you're doing before diving into the codes.
 
-With that said, following are the list of modules to be implemented/ported to Java before  `asyncio` will work in VOC:
+With that said, following are the list of modules to be implemented/ported to Java before `asyncio` will work in VOC:
 
--  `socket` module (a bit tricky since Java doesn't support Unix domain socket natively)
--  `selectors` module (high level I/O operations)
--  `threading` module (might be easier to implement this first since threading in Python is an emulation of Java's Thread)
--  `time` module (partially implemented in VOC)
+- `socket` module (a bit tricky since Java doesn't support Unix domain socket natively)
+- `selectors` module (high level I/O operations)
+- `threading` module (might be easier to implement this first since threading in Python is an emulation of Java's Thread)
+- `time` module (partially implemented in VOC)
 
 ## Final Thoughts
 
diff --git a/docs/en/news/posts/2022/buzz/2022q3-roadmap.md b/docs/en/news/posts/2022/buzz/2022q3-roadmap.md
@@ -34,7 +34,7 @@ Briefcase has an MSI packaging backend for Windows; and while this backend works
 
 - Adding a stub binary for Windows apps, so that Briefcase apps present to the task manager with the apps name and icon, rather than "`pythonw`";
 - Improving log capture on Windows, so that it is easier to diagnose when problems occur; and
-- Fixing some issues with the way the  `site` is defined and used. This may also address some issues we've seen with binary modules in some Windows apps.
+- Fixing some issues with the way the `site` is defined and used. This may also address some issues we've seen with binary modules in some Windows apps.
 
 ### Binary modules
 
diff --git a/docs/en/news/posts/2022/buzz/2022q4-roadmap.md b/docs/en/news/posts/2022/buzz/2022q4-roadmap.md
@@ -32,7 +32,7 @@ In Q4, we're planning to focus on:
 
 The primary focus for Q4 will be Toga. There are a number of pieces of work involved with this:
 
-- **Housekeeping** - Basic repository maintenance tasks, like enabling  `black`, introducing pre-commit hooks, `towncrier`, and automating release infrastructure.
+- **Housekeeping** - Basic repository maintenance tasks, like enabling `black`, introducing pre-commit hooks, `towncrier`, and automating release infrastructure.
 - **Example consolidation** - Toga's examples folder has become a sprawling collection of code that is part documentation, part testbed. We need to start consolidating these examples into 2 apps - one that is a user-facing demonstrator of Toga features, and one that can be used as a functional test of Toga features.
 - **Testing** - Modernizing and cleaning up the existing test suite, and working out how to automate GUI tests
 - **Documentation** - Toga's documentation has lagged behind an acceptable standard for a long time,
diff --git a/docs/en/news/posts/2022/buzz/september-2022-status-update.md b/docs/en/news/posts/2022/buzz/september-2022-status-update.md
@@ -33,7 +33,7 @@ On iOS, we've [reworked how the support packages are constructed](https://github
 
 While we are now able to support binary packages on mobile platforms, this doesn't mean that *every* binary package is automatically supported. Binary wheels need to be compiled for mobile platforms, and compiling for mobile platforms can be complicated. However, we've compiled ~40 of them most popular packages with binary components (including NumPy, Pandas, Cryptography, Pillow and Matplotlib), and made them available as dependencies. In order to get working builds, some of these packages are slightly older versions (e.g., cryptography is a version from before the introduction of the rust dependency); however, we've endeavored to provide the most recent versions possible.
 
-A full list of supported packages can be found [on the Chaquopy package repository for Android](https://chaquo.com/pypi-7.0/), and the [BeeWare repository for iOS](https://anaconda.org/beeware/repo). If your project uses one of these packages, you only need to add them to the  `requires` definition in your `pyproject.toml`, then update and re-build your project, and you're done.
+A full list of supported packages can be found [on the Chaquopy package repository for Android](https://chaquo.com/pypi-7.0/), and the [BeeWare repository for iOS](https://anaconda.org/beeware/repo). If your project uses one of these packages, you only need to add them to the `requires` definition in your `pyproject.toml`, then update and re-build your project, and you're done.
 
 If there’s a package you want that isn't on this list, you'll need to request a binary wheel. For Android, [open a ticket on the Chaquopy repository](https://github.com/chaquo/chaquopy/issues). For iOS, [open a ticket on this repository](https://github.com/freakboy3742/chaquopy). If you're adventurous, you can also try building wheels yourself. The issue trackers are on a project that has as "forge-like" tool for building wheels, in the `server/pypi` folder; there are tools and documentation describing how to build a package. The use of these projects is a short-term measure; in the longer term, we want to move to an actual “forge”-style community-managed model for managing binary packages.
 
