[Tutor] accessing modules found throughout a package?

[James Hartley]

In my current project, I am developing a package. It makes sense to embed
tests throughout the package's directory structure as they should be part
of the package & its distribution. It may raise eyebrows that I have tests
sprinkled through various directories, but there are reasons for keeping
some tests in the same proximity as the modules needed to import data into
a database. There are several directories importing data according to
different constraints.

The problem/annoyance I am facing is that tests need to access modules in
other directories, I have to play games at the beginning of each test file
which looks at os.path.realpath(__file__) to ascertain where the root of
the package can be found before calling os.path.append(). Since the
package is still under development, its structure is still in flux. As a
result, any structural change requires that I re-adjust each test file
ensuring that the paths are still correct.

Here is the package's general structure:

+/package_directory/
|
+/data/
+ base_classes_used_by_some_tests.py
|
+/import_1/
| + test_code_requiring_base_classes_above.py
|
+/import_2/
| + different_test_code_requiring_base_classes_above.py
|
+/tests/
|
+ more_test_code_requiring_base_classes_above.py

What is a better solution to minimize any tweaking forced upon the test
code? It seems that formally installing the package will only remedy some
of the problems I am currently experiencing.

Any suggestions you may have will be very welcomed.

Jim
_______________________________________________
Tutor maillist - ***@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

[Ben Finney]

In my current project, I am developing a package. It makes sense to
embed tests throughout the package's directory structure as they
should be part of the package & its distribution.

Yet, as you're finding, it also causes headaches.

First, know that you don't need to scatter the test suite through out the
rest of your code in order to meet the goal of including it in the
distribution.

You can distribute the test suite along with the rest, by specifying it
as part of the source distribution. See the “manifest” for Distutils.

To have your test suite run correctly when it's located separately from
the system under test, you need to specify the top-level directory as
being in the Python import path, during the test suite run.

Then, you can have all the test suite modules do relative imports from
that top level, to get the modules they need to import from the system
under test.

That way, the test suite imports modules the same way any other user of
your code will import them: from the top level package.

Look up “relative and absolute imports” to see how they work, and how
they differ, in Python.

Any suggestions you may have will be very welcomed.

