[issue15533] subprocess.Popen(cwd) documentation: Posix vs Windows

[ban]

ban  added the comment:

>> "In particular, the function looks for executable (or for the 
>> first item in args) relative to cwd if the executable path is 
>> a relative path." 
>
> For POSIX, this should be stated as a "relative path without a slash in
> it" or a "relative path without a directory in it". An unqualified
> filename is a relative path that won't be resolved against `cwd`,
> unless there's a "." entry in PATH.

While I don't understand the wording proposed (that seem backwards to me?), I 
do think it would be important to fix this.

I just got puzzled and spent some effort writing a workaround *not to look in 
cwd* for a bare command name, before I got so skeptical I actually tried 
empirically what Python would do -- and see the behavior was sensible and `cwd` 
was taken into account *only if the executable had a path component in it*.

Any other behavior is annoying IMO as it means using a `cwd` *requires* one to 
pass in an absolute path to the executable not to risk running an unexpected 
executable, which basically makes support for looking up executable in the 
system PATH unusable if using a `cwd`.
It would also be somewhat inconsistent with the idea that `cwd` only *changes* 
the current directory prior to execution, as it would suggest the behavior is 
not the same when using `cwd=None` and `cwd=os.getcwd()`.

So I'd suggest amending the wording in some way, maybe something like
"In particular, the function looks for executable (or for the first item in 
args) relative to cwd if the executable has an explicit relative path."
or something like that, possibly even dropping in an example.
The problem with the current wording is that usually an unqualified name *is* a 
relative path, whereas here one should somehow understand that it means "if it 
has a path component and that path component is relative", or the more 
down-to-earthy "if the executable starts with './' or '../'".

--
nosy: +ban

___
Python tracker 
<https://bugs.python.org/issue15533>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40772] module 'resource' has no attribute 'RLIMIT_VMEM'

[Titusz Ban]

New submission from Titusz Ban :

While trying to limit the virtual memory used by a process, using

import resource
MAX_VIRTUAL_MEMORY = 1 * 1024 * 1024
resource.setrlimit(resource.RLIMIT_VMEM, (MAX_VIRTUAL_MEMORY, 
MAX_VIRTUAL_MEMORY))

The following error occurred:

AttributeError: module 'resource' has no attribute 'RLIMIT_VMEM'

This is on Ubuntu 16.04 running inside WSL. on Python 3.8.2.

--
messages: 369902
nosy: Titusz Ban
priority: normal
severity: normal
status: open
title: module 'resource' has no attribute 'RLIMIT_VMEM'
type: crash
versions: Python 3.8

___
Python tracker 
<https://bugs.python.org/issue40772>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26812] ExtendedInterpolation drops user-defined 'vars' during _interpolate_some() recursion

[Yih-En Andrew Ban]

New submission from Yih-En Andrew Ban:

In Python 3.5.1, configparser.ExtendedInterpolation will drop the user-defined 
'vars' passed in via ConfigParser.get(vars=...) due to a bug when recursing 
beyond depth 1 in ExtendedInterpolation._interpolate_some(). Line 509 of 
configparser.py currently reads: 'dict(parser.items(sect, raw=True))' This 
appears to be a mistake and should instead be: 'map', which includes the 
user-defined vars.

The following code will trigger an InterpolationMissingOptionError without the 
fix, and runs as expected with the fix:

from configparser import *
parser = ConfigParser( interpolation=ExtendedInterpolation() )
parser.add_section( 'Section' )
parser.set( 'Section', 'first', '${userdef}' )
parser.set( 'Section', 'second', '${first}' )
parser[ 'Section' ].get( 'second', vars={'userdef': 'userval'} )

--
components: Library (Lib)
messages: 263876
nosy: lukasz.langa, yab-arz
priority: normal
severity: normal
status: open
title: ExtendedInterpolation drops user-defined 'vars' during 
_interpolate_some() recursion
type: behavior
versions: Python 3.5

___
Python tracker 
<http://bugs.python.org/issue26812>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26812] ExtendedInterpolation drops user-defined 'vars' during _interpolate_some() recursion

[Yih-En Andrew Ban]

Yih-En Andrew Ban added the comment:

Sure, patch attached.

--
keywords: +patch
Added file: http://bugs.python.org/file42702/issue26812.patch

___
Python tracker 
<http://bugs.python.org/issue26812>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com