Apply suggestions from code review

Co-authored-by: jakirkham <jakirkham@gmail.com>

blog/2024-10-15-python-noarch-variants.md

@@ -25,13 +25,12 @@ reference implementation is a good way to check the C/C++/Cython
 code against a much simpler python implementation and is also
 useful for platforms like PyPy where the C/C++/Cython implementation
 can be slower than the Python reference implementation due to the
-emulation of the Python C/C++ API by PyPy. For eg: for the Cython
+emulation of the Python C/C++ API by PyPy. For example for the Cython
 package, setting `CYTHON_NO_COMPILE` environment variable
 when building the Cython wheel itself, it will use the Python reference
 implementation. The only way to figure out if a package has a Python
-reference implementation is to look at `setup.py` on packages that
-provide such a file to see if `extensions` are built always or
-with a switch.
+reference implementation is to look at the library's source code
+to see if `extensions` are optional.
 
 To support platforms like PyPy, Some packages build wheels with
 compiled extensions for the platforms that are
@@ -42,16 +41,15 @@ like the free-threading Python build to use these packages by the
 early adopters of these Python versions.
 
 On conda-forge we usually have compiled Python packages, but provide
-no reference implementation. This makes early adopters of new Python
-versions to wait for the conda-forge bot managed by @conda-forge/bot
-team to start the migration and rebuild the packages. For eg: the
-free-threading Python 3.13 build is still not under way because
-conda-forge has decided to wait until the default (GIL enabled)
-Python 3.13 build has migrated enough and upstream packages have added
-support for free-threading builds.
+no reference implementation. This means early adopters of new Python
+versions need to wait for the conda-forge bot managed by @conda-forge/bot
+team to start the migration and rebuild the packages. For example the
+free-threading Python 3.13 build is still paused as
+conda-forge has decided to focus on the default (GIL enabled)
+Python 3.13 build first while upstream packages work on
+supporting free-threading.
 Another issue is that some packages have cyclic dependencies at build
-or test time and this requires manual handling to reduce dependencies
-before the migration and add the dependencies later on.
+or test time and this requires some manual handling.
 
 We have been adding `noarch: python` variants for some feedstocks
 so that the compiled extension has higher priority and the pure