I hope that helps.
--
\ “Faith is generally nothing more than the permission religious |
`\ people give to one another to believe things strongly without |
_o__) evidence.” —Sam Harris, _Letter to a Christian Nation_ 2006 |
Ben Finney

_______________________________________________
Tutor maillist - ***@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman

[Steven D'Aprano]

Post by James Hartley
In my current project, I am developing a package. It makes sense to embed
tests throughout the package's directory structure as they should be part
of the package & its distribution. It may raise eyebrows that I have tests
sprinkled through various directories, but there are reasons for keeping
some tests in the same proximity as the modules needed to import data into
a database. There are several directories importing data according to
different constraints.

I'm sure that there are "reasons", but are they good reasons?

The package structure you show strikes me as odd. You have code under a
"data" subdirectory, which seems deeply weird to me. Have you considered
a more convention structure?


+-- package
+-- __init__.py
+-- module.py
+-- subpackage
+-- __init__.py
+-- module.py
+-- data
+-- data.jpg
+-- data.txt
+-- tests
+-- __init__.py
+-- base_tests.py
+-- more_tests.py
+-- other_tests.py


which will correspond to Python imports like:

# Absolute imports
import package
import package.module
import package.subpackage
import package.subpackage.module
import package.tests
import package.tests.more_tests

which will work from your package's callers, and from within the package
itself provided the top level directory can be found within Python's
path. Within the package you can also use relative imports, see the
docs for more detail.


So within (say) more_tests.py you should be able to say:

from . import base_tests

or

import package.tests.base_tests


You can get the path of the data subdirectory like so:

import package
path = os.path.join(package.__path__[0], "data")


At the very least, this conventional structure will avoid problems with
the test modules, since they won't change location. Only your package
modules themselves will change location during development.

[Alex Kleider]

Post by Steven D'Aprano
which will work from your package's callers, and from within the package
itself provided the top level directory can be found within Python's
path. Within the package you can also use relative imports, see the
docs for more detail.

How does one arrange so "the top level directory _can_ be found within
Python's path."?


_______________________________________________
Tutor maillist - ***@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

[Alex Kleider]

Post by Alex Kleider

Post by Steven D'Aprano
which will work from your package's callers, and from within the package
itself provided the top level directory can be found within Python's
path. Within the package you can also use relative imports, see the
docs for more detail.

How does one arrange so "the top level directory _can_ be found within
Python's path."?

Is the answer to include the following at the beginning of each file?

if not 'path/to/top/level/package/directory' in sys.path:
sys.path.append('path/to/top/level/package/directory')


_______________________________________________
Tutor maillist - ***@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

[Alan Gauld]

Post by Alex Kleider

Post by Alex Kleider
How does one arrange so "the top level directory _can_ be found within
Python's path."?

Is the answer to include the following at the beginning of each file?
sys.path.append('path/to/top/level/package/directory')

You could, but you can also add it to your PYTHONPATH environment variable.
--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


_______________________________________________
Tutor maillist - ***@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

[Alex Kleider]

Post by Alan Gauld

Post by Alex Kleider

Post by Alex Kleider
How does one arrange so "the top level directory _can_ be found within
Python's path."?

Is the answer to include the following at the beginning of each file?
sys.path.append('path/to/top/level/package/directory')

You could, but you can also add it to your PYTHONPATH environment variable.

It seems to not exist:
(venv)***@x301:~/Py/CSV/debk$ echo $PYTHONPATH

Should I add the following to the end of my ~/.bashrc file?
export PYTHONPATH="$PYTHONPATH:/home/alex/Py"

_______________________________________________
Tutor maillist - ***@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

[Martin A. Brown]

Hello Alex,

Post by Alex Kleider

Post by Alan Gauld

Post by Alex Kleider

Post by Alex Kleider
How does one arrange so "the top level directory _can_ be found within
Python's path."?

Is the answer to include the following at the beginning of each file?
sys.path.append('path/to/top/level/package/directory')

You could, but you can also add it to your PYTHONPATH environment variable.

Should I add the following to the end of my ~/.bashrc file?
export PYTHONPATH="$PYTHONPATH:/home/alex/Py"

Quite possibly. You can test it out easily as follows to be
certain that this allows you to import your Python easily.

$ PYTHONPATH=/home/alex/Py python
If that works, then, yes. See also the docs [0].

This should certainly be suitable for personal work.

<detour type="shell">

It is generally polite to prefix any existing value of PYTHONPATH
before adding your own. For a possibly esoteric improvement, you
might consider a little shell refinement to avoid leaving any empty
path in the variable. What do I mean? After the fragment in your
.bashrc (assuming PYTHONPATH remains unset before the above line
runs), you will end up with:

PYTHONPATH=:/home/alex/Py

Oops! There's an empty path in there in the first position. A
minor improvement would be to only prepend the PYTHONPATH and
required colon if there's a value to PYTHONPATH already. So, this
little beautifully obnoxious bash parameter expansion gem will
accomplish that for you:

PYTHONPATH="${PYTHONPATH:+$PYTHONPATH:}/home/alex/Py"

</detour>

Good luck,

-Martin

[0] https://docs.python.org/3/using/cmdline.html#envvar-PYTHONPATH

[Ben Finney]

Post by Alex Kleider
Should I add the following to the end of my ~/.bashrc file?
export PYTHONPATH="$PYTHONPATH:/home/alex/Py"

No, because the entry should only be in PYTHONPATH *if* you want imports
to come from that package.

So the advice is:

* For the run-time application, it should be installed using the
Distutils system (‘python3 ./setup.py install’) and hence its modules
will be available on the path as normal.

That is, the normal operation of the code will *not* be to run it from
the development working tree, so that path should not be in your
normal PYTHONPATH.

* THe ‘sys.path’ sequence is equivalent to the PYTHONPATH environment
variable, and can be modified in your test suite's Python code as
described elsewhere. But don't do that, because:

* Python will automatically add a ‘sys.path’ entry for the directory
containing the script named on the command line. So this:

$ cd ~/Projects/lorem/
$ python3 ./setup.py test

will run the ‘setup.py’ program with ‘sys.path’ already modified to
contain the directory ‘/home/YOURUSERNAME/Projects/lorem’. Any
packages in that directory are available for absolute import, *during*
that test suite run.

* For this reason (and others), it's recommended to have ‘setup.py’ at
the top level of your working tree. Put all the other Python code in
packages and modules importable from the same location as ‘setup.py’,
and run ‘setup.py’ from that directory to allow the ‘sys.path’
modification to work as expected.
--
\ “Alternative explanations are always welcome in science, if |
`\ they are better and explain more. Alternative explanations that |
_o__) explain nothing are not welcome.” —Victor J. Stenger, 2001-11-05 |
Ben Finney

