Re: How to enter escape character in a positional string argument from the command line?
On Wed, 21 Dec 2022 at 15:28, Jach Feng wrote: > That's what I am taking this path under Windows now, the ultimate solution > before Windows has shell similar to bash:-) Technically, Windows DOES have a shell similar to bash. It's called bash. :) The trouble is, most people use cmd.exe instead. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: How to enter escape character in a positional string argument from the command line?
ery...@gmail.com 在 2022年12月20日 星期二中午12:35:52 [UTC+8] 的信中寫道: > On 12/19/22, Jach Feng wrote: > > > > That's really good for Linux user! How about Windows? > In CMD, typing the "^" escape character at the end of a line ignores > the newline and prompts for "more" input. If you press enter again, > you'll get another "more" prompt in which you can write the rest of > the command line. Command-line arguments are separated by spaces, so > you have to start the next line with a space if you want it to be a > new argument. Also, "^" is a literal character when it's in a > double-quoted string, which requires careful use of quotes. For > example: > > C:\>py -c "import sys; print(sys.orig_argv[3:])" spam^ > More? > More? eggs^ > More? > More? " and spam" > ['spam\n', 'eggs\n and spam'] > > The above is easier in PowerShell, which supports entering multiline > strings without having to escape the newline. The second-level prompt > is ">> ". For example: > > > py -c "import sys; print(sys.orig_argv[3:])" spam" > >> " eggs" > >> and spam" > ['spam\n', 'eggs\n and spam'] Thanks for the information. No idea Windows CMD can take such a trick to enter "\n" :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: How to enter escape character in a positional string argument from the command line?
Thomas Passin 在 2022年12月20日 星期二上午11:36:41 [UTC+8] 的信中寫道: > On 12/19/2022 9:24 PM, Jach Feng wrote: > > Mark Bourne 在 2022年12月20日 星期二凌晨4:49:13 [UTC+8] 的信中寫道: > >> Jach Feng wrote: > >>> I have a script using the argparse module. I want to enter the string > >>> "step\x0A" as one of its positional arguments. I expect this string has a > >>> length of 5, but it gives 8. Obviously the escape character didn't > >>> function correctly. How to do it? > >> That depends on the command-line shell you're calling your script from. > >> > >> In bash, you can include a newline in a quoted string: > >> ./your_script 'step > >> ' > >> (the closing quote is on the next line) > >> > >> Or if you want to do it on a single line (or use other escape > >> sequences), you can use e.g.: > >> ./your_script $'step\x0a' > >> (dollar sign before a single-quoted string which contains escape > >> sequences) > >> > >> -- > >> Mark. > > That's really good for Linux user! How about Windows? > One way is to process the argument after it gets into Python rather than > before. How hard that will be depends on how general you need the > argument to be. For your actual example, the argument comes into Python > as if it were > > arg1 = r"step\x0A" # or "step\\x0a" > > You can see if there is an "\\x": > > pos = arg1.find('\\x') # 4 > > Replace or use a regex to replace it: > > arg1_fixed = arg1.replace('\\x0A', '\n') > > Naturally, if "\\x0A" is only a special case and other combinations are > possible, you will need to figure out what you need and do some more > complicated processing. That's what I am taking this path under Windows now, the ultimate solution before Windows has shell similar to bash:-) -- https://mail.python.org/mailman/listinfo/python-list
Friendly Reminder
Greetings, all! I know our stress levels can be higher than normal around the holidays, but let's please be patient with each other. Both conversations and debates will be smoother if we assume other posters are asking/debating in good faith (at least, until proven otherwise). Happy Pythoning, and happy holidays! -- ~Ethan~ Moderator -- https://mail.python.org/mailman/listinfo/python-list
ContextVars in async context
Hi python people, hope this is the correct place to ask this! For a transactional async decorator I'm building I am using contextvars in order to know when a transaction is open in my current context. My understanding is that if given the following call stack A |- B | |- C |- D |- E If you set a context var at A with value 1, and then override it at B with value 2, then A, D and E will see value 1 and B and C will se value 2. Very similar (although a bit more manual) than dynamic scopes in common lisp. Now, back to the transactional decorator, from the little documentation there is about this I would imagine that something like this: @asynccontextmanager async def transactional( endpoint: _base.Endpoint, isolation_level: IsolationLevel = IsolationLevel.READ_COMMITTED, ): session = TRANSACTION_VAR.get() if not session: async with endpoint.session() as session, session.begin(): tok = TRANSACTION_VAR.set(session) try: await session.execute(text(f"SET TRANSACTION ISOLATION LEVEL {isolation_level.value}")) yield session finally: TRANSACTION_VAR.reset(tok) else: yield session should work automatically, and with some preliminary tests it seems it works, but, I don't understand why I need the manual reset. I thought just setting the variable would change it downstream the callstack and reset it when leaving the current context, as seen in the asyncio example in the documentation https://docs.python.org/3/library/contextvars.html#asyncio-support Now the final question, while the current setup works, when trying to use this as a context manager inside an async generator and then wrapping that with like `asyncio.wait_for`. To illustrate this: -- async def gen(): with transactional(): ... yield data g = gen() asyncio.wait_for(g.__anext__(), 1) # ValueError: was created in a different Context -- As far as I understand, that moves the awaitable into a new task and when trying to reset tok, it complains that tok was created in a different context. This is unfortunate as sometimes you want to be able to add a timeout using wait_for, particularly in tests. Is there anything I could do to my code to make it more reliable and robust when working with contextvars in an async context? Sorry for the wall of text, hope it's understandable Thanks in advance, -- Marce Coll ma...@dziban.net -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Installation hell
Personally I use winpython: https://winpython.github.io/ That have all the scientific packages already available. It can run without being installed and uses spyder as an IDE (for small projects it's ok). And, I can import pygame (even though I have not tested if everything works) in python 3.11. As I'm using it for science projects I find it perfect. -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Installation hell
On 12/20/2022 8:11 AM, Eryk Sun wrote: [snipped] I know we're not here to bash Windows, but... drive letters really need to just die already. I don't foresee drive-letter names getting phased out of Windows. And Windows itself is unlikely to get phased out as long as Microsoft continues to profit from it, as it has for the past 37 years. Microsoft won't get rid of them for backwards compatibility reasons, aside from the sheer difficulty of changing all that code. The company has always been very industrious about keeping backwards compatibility for Windows. I have compiled Delphi Windows GUI code from 2003 and even earlier that still runs, as one example. -- https://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Installation hell
On 12/19/22, Chris Angelico wrote: > On Tue, 20 Dec 2022 at 09:12, Thomas Passin wrote: > >> @echo off >> setlocal >> : Find effective drive for this file. >> set ed=%~d0 >> path %ed%\python37\Scripts;%ed%\python37;%PATH% For reference, in case not everyone on the list knows what "%~d0" means, the CMD shell supports extracting the drive (d), path (p), name (n), and extension (x) components of a path name that's stored in a parameter such as "%0". The full path (f) is resolved beforehand. For example: C:\Temp>set var=spam\eggs.py C:\Temp>for %c in (%var%) do @echo drive: "%~dc" drive: "C:" C:\Temp>for %c in (%var%) do @echo path: "%~pc" path: "\Temp\spam\" C:\Temp>for %c in (%var%) do @echo name: "%~nc" name: "eggs" C:\Temp>for %c in (%var%) do @echo extension: "%~xc" extension: ".py" C:\Temp>for %c in (%var%) do @echo full path: "%~dpnxc" full path: "C:\Temp\spam\eggs.py" C:\Temp>for %c in (%var%) do @echo full path: "%~fc" full path: "C:\Temp\spam\eggs.py" > So much easier to do on a Unix-like system, where you don't need to > concern yourself with "effective drive" and can simply use relative > paths. A relative path in the PATH environment variable would depend on the current working directory. Surely the added paths need to be absolute. However, Thomas didn't have to reference the drive explicitly. The expression "%~dp0" is the fully-qualified directory of the executing batch script, and an absolute path can reference its ancestor directories using ".." components. > I know we're not here to bash Windows, but... drive letters > really need to just die already. I don't foresee drive-letter names getting phased out of Windows. And Windows itself is unlikely to get phased out as long as Microsoft continues to profit from it, as it has for the past 37 years. The drive concept is deeply ingrained in the design of NT, the Windows API, shells, and applications. While assigning drive names "A:", "B:", and "D:" to "Z:" can be avoided, the system volume, i.e. drive "C:", still has to be accessed in the normal way, or using another one of its persistent names, such as r"\\?\BootPartition". The latter still uses the filesystem mount point on the root path of the device (e.g. "?\\BootPartition\\"), which you probably take issue with. That's a deeply ingrained aspect of Windows. Even mount points set on filesystem directories are actually bind mount points that ultimately resolve to the root path on the volume device (e.g. "\\Device\\HarddiskVolume4\\"). This differs from how regular mount points work on Unix, for which a path like "/dev/sda1/etc" is gibberish. Below I've outlined the underlying details of how logical drives (e.g. "C:"), UNC shares (e.g. r"\\server\share"), other device names, and filesystem mount points are implemented on NT. --- NT Device Names In contrast to Unix, NT is organized around an object namespace, not a root filesystem. Instances of many object types can be named. Some named object types also support a parse routine for paths in the namespace of an object (e.g. the configuration manager's registry "Key" type and the I/O manager's "Device" type). The object manager uses two object types to define the object namespace: Directory and Symbolic Link. Directory objects form the hierarchical tree. At the base of the tree is the anonymous root directory object (i.e. "\\"). A directory is implemented as a hashmap of named objects. A directory can be set as the shadow of another directory, creating a union directory for name lookups. Unless otherwise stated, the following discussion uses "directory" and "symlink" to refer to a directory object and a symbolic-link object, respectively -- not to a filesystem directory or filesystem symlink. A canonical NT device name (e.g. "C:", "PIPE", "UNC") is implemented in the object namespace as a symlink that targets the path of a real device object. The real device is typically in the r"\Device" directory. A canonical device name might be a persistent name for an enumerated device (e.g. "C:" -> r"\Device\HarddiskVolume2"). In some cases the real device name is persistent, but it's different from the canonical name (e.g. "PIPE" -> r"\Device\NamedPipe", or "UNC" -> r"\Device\Mup"). The symlink that implements a canonical device name is created either in the r"\Global??" directory or in a directory that's used for local device names in a given logon session (e.g. r"\Sessions\0\DosDevices\"). The global device directory generally contains system devices. Mapped drives and substitute drives typically use a local device directory, so users don't have to worry about conflicting drive assignments in these cases. The global device directory is the shadow of each local device directory, forming a union for name lookups. If the same device name is defined in both the local and global directories, the local device name takes precedence. However, each local device directory also contains