Guidance for Non-Python Developers to Contribute to the Python Codebase
Guidance for Non-Python Developers to Contribute to the Python Codebase
Objective:
Provide clear guidance for non-Python developers to understand and contribute to Python codebases in GitLab.
Description:
This epic aims to enable non-Python developers to contribute effectively to Python projects by providing them with structured resources. The focus will be on creating a Learning Group that uses https://exercism.org/tracks/python as a foundation for learning Python concepts and best practices. Additionally, resources for FastAPI and Pydantic will be included, allowing participants to build practical applications. The group will offer optional mentorship to support non-Python developers as they enhance their Python skills.
Key Deliverables:
- Onboarding Guide: A straightforward guide to help non-Python developers get started with Python in GitLab.
-
Learning Group: A collaborative group for studying the following:
- Basic Python syntax (https://exercism.org/tracks/python for Python concepts and best practices)
- FastAPI and Pydantic (to build practical Python apps)
- Mentorship Process: Ask experienced Python developers to optionally mentor new learners.
- Recorded Group Meetings: Screencasts explaining key concepts discussed in the group, covering Python, FastAPI, and Pydantic.
- Show closed items
- View on a roadmap
- Issuegitlab-org/gitlab#517452
- Issuegitlab-org/gitlab#517449
- Issue
- Issuegitlab-org/gitlab#506326
- IssueSet Up a Collaborative Learning Group for Non-Python Developers: Study Python, FastAPI, and PydanticClosedgitlab-org/gitlab#506327
- Issuegitlab-org/gitlab#506328
- Show labels
- Show closed items
Activity
@mhamda I want to share my experience of digging into Python after Ruby. I hope some of it would be useful to you. The biggest issues I got so far are:
- Testing. syntax of pytest is so much different from rspec, probably it's more aligned with minitest format but I'm not proficient enough in minitest to be 100% sure. And anyway, most of the people are daily rspec users, like me.
- Typing. Python is able to have 4 different typing approaches: Duck typing (same as Ruby - yay, implemented differently - nay), Goose typing, Static duck typing, Static typing. Ruby mostly relies on Duck typing and we don't use static type checkers (like Sorbet) in GitLab.
-
Inheritance. There are a lot of different things here:
- MULTIPLE INHERITANCE and its implications on method resolution.
- I run into an issue when trying to override initializer method for a class that inherits from Pydantic model. Turned out, I had to call
super
before initializing my object which for me was an unthinkable thing to do. - Mixings in Ruby are pretty unique and don't exist same way as in Python.
- I was confused by class/object attributes because there is no by default clear definition which is which like in Ruby. Or at least that's how I understand it so far.
Additionally, our AI Gateway project has clear test gaps so sometimes it's hard to contribute because of that.
And at last, for me sometimes it's hard to quickly write my code because we don't have or I don't know about python interactive console. I want a sandbox, same as we have with
rails c
which will load my environment and I can play with my classes.Thanks @brytannia for sharing your experience! This is definitely a huge help for anyone starting or making a similar switch.
For a
rails c
equivalent, I just googled something calledipython
, and it reminded me of thepdb
module (Python Debugger). Can't we combine both to achieve the same results asbinding.pry
andrails c
together?@mhamda
ipython
looks cool! We should try it and if it works, add that as recommended interactive console to GitLab guides.@mhamda during the last sync meeting last week we also discussed Jupiter notebooks. @eduardobonet suggested this tool as good instrument for the debug that can be used instead of console. We discussed that maybe onboarding guides should have be written in Jupiter or with usage of Jupiter. That would also be a good way to introduce Jupiter into the workflow.
Thanks, @brytannia, for the info! I'll definitely include this as well. Wrapping up the resources section is on my to-do list for this Friday.