Charles Machalow added the comment:
Maybe we need to add a __packing__ option to specify how packing should
work and default to legacy behavior. Then allow users to specify if they
want similar behavior cross-os.
Otherwise changing this does change packing for existing users and can lead
Charles Machalow added the comment:
In terms of multiple parameters, I propose adding a method to control the
defaults used by !p.
Though the defaults would work more than well enough for basic log and print
usage.
--
___
Python tracker
<ht
Charles Machalow added the comment:
One of the key things for ppformat here is to format long spanning dicts/lists
to multiple lines, that look easy to read in a log. I feel as though that
feature/usefulness outweigh potential indentation weirdness.
A lot of the usage would probably
Charles Machalow added the comment:
Fair enough. Didn't really know that list existed. Sent this there. Awaiting
moderator approval. Thanks.
--
___
Python tracker
<https://bugs.python.org/issue41
New submission from Charles Machalow :
Right now in str.format(), we have !s, !r, and !a to allow us to call str(),
repr(), and ascii() respectively on the given expression.
I'm proposing that we add a !p conversion to have pprint.pformat() be called to
convert the given expression
Charles Machalow added the comment:
I'm disappointed to see this closed. For new (and old) users, it makes complete
sense to have an rmtree method on the Path object itself.
If I'm using pathlib, I try not to delegate to os. for file operations,
since it also tends to seem more OO and clean
New submission from Charles Machalow :
I think it would make sense to add a recurse flag to the Path.rmdir() method.
It would default to False (to allow for current behavior). If set to True, the
method would act very similarly to shutil.rmtree() in that it would delete all
files
New submission from Charles Machalow :
I ran the following as admin in the Python interpreter (on Windows):
>>> d = pathlib.Path(r'\\.\PHYSICALDRIVE0')
>>> print(d)
\\.\PHYSICALDRIVE0\
>>> d.exists()
Traceback (most recent call last):
File "", line 1, i
Charles Machalow <csm10...@gmail.com> added the comment:
All of Python is implicitly cross platform. If something isn't actually cross
platform, it should be mentioned explicitly in the documentation. For example
see the mmap documentation, it explicitly say on Unix it does X, on W
Charles Machalow <csm10...@gmail.com> added the comment:
Antti, is there a place in the ctypes documentation that explicitly says ctypes
is not meant to be used cross-platform? If not, shouldn't that be mentioned?
I think ultimately ctypes should default to standard OS/compiler be
Charles Machalow added the comment:
Was browsing and found this.
This option would be very useful as it could help avoid a current bug I've had
to deal with : https://bugs.python.org/issue29753. My use case works with
data/structs from another device all-together, so I can't control it's
Charles Machalow added the comment:
Some more debug with print statements in the c code seems to confirm my
suspicion:
bitsize, pfield_size, bitofs, dict->size prints were added just above the if
chain to determine fieldtype and fieldtype was just after that if chain. That
code lo
Charles Machalow added the comment:
Took a quick look at the c code for this. The area at fault appears to be this
section in cfield.c:
#ifndef MS_WIN32
} else if (bitsize /* this is a bitfield request */
&& *pfield_size /* we have a bitfield open */
&&
New submission from Charles Machalow:
There appears to be a bug related to sizing/packing of ctypes Structures on
Linux. I'm not quite sure how, but this structure:
class MyStructure(Structure):
_pack_ = 1
_fields_= [
("P", c_uint16),
Changes by Charles Machalow <csm10...@gmail.com>:
Removed file: http://bugs.python.org/file41298/ctypesBug.py
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Charles Machalow <csm10...@gmail.com>:
Added file: http://bugs.python.org/file41299/ctypesBug.py
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Charles Machalow:
Large sized fields in Structures lead to incorrect string representations
because it is assuming that because the size is so large, it must be a bit
field instead of a byte field.
class bugStruct(Structure):
_pack_ = 1
_fields_
Charles Machalow added the comment:
Adding file with code to reproduce.
--
Added file: http://bugs.python.org/file41298/ctypesBug.py
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Charles Machalow <csm10...@gmail.com>:
Removed file: http://bugs.python.org/file41297/ctypesBug.py
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
19 matches
Mail list logo
