ault system Python is installed?
>
> Regards,
> Nick.
>
>
> Thanks a lot
>
> --
> Regards,
> Slavek Kabrda
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listi
ficant problems.
>
> Paul
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com
ould you mirror tags too?
Thanks
--
INADA Naoki
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Fixed. Thanks to infra team.
http://psf.upfronthosting.co.za/roundup/meta/issue638
INADA Naoki
On Fri, Sep 1, 2017 at 9:57 PM, Victor Stinner wrote:
> Hi,
>
> When I go to http://bugs.python.org/ Firefox warns me that the form on
> the left to login (user, password) sends data i
Big +1. I love the idea.
str (especially, docstring), dict, and tuples are major memory eater in Python.
This may reduce tuple memory usage massively.
INADA Naoki
On Fri, Sep 8, 2017 at 2:30 AM, Neil Schemenauer wrote:
> Python objects that participate in cyclic GC (things like li
uot; in many modules.
PEP 562 -- Module __getattr__ helps a lot too.
It make possible to split collection module and strings module.
(strings module is used often for constants like strings.ascii_letters, but
strings.Template
cause import time re.compile())
Regards,
--
Inada Naoki
om moving imports into functions or implementing
> lazy modes, until we have figured out how to satisfy requirements of
> both scripts and long running services. We probably need a PEP...
>
> Christian
> _______
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.o
131), # iı
# LATIN SMALL LETTER S, LATIN SMALL LETTER LONG S
(0x73, 0x17f), # sſ
There are some other `re.I(GNORECASE)` options in stdlib. I'll check them.
More optimization can be done with implementing sre_parse and sre_compile
in C.
But I have
I'm 100% agree with Łukasz and Brett.
+1 and thanks for writing this PEP.
INADA Naoki
On Fri, Nov 3, 2017 at 2:00 AM, Brett Cannon wrote:
>
>
> On Thu, 2 Nov 2017 at 08:46 Steven D'Aprano wrote:
>>
>> On Wed, Nov 01, 2017 at 03:48:00PM -0700, Lukasz Langa wro
27;t have strong opinion about what should we do about dict and OrderedDict.
But I feel PyPy's approach (using same implementation and just override
__eq__ and add move_to_end() method) is most simple.
Regards,
INADA Naoki
___
Python-Dev mailing
As memory footprint and import time point of view, I prefer string to thunk.
We can intern strings, but not lambda.
Dict containing only strings is not tracked by GC,
dict containing lambdas is tracked by GC.
INADA Naoki
On Tue, Nov 7, 2017 at 8:20 AM, Lukasz Langa wrote:
>
>
>&
nd
"MicroPython is almost compatible with Python language spec, but has
some restriction"?
If it's very important, how about "strong recommendation for
implementations" instead of
"language spec"?
Users who don't care implementations other than CPython and
insertion order. It's language
spec from 3.6. So we should have two mode for such optimization.
It makes dict more complicated.
So I'm +0.5 on making dict order as language spec, and -1 on "preserves
insertion order until deletion" idea.
But my expect may be wrong. Serhiy is worki
> By the way, I only just realized I can delete a key to demonstrate
> non-order-preservation on py 3.6. So at least I know what to tell students
> now.
>
You can't. dict in Python 3.6 preserves insertion order even after
key deletion.
___
Python-Dev ma
> 2. Switches keyword args and class body execution namespaces over to
> odict so the test suite passes again
> 3. Measures the impact such a change would have on the benchmark suite
For now, odict use twice memory and 2x slower on iteration.
https://bugs.python.org/issue31265#msg3019
f):
self.a, self.b, self.c = 1, 2, 3
a = A()
print(a.__dict__)
a.__dict__.pop('a')
print(a.__dict__)
Anyway, I'm -1 on adding such option to dict. dict in CPython is complicated
already for performance and compatibility rea
il it demonstrates
real performance gain.
> Is there an opportunity to support a fast cast to OrderedDict from 3.6 dict?
> Can it just copy .keys() into the OrderedDict linked list?Or is there more
> overhead to the transition?
https://bugs.python.org/i
I'm sorry about my laziness.
I've very busy these months, but I'm back to OSS world from today.
While I should review carefully again, I think I'm close to accept PEP 540.
* PEP 540 really helps containers and old Linux machines PEP 538 doesn't work.
And containers is really important for these
havior, without modifying code to use "surrogateescape" explicitly.
Which is more important scenario? Anyone has opinion about it?
Are there any rationals and use cases I missing?
Regards,
INADA Naoki
On Wed, Dec 6, 2017 at 12:17 PM, INADA Naoki wrote:
> I'm sorry about my
>> And I have one worrying point.
>> With UTF-8 mode, open()'s default encoding/error handler is
>> UTF-8/surrogateescape.
>
> The Strict UTF-8 Mode is for you if you prioritize correctness over usability.
Yes, but as I said, I cares about not experienced developer
who doesn't know what UTF-8 mode
quot;r") as f: # Binary data, not UTF-8
return f.read()
I'm not sure about this is good idea. And I don't know when is good for
changing write error handler; only when PEP 538 or PEP 540 is used?
Or always when os.fsencoding() is UTF-8?
Any thoughts?
INADA Naoki
___
braries depending on locale.getpreferredencoding() may raise
UnicodeErrors.
Am I correct?
Or locale.getpreferredencoding() returns UTF-8 in UTF-8 mode too?
INADA Naoki
On Fri, Dec 8, 2017 at 9:50 AM, Victor Stinner wrote:
> Hi,
>
> I made the following two changes to the PEP 540:
>
> * o
> Or locale.getpreferredencoding() returns UTF-8 in UTF-8 mode too?
Or should we change loale.getpreferredencoding() to return UTF-8
instead of ASCII always, regardless of PEP 538 and 540?
INADA Naoki
___
Python-Dev mailing list
Python-Dev@python.
ep-0538/#changes-to-the-default-error-handling-on-the-standard-streams
Since coercion target locales and UTF-8 mode do same thing,
I think this is not a big issue.
But I want it is clarified in the PEP.
Regards,
---
INADA Naoki
___
Python-Dev mailing list
d explicitly, locale coercion affects Python code too.
locale.getpreferredencoding() is UTF-8, open()' s default encoding is UTF-8,
and stdio is UTF-8/surrogateescape.
So shouldn't this sentence is: "Locale coercion impacts both of Python code
and non-Python code like C li
"surrogateescape" default for stdin
> and stderr error handling to also apply to the three potential coercion
> target locales.
https://www.python.org/dev/peps/pep-0538/#defaulting-to-surrogateescape-error-handling-on-the-standard-io-streams
I don't think en_US.UTF-8 should u
Except one typo I commented on Github,
I accept PEP 540.
Well done, Victor and Nick for PEP 540 and 538.
Python 3.7 will be most UTF-8 friendly Python 3 than ever.
INADA Naoki
On Mon, Dec 11, 2017 at 2:21 AM, Victor Stinner
wrote:
> Ok, I fixed the effects of the locale coercion (PEP
_US.UTF-8 should use surrogateescape, it may make confusing situation
like: "This script works in English Linux desktop, but doesn't work in
Japanese Linux
desktop!"
I accepted PEP 540. So even if failed to coerce locale, it is better
than
nough room
to optimize.
* It can make stop discussion like "Does X keeps insertion order?
It's language spec?", "What about Y? Z?". Everything on top of dict
keeps insertion order. It's simple to learn and explain.
Regards,
INADA Naoki
On Sun, Nov 5, 201
discussion of OrderedDict implementation.
Regards,
INADA Naoki
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ge CSV with DictReader.
While I think application should use tuple when memory consumption is
matter, there is significant benefit.
INADA Naoki
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
are more # than GH- in commit log.
https://github.com/python/cpython/commits/master
Where should we go?
Encourage GH-? or abandon it and use default #NNNN?
Regards,
--
INADA Naoki
___
Python-Dev mailing list
Python-Dev@python.org
h
gt;=1.2x,<1.3x faster.
> 5 that are >=1.1x,<1.2x faster.
> 0 that are < 1.1x faster/slower.
>
> Pretty good numbers overall I think.
>
>
Yay!! Congrats for all of us!
--
INADA Naoki
___
Python-Dev mailing list
Python-Dev@py
ring for
simplicity. So it's backward incompatible for both of reading and
writing docstring too.
But it keeps lineno and column of docstring in AST.
3 is most conservative because 3.7b2 was cut now and there are some tools
supporting 3.7 already.
I prefer 2 or 3. If we took 3, I do
a, b, c):
... self.a, self.b, self.c = a, b, c
...
>>> class D:
... def __init__(self, a, b, c):
... self.__dict__ = {'a':a, 'b':b, 'c':c}
...
>>> import sys
>>> sys.getsizeof(C(1,2,3).__dict__)
112
>>> sys.getsizeof(D(1,2,3).
hash and 48bit*2
for key and value. CompactEntry may be 16byte instead of 24byte.
Regards,
--
INADA Naoki
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mai
Some of APIs are stated as "Deprecated since version 3.3, will be
removed in version 4.0:".
e.g. https://docs.python.org/3/c-api/unicode.html#c.PyUnicode_AS_UNICODE
So we will remove them (and wstr) at Python 4.0.
___
Python-Dev mailing list
Python-Dev@
bject is not negligible.
But, of course, it's vary according to applications and libraries.
--
INADA Naoki
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailm
FYI, there is filed issue.
https://bugs.python.org/issue33099
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.co
bytes soon by moving `wstr` before `state`.
Off course, it needs siphash support 4byte aligned data instead of 8byte.
Regards,
--
INADA Naoki
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-de
and
> bytes, but for memoryview, which doesn't guarantee any alignment.
>
Oh, I'm sad about hear that...
> Note that after removing the wchar_t* field the gap will not gone, because
> the size of the structure should be a multiple of the alignment of the first
> field (whic
On Fri, Apr 27, 2018 at 10:52 AM Paul G wrote:
> Rust has a few syntactic ways to accomplish the same thing, though. I
think match expressions are used for the equivalent of conditionals that
carry the condition value into the body of the expression, and all blocks
return the result of the last s
ytes[index])
when doing such big change next time.
--
INADA Naoki
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Recently, I reported how stdlib slows down `import requests`.
https://github.com/requests/requests/issues/4315#issuecomment-385584974
For Python 3.8, my ideas for faster startup time are:
* Add lazy compiling API or flag in `re` module. The pattern is compiled
when first used.
* Add IntEnum and
l broke hash randomization.
See also: https://www.cvedetails.com/cve/CVE-2017-11499/
Regards,
--
Inada Naoki
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
that it's useful and safe when it's used carefully.
Regards,
On Tue, May 15, 2018 at 1:58 AM Antoine Pitrou wrote:
> On Tue, 15 May 2018 01:33:18 +0900
> INADA Naoki wrote:
> >
> > It will broke hash randomization.
> >
> > See also: https://www.cvedetails.co
2018年5月15日(火) 2:17 Antoine Pitrou :
>
> Le 14/05/2018 à 19:12, INADA Naoki a écrit :
> > I'm sorry, the word *will* may be stronger than I thought.
> >
> > I meant if memory image dumped on disk is used casually,
> > it may make easier to make security hole.
Keep insertion order" is requirement from 3.7 which is not released yet.
I feel it's too early to add more stronger requirements to core type.
Regards,
---
INADA Naoki
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.pyt
On Sun, May 27, 2018 at 12:43 PM Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
> > On May 26, 2018, at 7:20 AM, INADA Naoki wrote:
> >
> > Because doubly linked list is very memory inefficient, every
implementation
> > would be forced to implement di
buildbots are stable, if Antoine or
other GC expert accept it.
I estimate it reduces 5% memory usage (RSS) and negligible performance
difference.
If someone interested in it, please test and benchmark it on GC heavy
application.
Regards,
--
INADA Naoki
>
> First I was also
> confused between travis-ci.com and travis-ci.org ... The documentation
> shows an example with .com, but Python organization uses .org.
>
> Victor
>
.org is legacy.
Open source projects can migrate to new .com.
Maybe, ssh is .com only feature.
https://blog.travis-ci.com/
2018年6月7日(木) 2:44 Brett Cannon :
>
> On Wed, 6 Jun 2018 at 09:27 INADA Naoki wrote:
>
>> First I was also
>>> confused between travis-ci.com and travis-ci.org ... The documentation
>>> shows an example with .com, but Python organization uses .org.
>&g
tal application performance because it covers most calls.
But calling callable object other than them are relatively rare. It may
not affect
real world performance of most applications.
So, until I can compare it's complexity and benefits, I can say only "
I didn't meant comparing tp_fastcall and your PEP.
I just meant we need to compare complexity and benefit (performance),
and we need reference implementation for comparing.
On Mon, Jun 18, 2018 at 3:03 PM Jeroen Demeyer wrote:
> On 2018-06-18 03:34, INADA Naoki wrote:
> > Victo
doubt making some 3rd party call 20% faster can make real
applications significant faster.
--
INADA Naoki
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailma
On Tue, Jun 19, 2018 at 2:56 PM Jeroen Demeyer wrote:
> On 2018-06-18 16:55, INADA Naoki wrote:
> > Speeding up most python function and some bultin functions was very
> > significant.
> > But I doubt making some 3rd party call 20% faster can make real
> > appl
That's why I suggested to add new benchmark.
2018年6月19日(火) 22:22 Ivan Levkivskyi :
> On 19 June 2018 at 13:02, Nick Coghlan wrote:
>
>> On 19 June 2018 at 16:12, INADA Naoki wrote:
>> >
>> > On Tue, Jun 19, 2018 at 2:56 PM Jeroen Demeyer
>> wrote:
>
nternals already. I suppose that making it
public
doesn't make Python 3.7 unstable much.
If we can't at Python 3.7, I think we should do it at 3.8.
Regards,
--
INADA Naoki
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.o
2018年6月21日(木) 1:17 Antoine Pitrou :
> On Wed, 20 Jun 2018 18:09:00 +0200
> Victor Stinner wrote:
> >
> > > If we can't at Python 3.7, I think we should do it at 3.8.
> >
> > What's the rationale to make it public in 3.7? Can't it wait for 3.8?
> > The new PEPs target 3.8 anyway, no?
> >
> > IMHO
2018年6月21日(木) 1:59 Serhiy Storchaka :
> 20.06.18 18:42, INADA Naoki пише:
> > First of all, thank you Jeroen for writing nice PEPs.
> >
> > When I read PEP 579, I think "6. METH_FASTCALL is private and
> undocumented"
> > should be solved first.
>
ut METH_FASTCALL publication before
evaluating
PEP 580. That's my main point, and "from 3.7" part is just a bonus, sorry.
--
INADA Naoki
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listin
On Thu, Jun 21, 2018 at 2:57 PM Jeroen Demeyer wrote:
> On 2018-06-20 17:42, INADA Naoki wrote:
> > I don't have any idea about changing METH_FASTCALL more.
> > If Victor and Serhiy think so, and PyPy maintainers like it too, I want
> > to make it public
> > as
2018年6月21日(木) 20:27 Jeroen Demeyer :
> Currently, we have:
>
> >>> [].append == [].append
> False
>
> However, with a Python class:
>
> >>> class List(list):
> ... def append(self, x): super().append(x)
> >>> List().append == List().append
> True
>
> In the former case, __self__ is compared
and test_pydoc fail for me. I still
> have to fix those.
>
>
> Jeroen.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/songo
05
So it's not problem about general policy about refactoring / clean up.
It's just my preference. If Victor and Serhiy prefer the PR, I'm OK to
merge it.
Regards,
--
INADA Naoki
___
Python-Dev mailing list
Python-Dev@python.org
h
EP 580 also?
>
Real need is important than my preference. If it is needed PEP 580, I'm OK.
But I didn't know which part of the PR is required by PEP 580.
Regards,
--
INADA Naoki
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Wed, Jun 27, 2018 at 2:27 PM Jeroen Demeyer wrote:
> On 2018-06-27 00:02, Guido van Rossum wrote:
> > And TBH a desire to refactor a lot of code is often a sign of a
> > relatively new contributor who hasn't learned their way around the code
> > yet, so they tend to want to make the code follo
g-python-on-windows
>
> Be considered?
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/songofaca
//fatoptimizer.readthedocs.org/en/latest/
>
> Victor
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/
On Tue, Jan 26, 2016 at 12:02 PM, Andrew Barnert wrote:
> On Jan 25, 2016, at 18:21, INADA Naoki wrote:
> >
> > I'm very interested in it.
> >
> > Ruby 2.2 and PHP 7 are faster than Python 2.
> > Python 3 is slower than Python
.
But I wonder if CPython is more faster, especially about global lookup and
function call.
--
INADA Naoki
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/m
On Tue, Jan 26, 2016 at 2:44 PM, Andrew Barnert wrote:
> On Jan 25, 2016, at 19:32, INADA Naoki wrote:
>
> On Tue, Jan 26, 2016 at 12:02 PM, Andrew Barnert
> wrote:
>
>> On Jan 25, 2016, at 18:21, INADA Naoki wrote:
>> >
>> > I'm very interested in
ns that contributors to open source projects work on
> what they want to work on or on what their employers pay them to work
> on (for a lucky few, those are the same thing), so telling other
> contributors that they're working on the "wrong thing" because their
> prioritie
I'm +1 on adding general protocol for *coerce to string* like __index__.
+0.5 on inherit from str (and drop byte path support).
--
INADA Naoki
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
FYI, Ruby's Pathname class doesn't inherit String.
http://ruby-doc.org/stdlib-2.1.0/libdoc/pathname/rdoc/Pathname.html
Ruby has two "convert to string" method.
`.to_s` is like `__str__`.
`.to_str` is like `__index__` but for str. It is used for implicit
conversion.
File.open accepts any object
Sorry, I've forgot to use "Reply All".
On Tue, Apr 12, 2016 at 9:49 AM, INADA Naoki wrote:
> IHMO it's safer to get an encoding error rather than no error when you
>> concatenate two byte strings encoded to two different encodings (mojibake).
>>
>> print
t; or some such thing makes python3 less approachable for those who haven't
> learned that yet - which was almost all of us at some point when we started
> programming.
>
>
Totally agree with you.
--
INADA Naoki
___
Python-Dev maili
; NOAA/NOS/OR&R(206) 526-6959 voice
> 7600 Sand Point Way NE (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
>
> chris.bar...@noaa.gov
>
> ___
> Python-Dev mailing list
> Pyth
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com
>
--
INADA Nao
representation of a number, so they're right out.
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mai
representation of a number, so they're right out.
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mai
nx;
> \
> >> fi
> >
> > Doc/make.bat needs to be similarly updated.
>
> Indeed, thanks for the reminder.
>
> Georg
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.or
ion of bytes and
> text. (And if I sometimes come across as over-dogmatic, I apologise -
> put it down to the enthusiasm of the recent convert :-))
>
> Paul
>
> [1] If you cannot see that there's no essential reason why the base-10
> representation '123' should correspo
_
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
s porting
> https://warehouse.python.org/project/MySQL-python/ to Python 3. :)
>
I've did it.
https://github.com/PyMySQL/mysqlclient-python
https://pypi.python.org/pypi/mysqlclient
--
INADA Naoki
___
Python-Dev mailing list
Python-Dev@python
at O(1) string indexing operations are a quality of
>> implementation issue, not a deal breaker to call it a Python. I can't
>> see any requirement in the docs that str[n] must take O(1) time, but
>> perhaps I have missed something.
>>
>
> ___
el how PEP 572 is different from f-string or ternary
expression.
f-string and ternary expression can do only what expressions can.
But PEP 572 expands "what expressions can".
I feel PEP 572 breaks border between expression and statement, and it makes
readability of dirty code worse.
On t
e and effort into achieving that.
>
>
> Thanks,
> Jeroen.
> _______
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/
On Thu, Jul 5, 2018 at 1:13 AM Jeroen Demeyer wrote:
>
> On 2018-07-04 03:31, INADA Naoki wrote:
> > I think both PEPs are relying on FASTCALL calling convention,
> > and can't be accepted until FASTCALL is stable & public.
>
> First of all, the fact that FASTCAL
On Thu, Jul 5, 2018 at 6:31 PM Jeroen Demeyer wrote:
>
> On 2018-07-05 05:41, INADA Naoki wrote:
> > And stabilizing calling convention is prerequirements of designing new
> > calling APIs.
>
> I don't see why. I made my PEP with the assumption that the
> METH_F
On Thu, Jul 5, 2018 at 9:02 PM Jeroen Demeyer wrote:
>
> On 2018-07-05 13:32, INADA Naoki wrote:
> > Core devs interested in this area is limited resource.
>
> I know and unfortunately there is nothing that I can do about that. It
> would be a pity that PEP 580 (or a variant
upporting keywords easily, like Python. So this can be worthless...
--
INADA Naoki
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Fri, Jul 6, 2018 at 7:50 PM Jeroen Demeyer wrote:
>
> On 2018-07-05 14:20, INADA Naoki wrote:
> > like you ignored my advice about creating realistic benchmark for
> > calling 3rd party callable before talking about performance...
>
> I didn't really want to ig
oved, it's not
necessary. METH_VARARGS | METH_KEYWORDS is fine.
--
INADA Naoki
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
doesn't explain any information
about it.
When, and how often custom method type is used?
Isn't it very rare? If there are only 0.1% custom method type,
why reducing 30% calling overhead is important for them?
I want more possible target applications to motivate me
for such compl
On Sat, Jul 7, 2018 at 4:35 PM Stefan Behnel wrote:
>
> INADA Naoki schrieb am 07.07.2018 um 06:10:
> > How often "custom method type" are used?
> >
> > I thought Cython use it by default.
> > But when I read code generated by Cython, I can't find it.
dwritten extension.
> What am I missing? Comments from the maintainers of Cython and other
> similar tools would be appreciated.
>
> Cheers,
> Mark.
--
INADA Naoki
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.
ese PEPs are not needed for them.
I think main motivation of these PEPs are modern Python usages:
Jupyter notebook + Cython.
Unlike extension module writer, we shouldn't expect user knows
difference between C and Python. That's why Cyth
__
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com
--
INADA Naoki
___
ectly.
I think optimization like this idea can boost application performance
using Cython heavily.
But in Python and stdlib, there are no enough "call C function from C function"
scenarios, compared with Cython based applications. We really
need help from Cython world for this area.
Regar
1 - 100 of 538 matches
Mail list logo