_______________________________________________
Tutor maillist - ***@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/list

[Ben Finney]

Post by Ben Finney
* Python will automatically add a ‘sys.path’ entry for the directory
$ cd ~/Projects/lorem/
$ python3 ./setup.py test
will run the ‘setup.py’ program with ‘sys.path’ already modified to
contain the directory ‘/home/YOURUSERNAME/Projects/lorem’. Any
packages in that directory are available for absolute import, *during*
that test suite run.

This behaviour is detailed further in the documentation
<URL:https://docs.python.org/3/using/cmdline.html#using-on-interface-options>.
--
\ “The way to build large Python applications is to componentize |
`\ and loosely-couple the hell out of everything.” —Aahz |
_o__) |
Ben Finney

_______________________________________________
Tutor maillist - ***@python.org
To unsubscribe or change subscription options:
https://mai

[Steven D'Aprano]

Post by Alex Kleider

Post by Steven D'Aprano
which will work from your package's callers, and from within the package
itself provided the top level directory can be found within Python's
path. Within the package you can also use relative imports, see the
docs for more detail.

How does one arrange so "the top level directory _can_ be found within
Python's path."?

The boring, conventional way is to install the package under
site-packages.

E.g. if Python is installed here:

/usr/local/lib/python2.7/

(for example), there will also be a directory:

/usr/local/lib/python2.7/site-packages/

If you stick the package directory inside site-packages, it will be
visible to be imported from Python2.7.

If you install the package using an installer like pip or setuptools,
chances are it will automatically be placed in the correct
site-packages. Downside of this is that you need root or admin
privileges, however starting with Python 2.6, there's also a per-user
site-packages directory. On Linux systems, that will default to
something like:

~/.local/lib/python2.7/site-packages/


The less boring way is to adjust your path. There are various ways to do this:

(1) Set an environment variable.

E.g. in my .bashrc file, I have this:

export PYTHONPATH="/home/steve/python/:/home/steve/python/utilities"

which will add the two ":" separated paths to sys.path.

You can launch Python using a specific path like this from bash:

PYTHONPATH="/tmp:$PYTHONPATH" python

(Note that you have to use "" quotes, as bash doesn't evaluate
environment variables inside '' quotes.)


(2) If you set a PYTHONSTARTUP environment variable giving the path to a
Python file, you can manipulate the path inside that:

# startup.py
import sys
sys.path.append("something/or/other/")

but be aware that the startup file only runs when you run the
interactive interpreter directly, it doesn't run when you execute
scripts.

(3) Of course a module itself can also import sys and manipulate the
path, but that doesn't help you import the module in the first instance.

(4) If you're distributing an application which happens to be written in
Python, one nice trick is the make the entry-point to the application
(the executable file that you run) a shell script which sets up the
PYTHONPATH environment variable (and any others you need) before calling
Python. It doesn't have to be a shell script: you can do it in Python as
well. Since the application script never gets imported, only run
directly, the bootstrap problem of (3) doesn't matter.

(5) If you're distributing your own Python installation, you can
hack the values for sys.prefix and sys.exec_prefix, or the site.py file.
But if you do that, you're on your own.

(6) Create a spam.pth file listing directories to add.

(7) Create a sitecustomize.py or usercustomize.py file.

For (6) and (7), see the documentation for site.py:

https://docs.python.org/2/library/site.html
https://docs.python.org/3/library/site.html

[Alex Kleider]

Post by Alex Kleider

Post by Steven D'Aprano
which will work from your package's callers, and from within the package
itself provided the top level directory can be found within Python's
path. Within the package you can also use relative imports, see the
docs for more detail.

How does one arrange so "the top level directory _can_ be found within
Python's path."?

Thank you, Alan, Martin, Ben and Steve.
I'm a long way from distributing packages! Rather I'm simply
writing scripts for personal use and would like to do it using
Test Driven Development- hence my wish to be able to reference
modules within my development directory.
I've been able to satisfy my needs by adding
export PYTHONPATH="${PYTHONPATH:+$PYTHONPATH:}/home/alex/Py"
to the end of my ~/.bashrc
although use of a setup.py file is probably the more 'pythonic'
way of doing it. From my reading so far [1] it's not clear to
me exactly how this works but a bit of experimentation might
rectify that.
Again, thank you.
Alex

[1]
https://docs.python.org/3/distutils/introduction.html#distutils-simple-example


_______________________________________________
Tutor maillist - ***@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

[Ben Finney]

Post by Alex Kleider
I'm a long way from distributing packages!

You can keep working at your own pace, and that's good. But even better,
I would strongly recommend that you work with other people early and
frequently.

Programming is fundamentally a process of collaboration and
communication with other human programmers.

The habits you form alone can be eccentric and unhelpful, with no-one to
comment on strange habits you may be forming without even noticing until
they are too deeply entrenched to easily avoid.

Working frequently with others on the same code base will not only flush
out these oddities, but also help you to appreciate the consensus
decisions made in the past by the Python community as a whole.

So, while it's not essential, I would heartily encourage you to pick
some of the PyPI projects you are enjoying, or want to improve, and
contact their maintainers with your offer to fix specific things. Work
with other Python programmers on a common code base, and watch your
skills broaden and improve!
--
\ “For man, as for flower and beast and bird, the supreme triumph |
`\ is to be most vividly, most perfectly alive” —D.H. Lawrence |
_o__) |
Ben Finney

