ariable named like PyId_foo,
but all usage in CPython uses ASCII only, and _Py_Identifier is still private.
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.pytho
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 (non-ASCII) character? Does
> _PyUnicode_FromASCII() rai
hon.
So I wanted to discuss we really need to support non-ASCII before that.
But it seems I was late already.
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.p
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
___
ibuting generated C source code instead of a binary wheel
or Cython source code.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.o
On Tue, Jun 25, 2019 at 5:49 AM Antoine Pitrou wrote:
>
>
> For the record, there's another contender in the allocator
> competition now:
> https://github.com/microsoft/mimalloc/
>
> Regards
>
> Antoine.
It's a very strong competitor!
$ ./python -m pyperf compare_to pymalloc.json mimalloc.json -
20.8 kB -> 66.5 MB +- 21.1 kB: 1.07x slower (+7%)
- python_startup: 7946.6 kB +- 20.4 kB -> 8210.2 kB +- 16.6 kB: 1.03x
slower (+3%)
- python_startup_no_site: 7409.0 kB +- 18.3 kB -> 7574.6 kB +- 21.8
kB: 1.02x slower (+2%)
```
--
Inada Naoki
_
MB
...
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives
On Thu, Jul 4, 2019 at 11:32 PM Inada Naoki wrote:
>
> On Thu, Jul 4, 2019 at 8:09 PM Antoine Pitrou wrote:
> >
> > Ah, interesting. Were you able to measure the memory footprint as well?
> >
>
> Hmm, it is not good. mimalloc uses MADV_FREE so it may affect to s
have been wrapped
> around obmalloc over the years are to blame? Perhaps mimalloc's
> larger (16x) pools and arenas let it stay in its fastest paths more
> often? I don't know why, but it would be interesting to find out :-)
Totally agree. I'll investigate this next.
Regards
On Tue, Jul 9, 2019 at 5:29 PM Inada Naoki wrote:
>
> On Tue, Jul 9, 2019 at 9:46 AM Tim Peters wrote:
> >
> >> I was more intrigued by your first (speed) comparison:
> >
> > > - spectral_norm: 202 ms +- 5 ms -> 176 ms +- 3 ms: 1.15x faster (-13%)
> >
On Wed, Jul 10, 2019 at 5:18 PM Neil Schemenauer wrote:
>
> On 2019-07-09, Inada Naoki wrote:
> > PyObject_Malloc inlines pymalloc_alloc, and PyObject_Free inlines
> > pymalloc_free.
> > But compiler doesn't know which is the hot part in pymalloc_alloc and
>
> Mean +- std dev: [python-master] 199 ms +- 1 ms -> [python] 182 ms +-
> 4 ms: 1.10x faster (-9%)
...
> I will try to split pymalloc_alloc and pymalloc_free to smaller functions.
I did it and pymalloc is now as fast as mimalloc.
$ ./python bm_spectral_norm.py --compare-to=./python-master
python-
evs here.
>
FWIW, there is PendingDeprecationWarning for something discouraged
but not deprecated, and will be deprecated in the future.
But I prefer simple deprecation.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@py
On Tue, Jul 16, 2019 at 11:07 PM Jeroen Demeyer wrote:
>
> On 2019-07-16 15:33, Inada Naoki wrote:
> >> We currently have a deprecation policy saying that functions deprecated
> >> in version N cannot be removed before version N+2. That's a reasonable
> >&g
ns on an items view does.
-1. What is the motivation of this?
In this case, I don't think "I found missing parts so I want to
implement it for consistency"
is not enough reason to implement it.
I want a real-world application which requires it.
Without a strong use case
nd-wprintf-functions?view=vs-2015
"%zd" is standard C99 feature. Can we assume it is portable for now?
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
ht
ted I wasted a few hours to read some PDFs and searching
but I can not
find any official document about snprintf(3).
I feel it's impossible to support such platforms...
Except AIX, I believe all platforms supports size_t and %zd because
it's very basic
C99 feature.
Regards,
--
Inada Naok
Thank you for confining it!
Currently, Python defines PY_FORMAT_SIZE_T as:
#ifndef PY_FORMAT_SIZE_T
# if SIZEOF_SIZE_T == SIZEOF_INT && !defined(__APPLE__)
# define PY_FORMAT_SIZE_T ""
# elif SIZEOF_SIZE_T == SIZEOF_LONG
# define PY_FORMAT_SIZE_T "l"
# elif defined(MS_WINDOWS)
# define PY_FORMAT_
no-op. Bytes warning never emits.
3.12: Remove the -b option.
BytesWarning will be deprecated in the document, but not to be removed.
Users who want to use the -b option during 2->3 conversion need to use
Python ~3.10 for a while.
Regards,
--
Inada Na
s://github.com/python/cpython/blob/fb5db7ec58624cab0797b4050735be865d380823/Modules/_functoolsmodule.c#L802
https://github.com/python/cpython/blob/fb5db7ec58624cab0797b4050735be865d380823/Objects/codeobject.c#L724
(maybe more, but I'm not sure)
Regards,
--
Inada Naoki
3.10: Stop emitting BytesWarning for bytes == unicode case, because
this is the most annoying part.
3.11: Stop emitting BytesWarning in core and stdlib.
4.0: Remove `-b` option, `sys.flags.bytes_warning`, and `BytesWarning`.
Regards,
--
Inada Naoki
___
Pytho
On the other hand, I want to remove confusion by removing mention to
`__cause__`.
Because I don't think `__context__` and `__cause__` is important for new users.
See https://github.com/python/cpython/pull/23162 for my proposal.
Regards,
--
Inada Naoki
_
o beginners.
And deleting `__cause__` is not solery for "didactic" reason, nor
"loosing something precious."
As written in the b.p.o. issue, mention only `__cause__` "lose some precious".
We need to describe `__context__` and `__suppress_context__` too.
But all of them
t very often the documentation is very terse and the tutorial is the only
> place
> where some concepts are presented in a discursive way ... even if not
> "beginner friendly".
>
You know, exception chaining is described well in other place so it was removed.
I pr
ibrary/exceptions.html#built-in-exceptions
This is mentioned from the reviced tutorial, python-dev thread, and b.p.o issue.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@pyt
s feature to lower
> maintenance burden.
Which warning helped you? str(bytes)? bytes == str? or bytes == int?
I am not much concerned about removing str(bytes) warning anytime soon.
Only bytes== warning is significant maintenance burden.
Reg
; in the issue title.
* E.g. "needs compiler experts", "xml", "http", "mail", etc...
It will help to find PRs I can help in my spare time.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-d
eprecate PyUnicode_READY() and make it no-op
macro since Python 3.12.
But I don't know how many third-parties use it properly, because
legacy Unicode objects are very rare already.
Regards,
--
Inada Naoki
___
Python-Dev mailing list --
Unicode objects (including subclass) but any objects implementing some
protocol.
We already have __index__ for integers and buffer protocol for
byts-like objects. That is examples of the policy.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- pytho
On Mon, Dec 28, 2020 at 10:53 PM Antoine Pitrou wrote:
>
> On Mon, 28 Dec 2020 11:07:46 +0900
> Inada Naoki wrote:
> >
> > Additionally, if we introduce the customizable lazy str object, it's
> > very easy to release GIL during basic Unicode operations. M
If 3rd party wants to use completely different internal
representation, it must not be a unicode object at all.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
> Performance
> ---
>
> Performance with this PEP should be favorable. In general,
> resources are only consumed on demand—"you only pay for what you use".
>
Nice!
> There are three scenarios to consider:
>
> * the runtime cost when annotations aren't defined,
> * the runtime cost when a
On Wed, Jan 13, 2021 at 1:47 AM Larry Hastings wrote:
>
> On 1/11/21 5:33 PM, Inada Naoki wrote:
>
> Note that PEP 563 semantics allows more efficient implementation.
> Annotation is just a single constant tuple, not a dict.
> We already have the efficient implementation for Py
This PEP doesn't cover about what happened when __co_annotation__()
failed (e.g. NameError).
Forward reference is a major reason, but not a only reason for using
string annotation. There are two other reasons:
* Avoid importing heavy module.
* Avoid circular imports.
In these cases, this pattern
ce
is not a problem here.
Many type hinting use cases don't need type objects in runtime.
So I think PEP 563 is better for type hinting user experience.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To
On Tue, Jan 19, 2021 at 8:54 AM Larry Hastings wrote:
>
> On 1/18/21 3:42 PM, Inada Naoki wrote:
>
> Many type hinting use cases don't need type objects in runtime.
> So I think PEP 563 is better for type hinting user experience.
>
> You mean, in situations where the u
Hi, Lemburg.
I want to send the PEP to SC.
I think I wrote all your points in the PEP. Would you review it?
Regards,
On Tue, Aug 4, 2020 at 5:04 PM Inada Naoki wrote:
>
> On Tue, Aug 4, 2020 at 3:31 PM M.-A. Lemburg wrote:
> >
> > Hi Inada-san,
> >
> > thanks for
Hi, all.
I updated the PEP 597 yesterday.
Please review it to move it forward.
PEP: https://www.python.org/dev/peps/pep-0597/
Previous thread: https://discuss.python.org/t/3880
Main difference from the previous version:
* Added new warning category; EncodingWarning
* Added dedicated option to e
encoders?
> That would keep extensions working after a recompile, since
> Py_UNICODE is already a typedef to wchar_t.
>
That idea is written in the PEP already.
https://www.python.org/dev/peps/pep-0624/#replace-py-unicode-with-wchar-t
Regards,
--
Inada Naoki
become equal.
So please don't think PEP 624 neglect only wchar_t*.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/
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 di
ucs4_utf8_encoder() can encode
wchar_t* into UTF-8.
But when wchar_t* is UTF-16, ucs2_utf8_encoder() can not handle
surrogate escape.
We need to use a temporary Unicode object. That is what "inefficient" means.
I will update the section more elaborate.
Regards,
--
Inada Naoki
_
On Tue, Feb 2, 2021 at 9:40 PM Emily Bowman wrote:
>
> On Tue, Feb 2, 2021 at 3:47 AM Inada Naoki wrote:
>>
>> But when wchar_t* is UTF-16, ucs2_utf8_encoder() can not handle
>> surrogate escape.
>> We need to use a temporary Unicode object. That is what "ineff
On Tue, Feb 2, 2021 at 8:40 PM Inada Naoki wrote:
>
> On Tue, Feb 2, 2021 at 7:37 PM M.-A. Lemburg wrote:
> >
> > BTW: I don't understand this comment:
> > "They are inefficient on platforms wchar_t* is UTF-16. It is because
> > built-in codecs sup
gt; No.
>
> Hum. To write code compatible with Python 3.9, I understand that
> encoding=None is the closest to encoding="locale".
>
> And I understand that encoding=getattr(io, "LOCALE_ENCODING", None) is
> backward and forward compatible ;-)
>
&
On Tue, Feb 2, 2021 at 1:40 PM Inada Naoki wrote:
>
> On Tue, Feb 2, 2021 at 12:23 AM Victor Stinner wrote:
> >
> >
> > > Add ``io.LOCALE_ENCODING = "locale"`` constant too. This constant can
> > > be used to avoid confusing ``LookupError: unknown e
I send a pull request https://github.com/python/peps/pull/1799
* Add Backward/Forward Compatibility section
* Add How to teach this section
* Remove io.LOCALE_ENCODING constant
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To
False)`?
I think only we can do is documenting the option like this:
"""
EncodingWarning is warning to find missing encoding="utf-8" option. It
is common pitfall that many Windows user
Don't try to fix them if you need to use locale specific encoding.
"""
;
This warning is opt-in warning like BytesWarning.
It will be a good tool to find potential problems for people knows
what is the problem.
But it is not recommended for users who don't understand what is the problem.
--
Inada Naoki
___
Python-
. I want
to see how EncodingWarning and UTF-8 mode are adopted.
I want to implement both EncodingWarning and per-site UTF-8 mode
setting in Python 3.10.
5+ years later, we will see which approach is adopted by users.
* If EncodingWarning is widely adopted by many developer
On Wed, Feb 10, 2021 at 1:46 AM Anders Munch wrote:
>
>
> Inada Naoki wrote:
> > This warning is opt-in warning like BytesWarning.
>
> What use is a warning that no-one sees?
At least, I see.
We can fix stdlib and tests first, and fix some major tools too.
After th
On Wed, Feb 10, 2021 at 5:50 AM Paul Moore wrote:
>
> On Tue, 9 Feb 2021 at 16:54, Inada Naoki wrote:
> >
> > On Tue, Feb 9, 2021 at 9:31 PM Paul Moore wrote:
> > >
> > > Personally, I'm not at all keen on the idea of making users always
> > >
allation,
venv, or conda env).
But this is off topic. The thread for this topic is here.
https://mail.python.org/archives/list/python-id...@python.org/thread/LQVK2UKPSOI2AHYFUWK6ZII2U6QKK6BP/
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-
Don't touch -- You don't need to enable EncodingWarning.
* encoding=locale.getpreferredencoding(False) -- Backward compatible.
But doesn't work if you enabled UTF-8 mode.
* encoding="mbcs" -- Backward compatible. Works even when you enabled
UTF-8 mode. But it doesn't work
On Wed, Feb 10, 2021 at 11:58 PM Anders Munch wrote:
>
> On Wed, Feb 10, 2021 at 1:46 AM Anders Munch wrote:
> >> How about swapping around "locale" and None?
> Inada Naoki wrote:
> >
> > I thought it, but it may not work. Consider about function like
On Thu, Feb 11, 2021 at 4:44 PM Jim J. Jewett wrote:
>
> I just reread PEP 597, then re-reread the Rationale.
>
Do you read current PEP 597, or old PEP 597 in discuss.python.org?
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@p
g)
with open(filename, encoding=encoding) with f:
return f.read()
This function is not warned. Caller of this function is warned
instead. It is difficult to implement in the Linter.
--
Inada Naoki
___
Python-Dev mailing list -- p
On Fri, Feb 12, 2021 at 5:18 AM Jim J. Jewett wrote:
>
> Inada Naoki wrote:
>
> > Default encoding is used for:
>
> > a. Really need to use locale specific encoding
> > b. UTF-8 (bug. not work on Windows)
> > c. ASCII (not a bug, but slow on Windows)
>
many places before the time. At least, we can
fix all EncodingWarning in stdlib.
Maybe, the "Prepare to change the default encoding to UTF-8" is misleading.
I will try to fix the section or remove the section.
--
Inada Naoki
___
On Fri, Feb 12, 2021 at 12:28 PM Jim J. Jewett wrote:
>
> (I apologize if my summaries distort what Inada Naoki
> explained.)
>
> He said that some people use the default None when they really want
> either UTF-8 or ASCII.
Yes. Even Python core developers.
For example: https
On Fri, Feb 12, 2021 at 12:45 PM Jim J. Jewett wrote:
>
> On Thu, Feb 11, 2021 at 7:35 PM Inada Naoki wrote:
>
> > The PEP helps developers living on UTF-8 locale to find missing
> > `encoding="utf-8"` bug.
> > This type of bug is very common, and many Wind
ew
> environment variable, and maybe a new launch flag ... these all seem to risk
> just making things more complicated without sufficient gain.
>
> Would a recipe for site-packages be sufficient, or does this need to run too
> early in the bootstrapping process?
>
c and will
find many possible bugs that happen only on Windows, even if they
don't use Windows daily development.
Isn't this option worth enough?
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an emai
ferences used
only type hints, or user can not get even string form annotation which
is very useful for REPLs.
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list
do you think? about PYTHON_WARN_DEFAULT_ENCODING?
---
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archiv
Thank you for all.
I finally submit the PEP 597 with PYTHONWARNDEFAULTENCODING /
warn_default_encoding.
On Mon, Feb 15, 2021 at 2:28 PM Inada Naoki wrote:
>
> I am updating PEP 597 to include discussions in the thread.
> Before finishing the PEP, I need to decide the option name.
&
/1272280760280637441
>
> Anyway, this is yet another SJW non-issue (countries other than US don't have
> a modern history of slavery) so this change is a political
> statement rather than has any technical merit.
>
Yes. If we don't change the name, we need to pay our energy to sa
thon 3.9 support and
use `encoding="locale"` where locale encoding is needed.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/li
on Steering Council's gratitude,
> Thomas.
> --
> Thomas Wouters
>
> Hi! I'm an email virus! Think twice before sending your email to help me
> spread!
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.o
.
For paths, fsencoding is the right encoding. It is UTF-8 on Windows
(excpet PYTHONLEGACYWINDOWSFSENCODING is set), and locale-specific
encoding in Linux.
What encoding should we use?
* UTF-8
* sys.getfilesystemencoding()
* Keep status-quo.
Regards,
--
Inada Naoki
OK. setuptools doesn't specify encoding at all. So locale-specific
encoding is used.
We can not fix it in short term.
On Wed, Mar 17, 2021 at 4:56 AM Brett Cannon wrote:
>
>
>
> On Mon, Mar 15, 2021 at 7:53 PM Inada Naoki wrote:
>>
>> Hi, all.
>>
>> I
On Wed, Mar 17, 2021 at 5:33 PM Paul Moore wrote:
>
> On Wed, 17 Mar 2021 at 08:13, Michał Górny wrote:
> >
> > On Wed, 2021-03-17 at 13:55 +0900, Inada Naoki wrote:
> > > OK. setuptools doesn't specify encoding at all. So locale-specific
> > > encoding
h.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/
On Thu, Apr 1, 2021 at 11:52 AM Brett Cannon wrote:
>
> On Wed., Mar. 31, 2021, 18:56 Inada Naoki, wrote:
>>
>> Do we need _pyio at all?
>> Does PyPy or any other Python implementation use it?
>
> https://www.python.org/dev/peps/pep-0399/ would suggest rolling back
'U' mode was removed once and resurrected.
https://bugs.python.org/issue39674
As far as I can see, it is postponed to Python 3.10. Am I right?
Can we remove 'U' mode in Python 3.10?
Regards,
--
Inada Naoki
___
Python-Dev mailin
On Wed, Apr 7, 2021 at 11:29 PM Miro Hrončok wrote:
>
> On 07. 04. 21 14:53, Inada Naoki wrote:
> > 'U' mode was removed once and resurrected.
> > https://bugs.python.org/issue39674
> >
> > As far as I can see, it is postponed to Python 3.10. Am I right?
&
on-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/VTROKN5UOU3EN6F3OLX5RUK7TVETAXKB/
> Code of Conduct: http://python.org/psf/codeofconduct/
--
Inada Nao
On Thu, Apr 8, 2021 at 9:54 AM Inada Naoki wrote:
>
> We are close to 3.10 beta and it is not ideal timing for removing.
> So my proposal is:
>
> * Remove 'U' in fileinput, because it makes my task little simpler.
> * Remove 'U' in other places in Python 3.1
at
> https://mail.python.org/archives/list/python-dev@python.org/message/QSASX6PZ3LIIFIANHQQFS752BJYFUFPY/
> Code of Conduct: http://python.org/psf/codeofconduct/
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsub
On Tue, Apr 13, 2021 at 8:58 AM Larry Hastings wrote:
>
> On 4/12/21 4:50 PM, Inada Naoki wrote:
>
> As PEP 597 says, eval() is slow. But it can avoidable in many cases
> with PEP 563 semantics.
>
> PEP 597 is "Add optional EncodingWarning". You said PEP 597 in o
On Tue, Apr 13, 2021 at 9:57 AM Larry Hastings wrote:
>
>
> On 4/12/21 4:50 PM, Inada Naoki wrote:
>
> PEP 563 solves all problems relating to types not accessible in runtime.
> There are many reasons users can not get types used in annotations at runtime:
>
> * To avoid c
On Tue, Apr 13, 2021 at 11:18 AM Paul Bryan wrote:
>
> On Tue, 2021-04-13 at 10:47 +0900, Inada Naoki wrote:
>
> On Tue, Apr 13, 2021 at 9:57 AM Larry Hastings wrote:
>
>
> This is really the heart of the debate over PEP 649 vs PEP 563. If you
> examine an annotati
than OpenWrapper and DocDescripter.
Additionally, if we have same issue in other module, we can just use
staticmethod, instead of copy&paste OpenWrapper and DocDescripter.
So it provides "compensating practical benefit".
Regards,
--
Inada Naoki
__
se use case used only is a limited part of application. On the
other hand, type hint can be used almost everywhere in application
code base. It must cheap enough.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe
/cpython/pull/23056 too.
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https
+/- 0.00016614519056599577
exec: avg: 0.09546191191766411 +/- 0.00018099485135812695
```
Summary:
* Both of PEP 563 and PEP 649 has low memory consumption than Python 3.9.
* Importing time (unmarshal+exec) is about 0.7sec on old semantics and
PEP 649, 0.43sec on PEP 563.
On Thu, Apr 15, 2021 at 10:31 AM Inada Naoki
TYPE_CHECKING` and manually stringified annotation is used
in real world applications.
I want to mix both use cases.
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https:/
from
eval(). If we implement a "lazy load" mechanizm for docstrings and
annotations, overhead will become cheaper.
* pyc file become bigger (but who cares?)
I will read PEP 649 implementation to find missing optimizations other
than GH-25419 and GH-230
se type hinting even after I dropped Python 3.9
support.
But it is up to release manager and steering council.
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.p
.
Unlike simple function case, PEP 649 creates function object instead
of code object for __co_annotation__ of methods.
It cause this overhead. Can we avoid creating functions for each annotation?
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@py
ter PEP 563, only `'List[int]'` is practical so we can stop
supporting `List["int"]` and others at some point.
So playing with runtime type will become easier in the future.
Am I wrong?
--
Inada Naoki
___
Python-Dev mailing list -- p
/compile.c:1977
#13 0x55688e51 in compiler_class (c=c@entry=0x7fffc3d0,
s=s@entry=0x56222a60) at Python/compile.c:2623
#14 0x55687ce3 in compiler_visit_stmt (s=,
c=0x7fffc3d0) at Python/compile.c:3667
#15 compiler_body (c=c@entry=0x7fffc3d0, stmts=0x
As far as I know, both Pydantic and marshmallow start using annotation
for runtime type after PEP 563 is accepted. Am I right?
When PEP 563 is accepted, there are some tools using runtime type in
annotation, but they are not adopted widely yet.
But we didn't have any good way to emit DeprecationWa
__
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/ZAPCP4MFDO
On Tue, Apr 20, 2021 at 4:24 PM Inada Naoki wrote:
>
> Just an idea: do not save co_name and co_firstlineno in code object
> for function annotations.
> When creating a function object from a code object, they can be copied
> from annotated function.
>
I created a pu
``
# co_annotations
$ ./python ~/ann_test.py 3
code size: 236106 bytes
memory: 208261 bytes
unmarshal: avg: 653.788ms +/-1.257ms
exec: avg: 95.783ms +/-0.169ms
# optimize
$ ./python ~/ann_test.py 3
code size: 162097 bytes
memory: 208261 bytes
unmarshal: avg: 458.959ms +/-0.163ms
exec: avg: 98.327ms +
(c) is broken by design. It is not fixable.
IMHO, We should chose (a) or (b) and reject any idea relying on Sequence ABC.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@p
@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/J6GGEKUBMPU3X3WNKUG2XUD3GDV7L2FK/
> Code of Conduct: http://python.org/psf/codeofconduct/
--
Inada Naoki
201 - 300 of 538 matches
Mail list logo
