Our team is considering switching to Python for the upcoming 2024 season. Although we think this could bring a lot of new, interesting capabilities, we aren’t able to talk to teams who have used Python to code their bots. Our team has always coded in Java and we haven’t yet been able to start experimenting with Python. Is it too close to the season to code with Python, and are there any major cons with Python we need to consider before going all-in?
Thank you in advance!
1 Like
Just as I wouldn’t want to go into build season with an unproven drivetrain, I also wouldn’t want to do so with an unproven code build.
And with Python you will be in a much smaller community than Java, so assistance and “cool new things” will very likely be much more limited.
5 Likes
There are a lot of examples that you can play around with to decide whether python makes sense for you: GitHub - robotpy/examples: Repository of RobotPy example projects
You can also ask ChatGPT to translate your current Java code into Python to see what it might look like (I’ve done this for small things before, it’s pretty neat!). It’s not going to be 100%, but it’ll be close.
4 Likes
What new capabilities do you think it could bring? IMO, seeing as Python and Java are both basically complete programming languages, I wouldn’t expect “new capabilities” in Python. You may have a benefit of not requiring code compilation (but would you want it, anyway?), but you also get new bugs unfamiliar to many teams, lack of compatibility with other toolkits, no support for concurrent execution, etc.
Personally, I’d only go with Python if I (only) had a strong Python programmer, or my team was tied to a high school that focused on teaching Python, etc. Don’t get me wrong, I’d like to see Python advance … I just think it’s still too far outside the mainstream right now, and I think the potential issues outweigh the benefits so much that, for the competition season, I’d prefer some other team to willing chose to be the guinea pigs. (Off-season work, exploring a Python port of the previous season’s bot, etc., would be an entirely different story)
7 Likes
If you happen to have issues with your python code at a condition, there’ll probably be a lot less help available for you. I like the initiative of making a python a supported language for FRC, but I agree with other posters that it’s not too main stream yet.
3 Likes
My team, 3164, has had a ton of success with Python. Everything that works in Java works in Python (maybe except for the Shuffleboard class, but last I checked was two years ago). So personally, I’d say go for it.
Keep in mind, most other teams’ stuff is programmed in Java, so you won’t be able to use Advantage kit, etc. Plus, possibly less support a competitions. With that said, you should have a good reason to switch over. I’m excited to see the number of Python teams (hopefully) grow!
4 Likes
Is there anything stopping you from trying it out before making a decision on what to use next season? Try writing a simple tank drive robot and see how you like it compared to Java.
4 Likes
FWIW, people have been the guinea pigs for over a decade now, and for the most part it just works. 
5 Likes
A sample point: we’re probably gonna switch to python.
The consensus from every student and mentor involved so far - “Why didn’t we do this years ago?”
Background info: Caterpillar extensively uses python internally in the embedded space for tools and scripting, so most mentors have some experience with it. Additionally, most high schools in the area have a PLTW or similar course which is done in python.
So far - https://photos.app.goo.gl/cyXaR24dMaFizmvV7 - we’ve got a pathplanned autonomous swerve base. Needs some tuning, but it’s functional.
Development experience has been nothing short of wonderful. Students have gotten tank drive up and running from scratch in under an hour, having never touched Robotpy before.
But, echoing John - if you can’t get your current bot reprogrammed prior to the start of build season, wait till April to pull the trigger.
5 Likes
If you’re more familiar with Python than Java, use Python. I think too much is made of language choice in FRC; with the exception of LabView they’re all viable choices.
It’s worth noting that, as far as I know, Python doesn’t yet have a full command-based implementation. This may or may not matter to you; there are definitely other ways of structuring robot code that are totally viable.
5 Likes
Do you know which command-based features are missing?
1 Like
We have used Python for years, and it is an incredibly well-supported language. If you have anyone on your team who is well-versed in both Pyton and Java, support at events is not an issue. If you need help, and cannot find anyone to help you in Python, being able to ask how would you do it in Java should be enough to get you the help you need. The only reason we are currently using Java is the sheer number of tutorials that walk students from 0 knowledge to full programming. The best, which I keep singing the praises for, is 6814’s 0 to Autonomous. If you have the ability to walk new programmers through the steps, Python can be just as good. The other thing to be mindful of with Python is that, at the moment. You need to manually install (and keep updated) the Python libraries. That does make an otherwise easier programming language a bit more difficult (especially if you are working with team members who are remote).
2 Likes
That was true a few years ago, I believe the current commands implementation now covers 98%+ of the existing API.
For 2024, we will be moving back to a pure python implementation of commands, which will make it a lot easier for users to debug their interactions with the command framework.
6 Likes
It’s not that features were missing, it’s that the approach of wrapping WPILibC commands is not great given how particular WPILibC Command-based is about object ownership.
The pure python rewrite should solve the problem.
2 Likes
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.