New submission from jakirkham :
Reporting an issue recently encountered by a colleague.
It appears the `multiprocessing`'s "spawn" mode doesn't actually use POSIX
spawn, but instead uses fork+exec[1]. While this is certainly a useful feature
in its own right, this not qu
jakirkham added the comment:
The 2nd argument is the `strides`. IOW it is just specifying how to traverse
the buffer in memory to visit each of the dimensions.
For the first example where `strides` is not specified, Python makes them
C-ordered. IOW `m2.strides` would be `(3, 1
Change by jakirkham :
--
nosy: +jakirkham
___
Python tracker
<https://bugs.python.org/issue45819>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by jakirkham :
--
nosy: +jakirkham
___
Python tracker
<https://bugs.python.org/issue47010>
___
___
Python-bugs-list mailing list
Unsubscribe:
jakirkham added the comment:
Would it be possible to check for these newer OpenSSL symbols during the builds
of Python 3.8 & 3.9 (using them when available and otherwise falling back to
the older API otherwise)? This would allow people to build Python 3.8 & 3.9
with the newer
jakirkham added the comment:
Right with this change ( https://github.com/python/cpython/pull/25468 ). Thanks
for adding that Christian :)
I guess what I'm wondering is if in older Python versions we could do an
`#ifdef` check to try and use `SSL_read_ex` & `SSL_write_ex` if the sy
jakirkham added the comment:
Not following. Why would it break? Presumably once one builds Python for a
particular OS they keep there (like system package managers for example).
Or alternatively they build on a much older OS and then deploy to newer ones.
The latter case is what we do in
Change by jakirkham :
--
nosy: +jakirkham
___
Python tracker
<https://bugs.python.org/issue37355>
___
___
Python-bugs-list mailing list
Unsubscribe:
jakirkham added the comment:
Agree with Bruce. It seems like we could have support for OpenSSL 1.1.1 at that
level with a compile time fallback for previous OpenSSL versions that break up
the work. Would hope this solution also yields something we can backport more
easily
Change by jakirkham :
--
nosy: +jakirkham
___
Python tracker
<https://bugs.python.org/issue28646>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by jakirkham :
--
nosy: +jakirkham
___
Python tracker
<https://bugs.python.org/issue43976>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from jakirkham :
In Python 3.8+, pickle protocol 5 ( PEP<574> ) was added, which supports
out-of-band buffer collection[1]. The idea being that when pickling an object
with a large amount of data attached to it (like an array, dataframe, etc.) one
could collect this
Change by jakirkham :
--
versions: +Python 3.11
___
Python tracker
<https://bugs.python.org/issue41226>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by jakirkham :
--
versions: +Python 3.11
___
Python tracker
<https://bugs.python.org/issue43096>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by jakirkham :
--
versions: +Python 3.11
___
Python tracker
<https://bugs.python.org/issue41223>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by jakirkham :
--
versions: +Python 3.10, Python 3.11
___
Python tracker
<https://bugs.python.org/issue40718>
___
___
Python-bugs-list mailing list
Unsub
Change by jakirkham :
--
components: +Library (Lib)
___
Python tracker
<https://bugs.python.org/issue40718>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by jakirkham :
--
components: +Library (Lib)
type: -> enhancement
___
Python tracker
<https://bugs.python.org/issue41226>
___
___
Python-bugs-list mai
jakirkham added the comment:
We ran into the same issue in conda-forge (
https://github.com/conda-forge/python-feedstock/issues/522 ).
The problem is Apple also supplies their own `libffi`. However if the build
scripts in CPython fail to find the user provided `libffi`, they end up pulling
New submission from jakirkham :
To allow reading into a provided buffer without copying, it would be useful to
have a `read_into` method on `asyncio.StreamReader`, which takes a buffer
supporting the buffer protocol and fills it.
--
components: asyncio
messages: 386114
nosy: asvetlov
Change by jakirkham :
--
nosy: +jakirkham
___
Python tracker
<https://bugs.python.org/issue40007>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by jakirkham :
--
nosy: +jakirkham
___
Python tracker
<https://bugs.python.org/issue27149>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from jakirkham :
It would be nice (where possible) to support out-of-band pickling of builtin
`bytes`-like types. This would allow binary data from these objects to be
shipped along separately zero-copy and later reconstructed during unpickling.
It seems that `bytes
jakirkham added the comment:
Sorry if I'm just misunderstanding the discussion here. Would it make sense to
have an `order` keyword argument to `cast` as well? This seems useful when
interpreting a flatten F-order `bytes` object (say on the receiving end of a
transmission).
--
Change by jakirkham :
--
nosy: +jakirkham
___
Python tracker
<https://bugs.python.org/issue39645>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from jakirkham :
When working with an `object`-backed `memoryview`, it seems we are unable to
coerce it to a `list`. This would be useful as it would provide a way to get
the underlying `object`'s into something a bit easier to work with.
```
In [1]: import
New submission from jakirkham :
Currently one can reshape a `memoryview` using `.cast(...)` like so...
```
In [1]: m = memoryview(b"abcdef")
In [2]: m2 = m.cast("B", (2, 3))
```
However it is not currently possible to specify the `strides` when reshaping
the `memory
New submission from jakirkham :
When working with lower level C/C++ code, the Python Buffer Protocol[1] has
been immensely useful as it allows common Python `bytes`-like objects to expose
the underlying memory buffer in a pointer that C/C++ code can easily work with
zero-copy. In fact
jakirkham added the comment:
Thanks for the clarification, Eric! :)
Is this the sort of thing that we could capture in the `format`[1] field (like
with `"B"`, `"H"`, and `"I"`[2]) or are there potential issues there?
[1]: https://docs.python.org/3/c-api/buf
Change by jakirkham :
--
nosy: +jakirkham
___
Python tracker
<https://bugs.python.org/issue37293>
___
___
Python-bugs-list mailing list
Unsubscribe:
30 matches
Mail list logo
