Re: [Python-Dev] PEP 394 - Clarification of what "python" command should invoke
ault system Python is installed? > > Regards, > Nick. > > > Thanks a lot > > -- > Regards, > Slavek Kabrda > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listi
Re: [Python-Dev] 3.5 release schedule PEP
ficant problems. > > Paul > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com
[Python-Dev] No tags in semi-official github mirror of cpython repository.
ould you mirror tags too? Thanks -- INADA Naoki ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] HTTPS on bugs.python.org
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
Re: [Python-Dev] Memory bitmaps for the Python cyclic garbage collector
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
[Python-Dev] Investigating time for `import requests`
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
Re: [Python-Dev] Python startup optimization: script vs. service
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 > [email protected] > https://mail.python.o
[Python-Dev] Make re.compile faster
131), # iı # LATIN SMALL LETTER S, LATIN SMALL LETTER LONG S (0x73, 0x17f), # ss 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
Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations
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
Re: [Python-Dev] Guarantee ordered dict literals in v3.7?
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
Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations
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: > > >&
Re: [Python-Dev] Guarantee ordered dict literals in v3.7?
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
Re: [Python-Dev] The current dict is not an "OrderedDict"
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
Re: [Python-Dev] Guarantee ordered dict literals in v3.7?
> 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
Re: [Python-Dev] Guarantee ordered dict literals in v3.7?
> 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
Re: [Python-Dev] Guarantee ordered dict literals in v3.7?
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
Re: [Python-Dev] OrderedDict(kwargs) optimization?
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
Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v2)
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
Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v2)
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
Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v2)
>> 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
Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v2)
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 ___
Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v3)
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
Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v3)
> 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.
Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v3)
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
Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v3)
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
Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v3)
"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
Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v3)
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
Re: [Python-Dev] PEP 540: Add a new UTF-8 mode (v3)
_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
Re: [Python-Dev] Guarantee ordered dict literals in v3.7?
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
Re: [Python-Dev] Guarantee ordered dict literals in v3.7?
discussion of OrderedDict implementation. Regards, INADA Naoki ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decision of having a deprecation period or not for changing csv.DictReader returning type.
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 [email protected] https://mail.python.org/mailman/listinfo/python-dev
[Python-Dev] GH-NNNN vs #NNNN in merge commit
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 [email protected] h
Re: [Python-Dev] OS-X builds for 3.7.0
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
[Python-Dev] Backward incompatible change about docstring AST
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
Re: [Python-Dev] Replacing self.__dict__ in __init__
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).
[Python-Dev] How can we use 48bit pointer safely?
hash and 48bit*2 for key and value. CompactEntry may be 16byte instead of 24byte. Regards, -- INADA Naoki ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mai
Re: [Python-Dev] Nuking wstr [Re: How can we use 48bit pointer safely?]
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@
Re: [Python-Dev] Nuking wstr [Re: How can we use 48bit pointer safely?]
bject is not negligible. But, of course, it's vary according to applications and libraries. -- INADA Naoki ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailm
Re: [Python-Dev] Trying to build from source, test-poplib fails
FYI, there is filed issue. https://bugs.python.org/issue33099 ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.co
[Python-Dev] Timing for removing legacy Unicode APIs deprecated by PEP 393
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 [email protected] https://mail.python.org/mailman/listinfo/python-de
Re: [Python-Dev] Timing for removing legacy Unicode APIs deprecated by PEP 393
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
Re: [Python-Dev] Is PEP 572 really the most effective way to solve the problems it's targeting?
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
Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3
ytes[index]) when doing such big change next time. -- INADA Naoki ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python startup time
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
Re: [Python-Dev] Python startup time
l broke hash randomization. See also: https://www.cvedetails.com/cve/CVE-2017-11499/ Regards, -- Inada Naoki ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python startup time
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 2018年5月15日 01:33:18 +0900 > INADA Naoki wrote: > > > > It will broke hash randomization. > > > > See also: https://www.cvedetails.co
Re: [Python-Dev] Python startup time
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.
Re: [Python-Dev] Add __reversed__ methods for dict
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 [email protected] https://mail.pyt
Re: [Python-Dev] Add __reversed__ methods for dict
On Sun, May 27, 2018 at 12:43 PM Raymond Hettinger < [email protected]> 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
[Python-Dev] Compact GC Header
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
Re: [Python-Dev] Keeping an eye on Travis CI, AppVeyor and buildbots: revert on regression
>> 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/
Re: [Python-Dev] Keeping an eye on Travis CI, AppVeyor and buildbots: revert on regression
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
Re: [Python-Dev] PEP 575 (Unifying function/method classes) update
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 "
Re: [Python-Dev] PEP 575 (Unifying function/method classes) update
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
Re: [Python-Dev] PEP 575 (Unifying function/method classes) update
doubt making some 3rd party call 20% faster can make real applications significant faster. -- INADA Naoki ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailma
Re: [Python-Dev] PEP 575 (Unifying function/method classes) update
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
Re: [Python-Dev] PEP 575 (Unifying function/method classes) update
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: >
[Python-Dev] Can we make METH_FASTCALL public, from Python 3.7? (ref: PEP 579
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 [email protected] https://mail.python.o
Re: [Python-Dev] Can we make METH_FASTCALL public, from Python 3.7? (ref: PEP 579
2018年6月21日(木) 1:17 Antoine Pitrou :> On 2018年6月20日 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
Re: [Python-Dev] Can we make METH_FASTCALL public, from Python 3.7? (ref: PEP 579
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. >
Re: [Python-Dev] Can we make METH_FASTCALL public, from Python 3.7? (ref: PEP 579
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 [email protected] https://mail.python.org/mailman/listin
Re: [Python-Dev] Can we make METH_FASTCALL public, from Python 3.7? (ref: PEP 579
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
Re: [Python-Dev] About [].append == [].append
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
Re: [Python-Dev] PEP 580 (C call protocol) draft implementation
and test_pydoc fail for me. I still > have to fix those. > > > Jeroen. > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/songo
Re: [Python-Dev] Policy on refactoring/clean up
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 [email protected] h
Re: [Python-Dev] Policy on refactoring/clean up
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 [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Policy on refactoring/clean up
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
Re: [Python-Dev] VS 2010 compiler
g-python-on-windows > > Be considered? > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/songofaca
Re: [Python-Dev] FAT Python (lack of) performance
//fatoptimizer.readthedocs.org/en/latest/ > > Victor > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/
Re: [Python-Dev] FAT Python (lack of) performance
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
Re: [Python-Dev] FAT Python (lack of) performance
. But I wonder if CPython is more faster, especially about global lookup and function call. -- INADA Naoki ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/m
Re: [Python-Dev] FAT Python (lack of) performance
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
Re: [Python-Dev] FAT Python (lack of) performance
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
Re: [Python-Dev] Defining a path protocol
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 [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Defining a path protocol
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
Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()
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
Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5
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
Re: [Python-Dev] Python3 "complexity"
; 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 > > [email protected] > > ___ > Python-Dev mailing list > Pyth
Re: [Python-Dev] Python3 "complexity"
> ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com > -- INADA Nao
Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5
representation of a number, so they're right out. > > Regards > > Antoine. > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mai
Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5
representation of a number, so they're right out. > > Regards > > Antoine. > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mai
Re: [Python-Dev] cpython (3.3): Update Sphinx toolchain.
nx; > \ > >> fi > > > > Doc/make.bat needs to be similarly updated. > > Indeed, thanks for the reminder. > > Georg > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.or
Re: [Python-Dev] PEP 460: allowing %d and %f and mojibake
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
Re: [Python-Dev] pootle.python.org is down
_ >> Python-Dev mailing list >> [email protected] >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com > > > ___ > Python-Dev mailing list > [email protected]
Re: [Python-Dev] Language Summit Follow-Up
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
Re: [Python-Dev] Internal representation of strings and Micropython
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. >> > > ___
Re: [Python-Dev] Examples for PEP 572
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
Re: [Python-Dev] Comparing PEP 576 and PEP 580
e and effort into achieving that. > > > Thanks, > Jeroen. > _______ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/
Re: [Python-Dev] Comparing PEP 576 and PEP 580
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
Re: [Python-Dev] Comparing PEP 576 and PEP 580
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
Re: [Python-Dev] Comparing PEP 576 and PEP 580
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
Re: [Python-Dev] On the METH_FASTCALL calling convention
upporting keywords easily, like Python. So this can be worthless... -- INADA Naoki ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Comparing PEP 576 and PEP 580
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
Re: [Python-Dev] On the METH_FASTCALL calling convention
oved, it's not necessary. METH_VARARGS | METH_KEYWORDS is fine. -- INADA Naoki ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 579 and PEP 580: refactoring C functions and methods
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
Re: [Python-Dev] PEP 579 and PEP 580: refactoring C functions and methods
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.
Re: [Python-Dev] PEP 575, 576, 579 and 580
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 [email protected] https://mail.python.
Re: [Python-Dev] PEP 575, 576, 579 and 580
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
Re: [Python-Dev] Micro-benchmarks for function calls (PEP 576/579/580)
__ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com -- INADA Naoki ___
Re: [Python-Dev] Micro-benchmarks for PEP 580
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