On Tue, Feb 2, 2021 at 12:23 AM Victor Stinner wrote:
>
> Hi Inada-san,
>
> I followed the discussions on your different PEP and I like overall
> your latest PEP :-) I have some minor remarks.
>
> On Mon, Feb 1, 2021 at 6:55 AM Inada Naoki wrote:
> > The warning is disabled by default. New ``-X
Hi Skip,
On 01/02/2021 9:50 pm, Skip Montanaro wrote:
Guido> Maybe these lines in test_dis.py?
...
Skip> Thanks, I'll take a look. I was expecting there'd be a standalone
Skip> script somewhere. Hadn't considered that comments would be hiding
Skip> code.
Indeed, that did the trick, however...
On 2/02/21 12:13 am, Phil Thompson via Python-Dev wrote:
TypeError: object.__new__(B) is not safe, use B.__new__()
It's not safe because object.__new__ doesn't know about any
C-level initialisation that A or B need.
At the C level, there is always a *single* inheritance hierarchy.
The right
On Tue, Feb 2, 2021 at 4:28 AM Steve Dower wrote:
>
>
> I'm not defending the choice of wchar_t over UTF-8 (but I can: most of
> these systems chose Unicode before UTF-8 was invented and never took the
> backwards-incompatible change because they were so popular), but if we
> want to
On Tue, Feb 2, 2021 at 12:43 AM M.-A. Lemburg wrote:
>
> Hi Inada-san,
>
> thank you for adding some comments, but they are not really capturing
> what I think is missing:
>
> """
> Removing these APIs removes ability to use codec without temporary Unicode.
>
> Codecs can not encode Unicode
Guido> Maybe these lines in test_dis.py?
...
Skip> Thanks, I'll take a look. I was expecting there'd be a standalone
Skip> script somewhere. Hadn't considered that comments would be hiding
Skip> code.
Indeed, that did the trick, however... I'm a bit uncomfortable with
the methodology. It seems
Hi Pablo,
Looks like alpha 5 was scheduled for today. I am willing to take care of
this issue - https://bugs.python.org/issue42967
The patch is reasonable, but the changes are backwards incompatible.
Since it is with an underlying parsing library, the decision here is tricky
one way or the
Hi everyone,
I am prepared to start the release process for Python 3.10 a5 but there are
several
issues marked as release blockers that affect 3.10:
* https://bugs.python.org/issue38302
* https://bugs.python.org/issue42634
* https://bugs.python.org/issue41490
* https://bugs.python.org/issue42967
On 2/1/2021 5:16 PM, Christian Heimes wrote:
On 01/02/2021 17.39, M.-A. Lemburg wrote:
Can you explain where wchar_t* type is appropriate and how two
conversions is a performance bottleneck?
If an extension has a wchar_t* string, it should be easy
to convert this in to a Python bytes object
That code is quite old. This comment tries to explain it:
```
/* Check that the use doesn't do something silly and unsafe like
object.__new__(dict). To do this, we check that the
most derived base that's not a heap type is this type. */
```
I think you may have to special-case this and
On Mon, 1 Feb 2021 at 17:19, Christian Heimes wrote:
> How much software actually uses wchar_t these days and interfaces with
> Python? Do you have examples for software that uses wchar_t and would
> benefit from wchar_t support in Python?
This is very much a drive-by comment (I haven't been
On 01/02/2021 17.39, M.-A. Lemburg wrote:
>> Can you explain where wchar_t* type is appropriate and how two
>> conversions is a performance bottleneck?
>
> If an extension has a wchar_t* string, it should be easy
> to convert this in to a Python bytes object for use in Python.
How much software
On Mon, Feb 1, 2021 at 5:58 PM M.-A. Lemburg wrote:
> The fix is pretty simple, doesn't add a lot more code and gets
> us the symmetry back that I had put into the Unicode C API when
> I created this back in 2000.
This sounds like a completely different PEP than PEP 624 (which aims
to remove
On 01.02.2021 17:51, Victor Stinner wrote:
> On Mon, Feb 1, 2021 at 5:39 PM M.-A. Lemburg wrote:
>> The C code is already there, but it got hidden away in the
>> Python 3.3 change to new internals.
>
> Well, we are not in agreement and it's ok. Your objection is written
> in the PEP. IMO it's
On Mon, 1 Feb 2021 17:39:16 +0100
"M.-A. Lemburg" wrote:
>
> They should not use Py_UNICODE.
>
> wchar_t is standard C and is in wide spread use in C code for
> storing Unicode data.
Do you have any data points about "wide spread use"?
I work in C++ daily and don't see any "wide spread use"
On Mon, Feb 1, 2021 at 5:39 PM M.-A. Lemburg wrote:
> The C code is already there, but it got hidden away in the
> Python 3.3 change to new internals.
Well, we are not in agreement and it's ok. Your objection is written
in the PEP. IMO it's now up to the Steering Council to decide if the
overall
On 01.02.2021 17:10, Victor Stinner wrote:
> On Mon, Feb 1, 2021 at 4:47 PM M.-A. Lemburg wrote:
>> At the very least, we should have such APIs for going from wchar_t*
>> to a Python object.
>>
>> The alternatives you provide all require creating an intermediate
>> Python object for this purpose.
On Sat, Jan 30, 2021 at 10:37 AM Antoine Pitrou wrote:
> You can hide the access behind a function call. Slightly more costly,
> but shouldn't be that expensive on modern machines.
Oh sure, on the API side, it can be an "opaque" function call (on the
ABI side) or static inline function,
On Mon, Feb 1, 2021 at 4:47 PM M.-A. Lemburg wrote:
> At the very least, we should have such APIs for going from wchar_t*
> to a Python object.
>
> The alternatives you provide all require creating an intermediate
> Python object for this purpose.
We cannot optimize all use cases. IMO we should
Hi Inada-san,
thank you for adding some comments, but they are not really capturing
what I think is missing:
"""
Removing these APIs removes ability to use codec without temporary Unicode.
Codecs can not encode Unicode buffer directly without temporary Unicode
object since Python 3.3. All
Hi Inada-san,
I followed the discussions on your different PEP and I like overall
your latest PEP :-) I have some minor remarks.
On Mon, Feb 1, 2021 at 6:55 AM Inada Naoki wrote:
> The warning is disabled by default. New ``-X warn_encoding``
> command-line option and ``PYTHONWARNENCODING``
> Maybe these lines in test_dis.py?
> ```
> #print('expected_opinfo_jumpy = [\n ',
> #',\n '.join(map(str, _instructions)), ',\n]', sep='')
> ```
Thanks, I'll take a look. I was expecting there'd be a standalone
script somewhere. Hadn't considered that comments would be hiding
code.
Skip
Hi,
I'm trying to understand the purpose of the check in tp_new_wrapper() of
typeobject.c that results in the "is not safe" exception.
I have the following class hierarchy...
B -> A -> object
...where B and A are implemented in C. Class A has an implementation of
tp_new which does a few
23 matches
Mail list logo