_______________________________________________
Tutor maillist - ***@python.org
To unsubscribe or change subscription options:
h

[Alex Kleider]

Post by Ben Finney

Post by Alex Kleider
I'm a long way from distributing packages!

You can keep working at your own pace, and that's good. But even better,
I would strongly recommend that you work with other people early and
frequently.
Programming is fundamentally a process of collaboration and
communication with other human programmers.
The habits you form alone can be eccentric and unhelpful, with no-one to
comment on strange habits you may be forming without even noticing until
they are too deeply entrenched to easily avoid.
Working frequently with others on the same code base will not only flush
out these oddities, but also help you to appreciate the consensus
decisions made in the past by the Python community as a whole.
So, while it's not essential, I would heartily encourage you to pick
some of the PyPI projects you are enjoying, or want to improve, and
contact their maintainers with your offer to fix specific things. Work
with other Python programmers on a common code base, and watch your
skills broaden and improve!

How I wish I could find such collaborator!
Are there any "starter level" PyPi projects the maintainer of which
might consider a novice collaborator? I would have assumed that
such an animal doesn't exist.

I do appreciate the advice.

cheers,
Alex
_______________________________________________
Tutor maillist - ***@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

[Emile van Sebille]

<snip>

Post by Alex Kleider

Post by Ben Finney
So, while it's not essential, I would heartily encourage you to pick
some of the PyPI projects you are enjoying, or want to improve, and
contact their maintainers with your offer to fix specific things. Work
with other Python programmers on a common code base, and watch your
skills broaden and improve!

How I wish I could find such collaborator!
Are there any "starter level" PyPi projects the maintainer of which
might consider a novice collaborator?

This looks like the list of identified issues:
https://bitbucket.org/pypa/pypi/issues

Browse through and see if anything looks interesting/doable.

Emile


_______________________________________________
Tutor maillist - ***@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

[Alex Kleider]

