Call for Participation: Python devroom @ FOSDEM 2026

2025-10-31 Thread Marc-Andre Lemburg 


 Call for Participation

We are happy to announce that we will again be running a*Python devroom 
at FOSDEM 2026*.


The next edition of FOSDEM will take place on January 31 and February 1 
2026, with the Python devroom currently scheduled for Saturday, January 
31, in the afternoon.


If you haven’t heard about FOSDEM before or are looking for more 
information, you can visit the official website athttps://www.fosdem.org/.


As usual, we are looking for multiple Pythonistas to help us shape the 
devroom schedule. We are now open to receiving your proposals ! With 
over 8500 participants, FOSDEM is the perfect place to share your story 
and meet fellow Python enthusiasts.


Good luck to everyone applying. We’re looking forward to meeting you all 
at FOSDEM 2026 !



   About FOSDEM

 * Official FOSDEM 2026 website 
 * FOSDEM Code of Conduct

   

FOSDEM is a free and non-commercial event organized by the community for 
the community.


The goal is to provide free and open source software developers and 
communities a place to meet to:


 * get in touch with other developers and projects;
 * be informed about the latest developments in the free software world;
 * be informed about the latest developments in the open source world;
 * attend interesting talks and presentations on various topics by
   project leaders and contributors;
 * promote the development and benefits of free software and open
   source solutions.

Participation and attendance is totally free, though the FOSDEM 
organizers gratefully accept donations and sponsorship.



   Essential Information

The Python devroom is currently scheduled to be held on January 31 in 
the afternoon.


 * *Submission deadline: December 1 2025*
 * There will be no extension of the deadline
 * Announcement of the schedule: December 15 2025
 * The reference time is Brussels local lime (CET).
 * Talk format: 25 minutes presentation, including Q&A, if any.
   In-person only.
 * Live streaming of the talks will be available.


   Speaker Guidelines

Please submit your talk proposals using theCFP submission page 
.


 * FOSDEM is using a self-hosted Pretalx installation for managing talk
   submissions. You will need to create an account, if you don’t
   already have one.
 * In the Submission notes field, please also confirm that if your talk
   is accepted, you will be able to attend FOSDEM and deliver your
   presentation. We will not consider proposals from prospective
   speakers who are unsure whether they will be able to secure funds
   for travel and lodging to attend FOSDEM. Sadly, we are not able to
   offer travel funding for prospective speakers.
 * You will need to select the "*Python*" track
 * Keep in mind presentations must be related to Python. All
   presentations will be recorded and made available under the Creative
   Commons licenses CC-BY-SA or CC-BY. Captured footage will later be
   shared online using the FOSDEM archives. By submitting you also
   agree to these terms.


   List of Desirable Topics

We'd like to make the devroom topics as diverse as possible, so we are 
looking to offer a mixture of presentations, short tutorials, demos, 
live coding, etc. This year, the python devroom will focus both on the 
language itself (new developments, tools and best practices) and its 
broader applications in education, data science and emerging fields. 
Examples of these include the following:


 * How to start as a Python developer
 * Code infrastructure & starting new projects, e.g. with
   community-backed tools like uv or pixi
 * Testing/CI best practices; apps or libraries
 * Performant Python code
 * Making use of 3.13t (free-threaded Python with no GIL lock)
 * Sustainable Python code
 * How to do/my cool thing/in Python
 * Python as a tool for education
 * How to contribute to the Python language
 * Python 3.13, 3.14, 3.15: What's new?
 * Python in data analysis & visualization tools
 * Python in AI & machine learning
 * Reproducibility and best-practices (e.g. lockfile usage)
 * The scientific Python ecosystem
 * How to write secure Python code
 * Python governance structure
 * Python success stories
 * Interoperability and cross-language bindings for Python
 * New Python projects


   Volunteers

We will also call for volunteers to help us run the event and help us 
with the devroom operation. Please email the organizers, in case you are 
interested.



   Organizers

You can reach out directly to the organizers, if you have a specific 
request or question:


 * Marc-André Lemburg: mal+fosdem [at] egenix.com
 * Rosie Wood: rwood [at] turing.ac.uk

--
Marc-Andre Lemburg
--
https://mail.python.org/mailman3//lists/python-list.python.org

Re: argsparse: allowing --version without mandatory options

2025-10-31 Thread Daniel Sommers 
On 2025-10-31 at 09:09:08 +,
Anders Munch  wrote:

> From: [email protected] <[email protected]>:
> > Don't take this the wrong way, but what, exactly, is a mandatory option?
> 
> It's a named argument.

Okay.

> Positional arguments intermixed with options can get confusing. When you see 
>  aprogram.py --a --b c --d --e
> is 'c' the value for --b, or is it a positional argument? Hard to tell.
> Using options syntax for everything makes it clearer, because everything has 
> a name:
>  aprogram.py --a --b --c c --d --e

Is 'c' the value for --c, or is it a positional argument?  Hard to tell.

Perhaps it would be easier to tell with non-degenerate names.

Perhaps not.

Or maybe if I understood all the use cases for aprogram.py.  But if I
truly understood the all use cases, and the use case I was using in
particular, then I would understand the options and arguments, named,
unnamed, optional, or mandatory.

APIs are easy to create, and hard to get right.
-- 
https://mail.python.org/mailman3//lists/python-list.python.org

Re: argsparse: allowing --version without mandatory options

2025-10-31 Thread Anders Munch 
From: [email protected] <[email protected]>:
> Don't take this the wrong way, but what, exactly, is a mandatory option?

It's a named argument.
Positional arguments intermixed with options can get confusing. When you see 
 aprogram.py --a --b c --d --e
is 'c' the value for --b, or is it a positional argument? Hard to tell.
Using options syntax for everything makes it clearer, because everything has a 
name:
 aprogram.py --a --b --c c --d --e

Whether an argument is named and whether it's optional are orthogonal traits.
Positional arguments can be optional as well, and named arguments ("options") 
can be mandatory.

regards, Anders
-- 
https://mail.python.org/mailman3//lists/python-list.python.org