22.06.19 01:08, Daniel Holth пише:
Thanks. I think I might like an option to disable str(bytes) without
disabling str != bytes. Unless the second operation would also corrupt
output.
Came across this kind of set in the hyper http library which uses a set
to accept certain headers with either
For those who would like to test with something compatible with
Python 3.7.3, I made re-based branches here:
https://github.com/nascheme/cpython/tree/obmalloc_radix_v37
https://github.com/nascheme/cpython/tree/obmalloc_big_pools_v37
They should be ABI compatible with Python 3.7.3. So,
The answer bytes == str is just False. That doesn't put b'' in your
database by accident. It could be useful to separate the two kinds of
warnings.
On Fri, Jun 21, 2019, 18:57 Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:
> On 22.06.2019 1:08, Daniel Holth wrote:
>
> Thanks. I think
On 2019-06-21, Tim Peters wrote:
> [Thomas Wouters ]
> > Getting rid of address_in_range sounds like a nice idea, and I
> > would love to test how feasible it is -- I can run such a change
> > against a wide selection of code at work, including a lot of
> > third-party extension modules, but I don'
On 22.06.2019 1:08, Daniel Holth wrote:
Thanks. I think I might like an option to disable str(bytes) without disabling str != bytes. Unless the second operation would also
corrupt output.
You can't compare str to bytes without knowing the encoding the bytes are supposed to be in (see
https://s
Le ven. 21 juin 2019 à 23:19, Thomas Wouters a écrit :
> Is this really feasible in a world where the allocators can be selected (and
> the default changed) at runtime?
The memory allocation must not be changed after the Python
pre-initialization. What's done after pre-initialization is more to
[Tim]
>> I don't think we need to cater anymore to careless code that mixes
>> system memory calls with O calls (e.g., if an extension gets memory
>> via `malloc()`, it's its responsibility to call `free()`), and if not
>> then `address_in_range()` isn't really necessary anymore either, and
>> then
Thanks. I think I might like an option to disable str(bytes) without
disabling str != bytes. Unless the second operation would also corrupt
output.
Came across this kind of set in the hyper http library which uses a set to
accept certain headers with either str or bytes keys.
On Tue, Jun 18, 2019
On Sun, Jun 2, 2019 at 7:57 AM Tim Peters wrote:
> I don't think we need to cater anymore to careless code that mixes
> system memory calls with O calls (e.g., if an extension gets memory
> via `malloc()`, it's its responsibility to call `free()`), and if not
> then `address_in_range()` isn't rea
ACTIVITY SUMMARY (2019-06-14 - 2019-06-21)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open7038 (+16)
closed 42078 (+65)
total 49116 (+81)
Open issues w
Steven,
Yes and I posted to python-dev for a reason - I'm almost positive that
this is a bug - or at least an inconsistency - in how python handles
stack frames WRT closures in some instances. In fact, the reason I
posted is because we hit this inconsistency in handling production
code - we need
On Fri, 21 Jun 2019 12:22:21 +0900
Inada Naoki wrote:
> On Fri, Jun 21, 2019 at 1:28 AM Victor Stinner wrote:
> >
> > Le jeu. 20 juin 2019 à 11:15, Inada Naoki a écrit
> > :
> > > Can we change _PyUnicode_FromId to use _PyUnicode_FromASCII?
> >
> > How would a developer detect a mistake (no
OK. I start optimizing PyUnicode_GetString() already.
It was 2x slower than _PyUnicode_FromASCII.
But it can be only 1.5x slower than _PyUnicode_FromASCII.
And as a bonus, `b"foo".decode()` become 10% faster too.
--
Inada Naoki
___
Python-Dev mail
20.06.19 19:28, Victor Stinner пише:
Le jeu. 20 juin 2019 à 11:15, Inada Naoki a écrit :
Can we change _PyUnicode_FromId to use _PyUnicode_FromASCII?
How would a developer detect a mistake (non-ASCII) character? Does
_PyUnicode_FromASCII() raise an exception, even in release mode?
The functi
Hi Ed,
Your note probably won't receive any other reply than this, because the
python-dev list is specifically for discussions about the development _of_,
rather than _with_, Python.
A more appropriate forum is probably the Python list (python-l...@python.org),
about which you can discover more d
15 matches
Mail list logo