Post by Emile van Sebille
https://bitbucket.org/pypa/pypi/issues
Browse through and see if anything looks interesting/doable.
How about https://mail.python.org/mailman/listinfo/core-mentorship ?

Thank you Emile and Mark for your suggestions.
I fear that both are better suited to someone much more advanced than I!

_______________________________________________
Tutor maillist - ***@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

[Emile van Sebille]

Post by Alex Kleider

Post by Emile van Sebille
https://bitbucket.org/pypa/pypi/issues
Browse through and see if anything looks interesting/doable.
How about https://mail.python.org/mailman/listinfo/core-mentorship ?

Thank you Emile and Mark for your suggestions.
I fear that both are better suited to someone much more advanced than I!

You'd think so, but digging into any of the issues shown there and
simply trying to locate where a change may help resolve the issue is
itself a learning experience that'll do more for you taking your first
step then watching from the sidelines.

For example, take a look at http://bugs.python.org/issue25417 -- can you
figure out what file this change may impact? (Note -- I haven't looked)

Emile





_______________________________________________
Tutor maillist - ***@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

[Alex Kleider]

Post by Emile van Sebille

Post by Alex Kleider

Post by Emile van Sebille
https://bitbucket.org/pypa/pypi/issues
Browse through and see if anything looks interesting/doable.
How about https://mail.python.org/mailman/listinfo/core-mentorship ?

Thank you Emile and Mark for your suggestions.
I fear that both are better suited to someone much more advanced than I!

You'd think so, but digging into any of the issues shown there and
simply trying to locate where a change may help resolve the issue is
itself a learning experience that'll do more for you taking your first
step then watching from the sidelines.
For example, take a look at http://bugs.python.org/issue25417 -- can
you figure out what file this change may impact? (Note -- I haven't
looked)
Emile

Inspired by your encouragement (for which I'm grateful,) I had a look:
Here's the content of issue25417:
"""
The output of pydoc for Path.samefile currently reads

pathlib.Path.samefile = samefile(self, other_path)
Return whether `other_file` is the same or not as this file.
(as returned by os.path.samefile(file, other_file)).

It should arguably be something like

pathlib.Path.samefile = samefile(self, other_path)
Return whether `other_path` is the same or not as this file.
(as returned by os.path.samefile(file, other_file)).

or

pathlib.Path.samefile = samefile(self, other_path)
Return whether `other_path` is the same or not as this file.
(as returned by os.path.samefile(str(self), str(other_path))).
"""
The author suggests that the output A should in fact be more along the
lines of
B or C but to my reading A==B==C!

Am I missing something?

I did look at the source:
https://hg.python.org/cpython/file/3.5/Lib/pydoc.py
How would one download the source? (i.e. the equivalent of git clone
...)

Thanks,
ak
_______________________________________________
Tutor maillist - ***@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

[Alan Gauld]

Post by Alex Kleider
The output of pydoc for Path.samefile currently reads
pathlib.Path.samefile = samefile(self, other_path)
Return whether `other_file` is the same or not as this file.
pathlib.Path.samefile = samefile(self, other_path)
Return whether `other_path` is the same or not as this file.

Look closely at what the return value is called in each case.
And see how it compares to the names in the signature.
--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


_______________________________________________
Tutor maillist - ***@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

[Alex Kleider]

Post by Alan Gauld
Look closely at what the return value is called in each case.
And see how it compares to the names in the signature.

OOPS!
Should have run over them with diff _before_ posting rather than after.
Sorry about that.
Alex
_______________________________________________
Tutor maillist - ***@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

[Mark Lawrence]

Post by Alex Kleider

Post by Emile van Sebille
https://bitbucket.org/pypa/pypi/issues
Browse through and see if anything looks interesting/doable.
How about https://mail.python.org/mailman/listinfo/core-mentorship ?

Thank you Emile and Mark for your suggestions.
I fear that both are better suited to someone much more advanced than I!

To be frank what difference does it make? Whether a project on pypi or
core Python you're still going to be learning. Further the core
mentorship list is specifically there to assist. If you try and fail so
what? If you don't try you'll never know.

You might also like to know that by nature I'm so shy that it took me
months if not years to pluck up the courage to join in with any online
community. In a lot of ways I made a complete fool of myself. I
learned. So can you :)
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

_______________________________________________
Tutor maillist - ***@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

[Steven D'Aprano]

Post by Mark Lawrence
You might also like to know that by nature I'm so shy

Loading Image...


:-)

[Mark Lawrence]

Post by Alex Kleider

Post by Ben Finney

Post by Alex Kleider
I'm a long way from distributing packages!

You can keep working at your own pace, and that's good. But even better,
I would strongly recommend that you work with other people early and
frequently.
Programming is fundamentally a process of collaboration and
communication with other human programmers.
The habits you form alone can be eccentric and unhelpful, with no-one to
comment on strange habits you may be forming without even noticing until
they are too deeply entrenched to easily avoid.
Working frequently with others on the same code base will not only flush
out these oddities, but also help you to appreciate the consensus
decisions made in the past by the Python community as a whole.
So, while it's not essential, I would heartily encourage you to pick
some of the PyPI projects you are enjoying, or want to improve, and
contact their maintainers with your offer to fix specific things. Work
with other Python programmers on a common code base, and watch your
skills broaden and improve!

How I wish I could find such collaborator!
Are there any "starter level" PyPi projects the maintainer of which
might consider a novice collaborator? I would have assumed that
such an animal doesn't exist.
I do appreciate the advice.
cheers,
Alex

How about https://mail.python.org/mailman/listinfo/core-mentorship ?
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

_______________________________________________
Tutor maillist - ***@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor

[Steven D'Aprano]

Post by Mark Lawrence

Post by Alex Kleider
Are there any "starter level" PyPi projects the maintainer of which
might consider a novice collaborator? I would have assumed that
such an animal doesn't exist.
I do appreciate the advice.

How about https://mail.python.org/mailman/listinfo/core-mentorship ?

While core-mentorship is open to all, it is intended "for developers
interested in contributing to core Python development", which means that
the intent is to teach *experienced* programmers how to deal with the
specific indiosyncracies of the CPython code base and development
process. It's also quite low volume.

Have a read of:

https://docs.python.org/devguide/

particularly the FAQs and see if it looks like something you can handle.

I emphasis that you don't need core-mentorship in order to provide
patches for issues on the Python bug tracker. You could dip your toe in
the water by finding some easy issues and submitting patches, even just
doc patches:

http://bugs.python.org

Personally, what worked for me (although at the cost of many, many
hours over the years!) was reading and discussing other people's code,
here and on comp.lang.python (also available via email,
python-***@python.org), reading the standard library code to see how it
works, and especially reading the recipes in the Python Cookbook
(O'Reilly Books) and ActiveState:

http://code.activestate.com/recipes/langs/python/

although sometimes the quality is a bit mixed. Even the top-rated
recipes are not immune to this:

http://code.activestate.com/recipes/langs/python/top/

(although generally anything by Raymond Hettinger is almost guaranteed
to be amazing). For example, I just came across a top-rated recipe for
dependency injection which doesn't actually implement dependency
injection. (That's a good trick, since dependency injection is
*trivially* easy in Python.)

[Zachary Ware]

Post by Alex Kleider

Post by Ben Finney
Work
with other Python programmers on a common code base, and watch your
skills broaden and improve!

How I wish I could find such collaborator!
Are there any "starter level" PyPi projects the maintainer of which
might consider a novice collaborator? I would have assumed that
such an animal doesn't exist.

Most maintainers of open source software will gratefully accept
patches from anybody of any skill level (after proper review), though
there's always the possibility that a patch will be politely rejected
(if it's rejected impolitely, that's their problem, not yours). The
choice of project to contribute to is really up to you. Pick one that
you like and know fairly well, and preferably make a contribution that
will make some difference to you and your use of the project.

And if you can't find a PyPI project you'd like to contribute to, you
could always give a shot to working on CPython itself -- see
https://docs.python.org/devguide/ for a guide to getting started with
that.