richpl
Feature questions
I’ve been doing a lot of recent work on PyBasic because I’m preparing to deploy it on a hardware device for blind users. Some fixes were required for accessibility reasons, especially related to how negative numbers are handled.
In braille, formatting and symbol placement can change how code is interpreted. Something as small as where the minus sign appears can affect how readable the code is on a braille display. Because of this, fixing number handling was not optional before moving forward.
As a result, I’ve begun adding features that existed in older BASIC systems (specifically from the Braille 'N Speak devices in the 1990s), as well as a few additions that map cleanly onto Python behavior today.
Before continuing, I wanted to ask: Would the PyBasic project want these features included, or should I keep them only in my fork?
If they are wanted, I would much prefer to contribute them upstream instead of maintaining them separately.
About my fork (context)
My fork currently:
Runs more like Python (basic -i for interactive mode, basic to run files)
Is managed using PDM
Has internal restructuring
Focuses on accessibility and device deployment
The features I am intersted in know if you want in the master branch are:
- Expand DIM to support up to 10 dimensions
Original BNS BASIC supported up to 10 dimensions in DIM. PyBasic currently limits this to 3.
Are you open to having that default limit increased in the master branch?
Example: 10 DIM A(10,10,10,10,10) 20 A(1,1,1,1,1) = 42 30 PRINT A(1,1,1,1,1)
Current behavior only allows:
10 DIM A(10,10,10)
- Traditional BASIC error handling (ON ERROR)
Older BASIC (including BNS) supported structured error handling:
Example: 10 ON ERROR GOTO 100 20 PRINT 10 / 0 30 PRINT "This will not run" 40 END
100 PRINT "An error occurred" 110 RESUME NEXT
Would you want support for:
ON ERROR GOTO
RESUME
RESUME NEXT
…in addition to the current Python-style exceptions? and already supported errors in PyBasic. Note that this would set an error code when on error is fired. From a list of error codes.
- Raw keyboard input (GET and INKEY$)
Although PyBasic aims to be platform-agnostic, Python itself supports cross-platform raw keyboard input (Windows, macOS, Linux).
I plan to implement this in a way that:
Can be disabled with a constant
Fails cleanly if unsupported on a platform
GET (Blocking single-key read) 10 PRINT "Press any key:" 20 GET K$ 30 PRINT "You pressed "; K$
INKEY$ (Non-blocking key polling) 10 PRINT "Press any key to continue" 20 K$ = INKEY$ 30 IF K$ = "" THEN GOTO 20 40 PRINT "Key pressed was "; K$
- SLEEP (pause in seconds)
This maps cleanly to time.sleep() in Python.
10 PRINT "Waiting..." 20 SLEEP 3 30 PRINT "Done"
Supports integer or floating-point seconds.
- USLEEP / UPAUSE / PAUSE (sub-second timing)
Higher-resolution timing for animations, polling, or precise delays.
Final naming is flexible — this section is really about whether fine-grained timing support is something PyBasic wants.
Microsecond delay (USLEEP) 10 PRINT "Half second pause" 20 USLEEP 500000 30 PRINT "Done"
Fractional-second pause (UPAUSE) 10 UPAUSE 0.25
Milliseconds (if PAUSE is used that way) 10 PAUSE 250
Final question
I will be adding these features to my fork regardless, but I would strongly prefer to contribute them upstream if they are wanted. If one or more of these are wanted just comment here and I can add them as issues and fix themas pull requests in the near future.
To be clear.
Would PyBasic like to support:
Up to 10-dimension DIM
ON ERROR handling
GET and INKEY$
SLEEP / pause
USLEEP / UPAUSE
If so, I would be happy to submit PRs rather than keeping these changes private.
Thank you for your time, and thank you for maintaining PyBasic.
Regarding SLEEP, PAUSE, USLEEP, and UPAUSE, why not simplify to a single SLEEP command that matches the values of Python's time.sleep() or asyncio.sleep()?
SLEEP 5 REM 5 seconds
SLEEP 0.5 REM half a second
Again the details of implementation is for later when one of us adds it. I don’t disagree with this however having the two types is more simple for people to understand and basic is more about simplicity than low verbosity. It is rather simple to add and the fork I have I am using two functions because I felt it was easier to understand. I might be wrong though and I might even change my fork before we go live.
From: Christian Clauss @.> Sent: Sunday, November 30, 2025 7:10 AM To: richpl/PyBasic @.> Cc: krperry @.>; Mention @.> Subject: Re: [richpl/PyBasic] Feature questions (Issue #91)
cclauss left a comment (richpl/PyBasic#91) https://github.com/richpl/PyBasic/issues/91#issuecomment-3592498576
Regarding SLEEP, PAUSE, USLEEP, and UPAUSE, why not simplify to a single SLEEP command that matches the values of Python's https://docs.python.org/3/library/time.html#time.sleep time.sleep() or https://docs.python.org/3/library/asyncio.html#asyncio.sleep asyncio.sleep()?
SLEEP 5 REM 5 seconds SLEEP 0.5 REM half a second
— Reply to this email directly, view it on GitHub https://github.com/richpl/PyBasic/issues/91#issuecomment-3592498576 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AB5J6YMJ5H2IZH657MXVWIT37LNDLAVCNFSM6AAAAACNROSYEOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKOJSGQ4TQNJXGY . You are receiving this because you were mentioned.Message ID: @.***>
I just realized that PyBasic does have on goto and on gosub so I removed that as a feature I need. The reason I added that is my on goto was erroring because PyBasic doesn't support errors with on goto and on gosub. That is OK because our error handling is different. I am only mentioning this if people notice I removed that comment to this feature question issue.I just noticed that PyBasic does already have on goto and on gosub so ignore my com
Hi @krperry, apologies for the long delay in replying. I don't have a lot of time these days so it can be a while before I get around to things. There's a lot in your suggestions, I guess I'll answer but outlining the main principles I'm trying to adhere to in PyBasic:
-
Portability. Ideally, if a machine can run a Python interpreter, then (memory and storage notwithstanding) it should be able to run PyBasic and hence any BASIC program that is PyBasic compatible. Therefore, I've resisted pull requests to add machine specific features, for example, BASIC dialects containing features that are platform specific. The only exception I'd be prepared to make (which might be where you are coming from) is the addition of features to make PyBasic more accessible. This is obviously a good thing and something I suspect wasn't at the forefront of any pioneer's thinking in the 1970s. My only caveat is that I'd like to make it clear in the documentation that some accessibility features may not run on all platforms.
-
Remaining true to classic BASIC dialects. I'm happy to accept additions or changes (e.g. arrays with more than three dimensions) as long as there is precedent for those features within some dialect of BASIC that has previously appeared and isn't completely obscure (i.e. not a dialect that was developed by some guy back in the 1980s that didn't get any traction). This also means only adding features that were found in unstructured, line numbered BASIC. I'm not trying to recreate more modern, structured versions or Visual BASIC. This principle is also designed to stop PyBasic becoming cluttered with lots ad hoc extensions developed by people who had a clever idea one day.
With those principles in mind, I'm happy for you to continue contributing to the main branch. I welcome it in fact, as I find your work is thorough, well thought through, and you pay attention to keeping the documentation up to date!
The BASIC I am replacing is an off-brand mix of Apple BASIC and GW-BASIC. That is why I originally wanted arrays to support up to 10 dimensions. From about 1981 to 1988, this system supported 10 dimensions, so I was trying to stay true to that behavior.
That said, the code I submitted in the pull request actually allows any number of dimensions, as long as memory allows. I recently did a code review with AI on the BASIC code, and it pointed out a few areas that could be improved for smaller platforms and to better avoid memory issues. I plan to clean those up, so you may see additional pull requests focused on refactoring and safety improvements.
I agree with everything you said about portability and staying true to classic BASIC.
As for accessibility, I agree there is no real need for accessibility features to be built directly into PyBasic. The device I am building for requires braille, music, and speech, but those features can live on my branch without being added to PyBasic itself. That keeps PyBasic clean and portable.
The one thing this BASIC seems to be missing is raw input. I suspect that is because truly portable raw input is hard to do. I briefly considered some kind of input source plug-in, but that may not be worth the added complexity. It is unfortunate, though, because without raw input it is difficult to support arcade-style input. I need to think more about this in light of what you said.
Finally, the pull request I submitted should not conflict with your principles. It does not force arrays to 10 dimensions; it simply allows them to go to 10 or higher when memory permits.
From: richpl @.> Sent: Friday, December 19, 2025 2:39 PM To: richpl/PyBasic @.> Cc: krperry @.>; Mention @.> Subject: Re: [richpl/PyBasic] Feature questions (Issue #91)
richpl left a comment (richpl/PyBasic#91) https://github.com/richpl/PyBasic/issues/91#issuecomment-3676302125
Hi @krperry https://github.com/krperry , apologies for the long delay in replying. I don't have a lot of time these days so it can be a while before I get around to things. There's a lot in your suggestions, I guess I'll answer but outlining the main principles I'm trying to adhere to in PyBasic:
- Portability. Ideally, if a machine can run a Python interpreter, then (memory and storage notwithstanding) it should be able to run PyBasic and hence any BASIC program that is PyBasic compatible. Therefore, I've resisted pull requests to add machine specific features, for example, BASIC dialects containing features that are platform specific. The only exception I'd be prepared to make (which might be where you are coming from) is the addition of features to make PyBasic more accessible. This is obviously a good thing and something I suspect wasn't at the forefront of any pioneer's thinking in the 1970s. My only caveat is that I'd like to make it clear in the documentation that some accessibility features may not run on all platforms.
- Remaining true to classic BASIC dialects. I'm happy to accept additions or changes (e.g. arrays with more than three dimensions) as long as there is precedent for those features within some dialect of BASIC that has previously appeared and isn't completely obscure (i.e. not a dialect that was developed by some guy back in the 1980s that didn't get any traction). This also means only adding features that were found in unstructured, line numbered BASIC. I'm not trying to recreate more modern, structured versions or Visual BASIC. This principle is also designed to stop PyBasic becoming cluttered with lots ad hoc extensions developed by people who had a clever idea one day.
With those principles in mind, I'm happy for you to continue contributing to the main branch. I welcome it in fact, as I find your work is thorough, well thought through, and you pay attention to keeping the documentation up to date!
— Reply to this email directly, view it on GitHub https://github.com/richpl/PyBasic/issues/91#issuecomment-3676302125 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AB5J6YJZMH2QQQEA4IO5CCL4CRH45AVCNFSM6AAAAACNROSYEOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMNZWGMYDEMJSGU . You are receiving this because you were mentioned.Message ID: @.***>