New submission from benrg :
`importlib._bootstrap_external` contains this comment:
# We need an absolute path to the py file to avoid the possibility of
# collisions within sys.pycache_prefix [...]
# [...] the idea here is that if we get `Foo\Bar`, we first
# make it absolute
benrg added the comment:
memmem isn't a standard C function, and some libraries don't have it, notably
Microsoft's.
newlib's memmem seems to be the same as glibc's, but is under a BSD 3-clause
license instead of LGPL. An older version of newlib's memmem
New submission from benrg :
On Windows, `mmap.mmap(f.fileno(), ...)` has the undocumented side effect of
setting f's file pointer to 0.
The responsible code in mmapmodule is this:
/* Win9x appears to need us seeked to zero */
lseek(fileno, 0, SEEK_SET);
Win9x is no longer supp
New submission from benrg :
The Windows functions that deal with environment variables are case-insensitive
and case-preserving, like most Windows file systems. Many environment variables
are conventionally written in all caps, but others aren't, such as
`ProgramData`, `PSModulePath`
New submission from benrg :
On Windows, if one writes
env = os.environ.copy()
env['http_proxy'] = 'whatever'
or either of the documented equivalents ({**os.environ, ...} or (os.environ |
{...})), and passes the resulting environment to subprocess.run or
subproces
benrg added the comment:
This issue should be marked dependent on issue 43702 or issue 46862, since
fixing it could break third-party code unless they're fixed first.
> Given 'nt.environ' is available without case remapping, I think that's the
> best workaround.
New submission from benrg :
math.prod is slow at multiplying arbitrary-precision numbers. E.g., compare the
run time of factorial(5) to prod(range(2, 50001)).
factorial has some special-case optimizations, but the bulk of the difference
is due to prod evaluating an expression tree of
benrg added the comment:
My example used ints, but I was being deliberately vague when I said "bignums".
Balanced-tree reduction certainly isn't optimal for ints, and may not be
optimal for anything, but it's pretty good for a lot of things. It's the
comparison-b
benrg added the comment:
Anything that produces output of O(m+n) size in O(m+n) time. Ordered merging
operations. Mergesort is a binary ordered merge with log-depth tree reduction,
and insertion sort is the same binary operation with linear-depth tree
reduction. Say you're merging s
benrg added the comment:
The REMOVE_DIR case reduces to
return RemoveDirectoryW(path->wide) ? 0 : -1;
so I think there's no reason to combine it with the other two.
The REMOVE_BOTH case is
attrs = GetFileAttributesW(path->wide);
if (attrs != INVALID_FILE_ATTRIBUTE
benrg added the comment:
>That memory frugality adds a log2 factor to the runtime.
Your iterative algorithm is exactly the one I had in mind, but it doesn't have
the run time that you seem to think. Is that the whole reason for our
disagreement?
It does only O(1) extra work (
benrg added the comment:
I am still interested in this for the same reason I was interested in this in
the first place; nothing has changed. I guess I will reiterate, and try to
expand.
The problem is that ctypes tries to enforce const correctness (inconsistently),
but it has no way to
benrg added the comment:
With this patch, read_byte returns an integer in the range -128 to 127 instead
of 0 to 255 if char is signed. Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52)
[MSC v.1500 32 bit (Intel)] on win32 is affected by this. I think it is a bug.
The test code would fail if
New submission from benrg :
In Python 3.1.3, (c_char*5).from_buffer(b'abcde') worked. In 3.2 it fails with
"TypeError: expected an object with a writable buffer interface".
This seems to represent a significant decrease in the functionality of ctypes,
since, if I understa
New submission from benrg :
class MakeContextHandler:
def __init__(self, enter, exit):
self.__enter__ = enter
self.__exit__ = exit
with MakeContextHandler(lambda: None, lambda *e: None): pass
In 3.1.3 this worked; in 3.2 it raises AttributeError('__exit__'), which
appea
benrg added the comment:
The bug is still present in 3.2.
--
versions: +Python 3.2
___
Python tracker
<http://bugs.python.org/issue8847>
___
___
Python-bug
New submission from benrg :
ctypes accepts bytes objects as arguments to C functions, but not bytearray
objects. It has its own array types but seems to be unaware of array.array. It
doesn't even understand memoryview objects. I think that all of these types
should be passable to C
New submission from benrg :
A struct that is resized knows its new size; among other things, the new size
is returned by sizeof.
But it seems to be impossible to increase the size of a struct that doesn't own
its buffer. resize fails in this case. This would not be too bad if the size
benrg added the comment:
But when I translate my example according to PEP 343, it works (i.e., doesn't
raise an exception) in 3.2, and PEP 343 says "[t]he details of the above
translation are intended to prescribe the exact semantics." So I think that at
least one of PEP 343,
benrg added the comment:
w9xpopen is currently used on NT. The patch to use it on NT was checked in by
bquinlan in August of 2001
(http://mail.python.org/pipermail/patches/2001-August/005719.html). He claims
that it is necessary in NT, even though (a) the cited knowledge base article
benrg added the comment:
It turns out that, on Windows 7 32-bit with COMSPEC pointing to command.com,
platform.popen('dir').read() works with w9xpopen and fails (no output) without
it.
But the reason has nothing to do with the old Win9x problem. It's because
subprocess al
New submission from benrg :
If `HKCU\Software\Microsoft\Windows\CurrentVersion\Internet
Settings\ProxyServer` contains the string
`http=host:123;https=host:456;ftp=host:789`, then getproxies_registry() should
return
{'http': 'http://host:123', 'https': &#
New submission from benrg :
(Pure)WindowsPath uses str.lower to fold paths for comparison and hashing. This
doesn't match the case folding of actual Windows file systems. There exist
WindowsPath objects that compare and hash equal, but refer to different files.
For example, the st
benrg added the comment:
This bug is about paths that compare *equal*, but refer to *different* files. I
agree that the opposite is not much of a problem (and I said so in the original
comment).
The reason I classified this as a security bug is that Python scripts using
pathlib on Windows
benrg added the comment:
I don't know whether this clarifies it at all, but if x and y are Path objects,
and x == y, I would expect also x.exists() == y.exists(), and x.read_bytes() ==
y.read_bytes(), and so on, unless there is a race condition. I think all
programmers expect that if x
New submission from benrg :
>From 3.3 on, the expression () is compiled to BUILD_TUPLE 0 instead of
>LOAD_CONST. That's probably fine and I suppose it's slightly more efficient to
>avoid adding an entry to the constant table.
The problem is that BUILD_TUPLE 0 is not treate
benrg added the comment:
This is bizarre:
Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> x = y = [1, 2]
>>> x +=
benrg added the comment:
> As far as I know Ezio is correct, "when possible" means "when the target is
> mutable". The documentation should probably be clarified on that point.
Yes, it needs to be made very, very clear in the documentation. As I said, I'm
not
benrg added the comment:
> AFAIK in C "x += 1" is equivalent to "x++", and both are semantically
> more about incrementing (mutating) the value of x than about creating a
> new value that gets assigned to x. Likewise it seems to me more natural
> to interpret &q
New submission from benrg :
c:\>python
Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit (Intel)]
on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from collections import namedtup
30 matches
Mail list logo
