New submission from benrg benrud...@gmail.com:
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 namedtuple
foo = namedtuple('foo', '')
[1] + foo
benrg benrud...@gmail.com 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
New submission from benrg benrud...@gmail.com:
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 understand
New submission from benrg benrud...@gmail.com:
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
benrg benrud...@gmail.com added the comment:
The bug is still present in 3.2.
--
versions: +Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8847
New submission from benrg benrud...@gmail.com:
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
New submission from benrg benrud...@gmail.com:
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
benrg benrud...@gmail.com 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 benrud...@gmail.com 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
benrg benrud...@gmail.com 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
benrg benrud...@gmail.com 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
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 += [3]
y
[1, 2, 3]
x = y = {1, 2}
x -= {2}
y
{1}
Since when has
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 aware of any other language in which
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 x += y as add the value of y to the object x
New submission from benrg <benrud...@gmail.com>:
>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 tha
New submission from benrg <benrud...@gmail.com>:
(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
benrg <benrud...@gmail.com> 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
benrg <benrud...@gmail.com> 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
progr
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': 'http://host:456', 'ftp':
'http
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 (prior to
2019-01-01) has
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 supported
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
subprocess.Popen, the spawned
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
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_ATTRIBUTES &am
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 sorted
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 (not e
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
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-based sorting of
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.
Right now, it's not
30 matches
Mail list logo
