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
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
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
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
>>
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,
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
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
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
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
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
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
14 matches
Mail list logo
