Re: Is sys.executable not supposed to follow symlinks?
On 7/26/20, Bolun Thompson wrote: > In the sys.executable documentation ( > https://docs.python.org/3/library/sys.html#sys.executable), they don't > specify if it follows symlinks. From my limited testing, it does not. Is > this behavior guaranteed? In Unix, the interpreter resolves the target of sys.executable if it's a symlink in order to set the prefix directory, which is the base path for the standard library (i.e. "prefix/lib/pythonX.Y"). For a contrived example, compare using a symlink vs. a hardlink when the landmark "lib/python3.8/os.py" exists relative to the directory of the link. With a hardlink, it will accept the link directory as the prefix path, without falling back on the configured default prefix path (e.g. "/usr"), and the interpreter will fail to start. But with a symlink, in an strace you can see the executable getting resolved at the start via readlink(), and it will try setting the prefix to "/usr" and eventually find the landmark "/usr/lib/python3.8/os.py". In Windows, for Python 3.8 finding python38.dll and vcruntime140.dll reliably depends on their being beside the executable in the application directory. The loader does not resolve symlinks, and depending on PATH to find python38.dll is unreliable (e.g. it could find an x86 32-bit DLL when it needs an x64 DLL). For argument's sake, it's possible to link python.exe, python38.dll, python3.dll, and vcruntime140.dll all together in the target directory (as would be done in a venv that uses symlinks). In this case, if you repeat the above contrived example by creating the landmark r"Lib\os.py" relative to the directory of the symlinks, then the interpreter will fail to start. There's no reason stopping Python in Windows from resolving the target of a symlink'd executable when searching for the prefix directory, but it's not a pressing concern since using symlinks is relatively uncommon in Windows. A virtual environment may use symlinks, but pyvenv.cfg is used to find the standard library in that case. Also, other than the above contrived example, an installed Python has a default "PythonPath" set in its registry key, which it uses when the prefix directory isn't found otherwise. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is sys.executable not supposed to follow symlinks?
On Mon, Jul 27, 2020 at 8:04 AM Bolun Thompson wrote: > > In the sys.executable documentation ( > https://docs.python.org/3/library/sys.html#sys.executable), they don't > specify if it follows symlinks. From my limited testing, it does not. Is > this behavior guaranteed? I don't know about guaranteed, but it's certainly the behaviour I would expect. Recognizing the invocation executable is important to a lot of commands that behave differently based on that, for instance with the detection of a virtual environment. The fact that the executable might be a symlink is irrelevant. If you want to follow symlinks, you can always readlink on it. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Is sys.executable not supposed to follow symlinks?
In the sys.executable documentation ( https://docs.python.org/3/library/sys.html#sys.executable), they don't specify if it follows symlinks. From my limited testing, it does not. Is this behavior guaranteed? -- https://mail.python.org/mailman/listinfo/python-list
Re: Symlinks already present
On 27/07/2020 00:56, Termoregolato wrote: There is any way to check if a directory is already symlinked, without controlling every symlink viewing the link? That is a bit time consuming, due I've two or three directory that can have a new symlink, but I've to check on a list of 20-3 symlinks to delete it and avoid duplicates... Please review "os — Miscellaneous operating system interfaces" (https://docs.python.org/3/library/os.html) - in particular os.stat() - and thus os.stat_result, and given what you appear to be doing, possibly os.scandir() and os.DirEntry. I built a test: dir1 -- dir-link = symlink to dir2 dir2 -- real-file >>> os.stat( "dir2", follow_symlinks=True ) os.stat_result(st_mode=16893, st_ino=2345143, st_dev=64773, st_nlink=2, st_uid=1000, st_gid=1000, st_size=4096, st_atime=1595793224, st_mtime=1595793223, st_ctime=1595793223) >>> os.stat( "dir1/dir-link", follow_symlinks=True ) os.stat_result(st_mode=16893, st_ino=2345143, st_dev=64773, st_nlink=2, st_uid=1000, st_gid=1000, st_size=4096, st_atime=1595793224, st_mtime=1595793223, st_ctime=1595793223) >>> os.stat( "dir1/dir-link", follow_symlinks=False ) os.stat_result(st_mode=41471, st_ino=2345146, st_dev=64773, st_nlink=1, st_uid=1000, st_gid=1000, st_size=7, st_atime=1595793558, st_mtime=1595793558, st_ctime=1595793558) NB st_size Size of the file in bytes, if it is a regular file or a symbolic link. The size of a symbolic link is the length of the pathname it contains, without a terminating null byte. Thus, compare the results of the two calls to detect a difference. -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
RE: Dowloading package dependencies from locked down machine
I think your best bet is to make a formal business case to your IT people and explain what's in it for them. If they hold all the cards you defeat them at your peril.Mike -- https://mail.python.org/mailman/listinfo/python-list
How to cast to a type WAS: How to limit *length* of PrettyPrinter
I was a bit unhappy with my convert function:
def convert(typ,obj):
newobj = typ.__new__(typ,obj)
newobj.__init__(obj)
return newobj
because it called __xxx__ functions, which are supposed to be internal. It
was also a surprise that __new__ ignores the obj for (mutable) lists, but
__init__ ignores the obj for (immutable) tuples (rather than throwing an
exception).
Reading the reference manual, I see that I was right to be unhappy, because
the straightforward way is:
def convert(typ,obj): return typ(obj)
and it works in other cases as well, e.g., type(3.4)(True) and
type({})((i,i) for i in range(0,2)).
--
https://mail.python.org/mailman/listinfo/python-list
Support both asyncio and synchronous callers
Hi. I'm the author of Stem, Tor's python library [1]. Recently we
migrated to asyncio, but desire to still be usable by synchronous
callers.
We wrote a mixin [2][3] that transparently makes any class usable by
both asyncio and synchronous callers...
==
import asyncio
import stem.util.asyncio
class Example(stem.util.asyncio.Synchronous):
async def hello(self):
return 'hello'
def sync_demo():
instance = Example()
print('%s from a synchronous context' % instance.hello())
instance.stop()
async def async_demo():
instance = Example()
print('%s from an asynchronous context' % await instance.hello())
instance.stop()
sync_demo()
asyncio.run(async_demo())
==
Is there a better way to approach this?
Our wider ecosystem seem to be forking networking libraries into
sync/async variants, with requests [4] and AIOHTTP [5] as the most
prominent. Are there any libraries out there that demonstrate good
support for both kinds of callers without duplicating their API?
Thanks! -Damian
PS. I apologize if this email gets duplicated. Initially I used a
different email address which Mailman seemed to decline.
[1] https://stem.torproject.org/
[2] https://gitweb.torproject.org/stem.git/tree/stem/util/asyncio.py
[3] https://gitweb.torproject.org/stem.git/tree/test/unit/util/asyncio.py
[4] https://requests.readthedocs.io/en/master/
[5] https://docs.aiohttp.org/en/latest/index.html
--
https://mail.python.org/mailman/listinfo/python-list
Re: Symlinks already present
Il 26/07/20 15:19, Barry ha scritto: No. None. Sob :-) But thanks for confirm. Don’t you have control of the code that is adding the symlinks? No, so I must traverse the directories where symlinks are, to deduplicate them. There are some modes to minimize the work, but that way could be the simplest. -- https://mail.python.org/mailman/listinfo/python-list
Re: Symlinks already present
> On 26 Jul 2020, at 14:03, Termoregolato wrote: > > There is any way to check if a directory is already symlinked, No. None. > without controlling every symlink viewing the link? That is a bit time > consuming, due I've two or three directory that can have a new symlink, but > I've to check on a list of 20-3 symlinks to delete it and avoid > duplicates... Don’t you have control of the code that is adding the symlinks? Barry > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Symlinks already present
There is any way to check if a directory is already symlinked, without controlling every symlink viewing the link? That is a bit time consuming, due I've two or three directory that can have a new symlink, but I've to check on a list of 20-3 symlinks to delete it and avoid duplicates... -- https://mail.python.org/mailman/listinfo/python-list
Dowloading package dependencies from locked down machine
At work my only Internet access is via a locked-down PC. The IT department are not willing to install Python on it [1]. Ideally I would download packages and their dependencies from PyPi using "pip download" at the command line. Any better solutions than downloading the package in a browser, finding its dependencies manually, downloading these and so on recursively? My dream solution would be for PyPi to provide a link to a zip file that bundled up a package and its dependencies, but I realise that this is probably a very niche requirement. - Andrew [1] Apparently they think installing Python would be incompatible with their Cyber Essentials Plus security accreditation, although it's apparently fine to have Microsoft Office 365 with a build in VBA interpreter! -- https://mail.python.org/mailman/listinfo/python-list
