Develop Reference

Print non-unicode subscript to Python console

I'm using Python 3.10 to implement a classical mechanics problem, and I want to print a message to the console asking the user to input the initial velocities. I am using x, y, and z as coordinates so ideally I want to denote the velocity components as vx, vy, and vz.
Originally I thought of using unicode subscirpts, but apparently they don't exist for y and z (as this other SO answer explains).
Of course I could just display (v_x, v_y, v_z), but I wanted it to look a bit more polished. Is there an easy way to display non-unicode subscripts in Python? Or otherwise, some very bare-bones UI package where I can have more freedom in formatting the text (like using LaTeX, or Markdown)?

No -
The terminal emulator (or command line) can only display characters, and does not allow for unlimited character transformations, as it is possible with text on a web browser or in a graphic interface.
ALthough there are special character sequences that can trigger special features such as foreground and background color, underline and blinking, those have to be implemented by the terminal emulator program itself, and appart from a subset, there is no universal code convention. The closest one, are what we usually call "ANSI escape code sequences" do not provide for a subscript or super-script convert - you can check the available codes on wikipedia - those will work in most terminal programs for Linux and MacOS and most custom terminal programas in windows (including the one called "terminal" in the microsoft store), but not on the default "cmd" app which cames pre-installed in windows.
(There is a Python package called "colorama" which tries to overcome this limitation to cmd, allowing cross-platform terminal programs able to display rich text - but it will filter out the codes for using fullcolor in terminal programs that accept them, so it is not always a good idea)
All that said, the tables as they are in the linked wikepdia article may be a bit confusing - but for shorten: "CSI" is the sequence "\x1b[" - where "\x1b"is the "ESC" character (decimal 27) , and "[" is a literal "open square bracket" char - the "SGR" sequence is"\x1b[<list-of-parameters-separated-by-;>m"` (again, "m" here is just the plain letter "m" closing a sequence of numeric codes that may change the way the terminal will display some text.
So, for front-face red text, you may want to do:
print("\x1b[31mThis text in red\x1b[39m normal color").
(note that the numbers are also plain decimal strings with the digits)
You will note that the code "74" is reserved for "subscript" code - however, I don't know of a terminal emulator which implements it.

How can I put giant writing in Python?

How could I make a word in giant text (for example “welcome” but giant)? I know that it's possible to change the console to make the font larger but I need it for just the word.

There are 2 ways to solve this problem
1 - Change the font in the python shell. Go to configure IDLE , go to the fonts tab and change the size value. Then apply the changes
2 - Using ASCII art. You can use ASCII art generators or use the python package pyfiglet(python version of figlet).
Example with pyfiglet
import pyfiglet
result = pyfiglet.figlet_format("Hello World")
print(result)
Pyfiglet also allows you to use many fonts , you can read their documentation for the everything else.
Hope this helps :)

Pycharm deletes quotation marks in paramenter field

I want to set a parameter for a python script by using the parameter field in PyCharm.
My config:
But the command in the Run console is:
python3 path_to_script.py '{app_id: picoballoon_network, dev_id: ferdinand_8c ... and so on
and not:
python3 path_to_script.py '{"app_id": "picoballoon_network", "dev_id": "ferdinand_8c" ... and so on
Basically, it deletes all " in the parameter.
Does anyone know how to turn this off?
My PyCharm version is:
PyCharm 2020.3.1 (Professional Edition)
Build #PY-203.6682.86, built on January 4, 2021
Runtime version: 11.0.9.1+11-b1145.37 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Windows 10 10.0

To avoid the quotation marks being deleted notice the rules to writing parameters that contain quotation marks.
Run/Debug Configuration: Python
Configuration tab
When specifying the script parameters, follow these rules:
Use spaces to separate individual script parameters.
Script parameters containing spaces should be delimited with double quotes, for example, some" "param or "some param".
If script parameter includes double quotes, escape the double quotes with backslashes, for example:
-s"main.snap_source_dirs=[\"pcomponents/src/main/python\"]" -s"http.cc_port=8189"
-s"backdoor.port=9189"
-s"main.metadata={\"location\": \"B\", \"language\": \"python\", \"platform\": \"unix\"}"
The case in the question would be a single parameter, lets apply the rules to the example:
'{"app_id": "picoballoon_network", "dev_id": "ferdinand_8c"'
Because it's a single parameter containing spaces it has to be surounded by quotation marks.
Since the content of the parameter also contains quotation marks they must be escaped using a backslash \. So applying the parameter formatting rules gives:
"'{\"app_id\": \"picoballoon_network\", \"dev_id\": \"ferdinand_8c\"}'"
(Side note): In the example the parameter was surrounded by Apostrophes, this may be unnecessary and will probably have to be stripped later in your Python code (the below example uses the strip method).
You can test it with this simple script:
import sys
import ast
your_dictionary = ast.literal_eval(sys.argv[1].strip("'"))
(Side note): Your example parameter is a string containing a Python dictionary, there are several ways to convert it, in the example I included the highest voted answer from this question: "Convert a String representation of a Dictionary to a dictionary?"
A screenshot showing the parameter and test code in use:

Get rid of unicode characters in VSCode Interactive Python Environment

I'm using VSCode Version: 1.46.1 on Mac OS Catalina. I'm using the built-in Python interactive terminal Python 3.7.4 Whenever I print strings, it shows up with unicode, making it difficult to read, like so:
\\u201cI like what we have.\\u201d It is quiet and there is somebody else in the room. I tell my dog that I need to go and he says, \\u201cjust alright.\\u201d ~~I am hungry.\\n\\n
I have tried every flavor of un-escaping escaped characters. See here:
Unescaping escaped characters in a string using Python 3.2
And
Using unicode character u201c
But to no avail. I think the problem lies in the encoding options built into VSCode itself, but I'm not sure how to modify that.

Maybe this page could provide some information for you.
"\u201c" and "\u201d" means “ and ”, but they will not work, they should be "\u201c" and "\u201d".

How do I handle Python unicode strings with null-bytes the 'right' way?

Question
It seems that PyWin32 is comfortable with giving null-terminated unicode strings as return values. I would like to deal with these strings the 'right' way.
Let's say I'm getting a string like: u'C:\\Users\\Guest\\MyFile.asy\x00\x00sy'. This appears to be a C-style null-terminated string hanging out in a Python unicode object. I want to trim this bad boy down to a regular ol' string of characters that I could, for example, display in a window title bar.
Is trimming the string off at the first null byte the right way to deal with it?
I didn't expect to get a return value like this, so I wonder if I'm missing something important about how Python, Win32, and unicode play together... or if this is just a PyWin32 bug.
Background
I'm using the Win32 file chooser function GetOpenFileNameW from the PyWin32 package. According to the documentation, this function returns a tuple containing the full filename path as a Python unicode object.
When I open the dialog with an existing path and filename set, I get a strange return value.
For example I had the default set to: C:\\Users\\Guest\\MyFileIsReallyReallyReallyAwesome.asy
In the dialog I changed the name to MyFile.asy and clicked save.
The full path part of the return value was: u'C:\Users\Guest\MyFile.asy\x00wesome.asy'`
I expected it to be: u'C:\\Users\\Guest\\MyFile.asy'
The function is returning a recycled buffer without trimming off the terminating bytes. Needless to say, the rest of my code wasn't set up for handling a C-style null-terminated string.
Demo Code
The following code demonstrates null-terminated string in return value from GetSaveFileNameW.
Directions: In the dialog change the filename to 'MyFile.asy' then click Save. Observe what is printed to the console. The output I get is u'C:\\Users\\Guest\\MyFile.asy\x00wesome.asy'.
import win32gui, win32con
if __name__ == "__main__":
initial_dir = 'C:\\Users\\Guest'
initial_file = 'MyFileIsReallyReallyReallyAwesome.asy'
filter_string = 'All Files\0*.*\0'
(filename, customfilter, flags) = \
win32gui.GetSaveFileNameW(InitialDir=initial_dir,
Flags=win32con.OFN_EXPLORER, File=initial_file,
DefExt='txt', Title="Save As", Filter=filter_string,
FilterIndex=0)
print repr(filename)
Note: If you don't shorten the filename enough (for example, if you try MyFileIsReally.asy) the string will be complete without a null byte.
Environment
Windows 7 Professional 64-bit (no service pack), Python 2.7.1, PyWin32 Build 216
UPDATE: PyWin32 Tracker Artifact
Based on the comments and answers I have received so far, this is likely a pywin32 bug so I filed a tracker artifact.
UPDATE 2: Fixed!
Mark Hammond reported in the tracker artifact that this is indeed a bug. A fix was checked in to rev f3fdaae5e93d, so hopefully that will make the next release.
I think Aleksi Torhamo's answer below is the best solution for versions of PyWin32 before the fix.

I'd say it's a bug. The right way to deal with it would probably be fixing pywin32, but in case you aren't feeling adventurous enough, just trim it.
You can get everything before the first '\x00' with filename.split('\x00', 1)[0].

This doesn't happen on the version of PyWin32/Windows/Python I tested; I don't get any nulls in the returned string even if it's very short. You might investigate if a newer version of one of the above fixes the bug.

ISTR that I had this issue some years ago, then I discovered that such Win32 filename-dialog-related functions return a sequence of 'filename1\0filename2\0...filenameN\0\0', while including possible garbage characters depending on the buffer that Windows allocated.
Now, you might prefer a list instead of the raw return value, but that would be a RFE, not a bug.
PS When I had this issue, I quite understood why one would expect GetOpenFileName to possibly return a list of filenames, while I couldn't imagine why GetSaveFileName would. Perhaps this is considered as API uniformity. Who am I to know, anyway?