top suppressing DeprecationWarning by default
* Use at least one PendingDeprecationWarning and one DeprecationWarning.
* More than two PendingDeprecationWarning periods is preferred.
How do you think?
--
Inada Naoki
___
Python-Dev mailing list -- python-de
how DeprecationWarning.
And there are many scripts without tests.
So it is hidden for some people.
--
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
CC optimize ("O0")
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:/
So how about making PY_SSIZE_T_CLEAN not mandatory in Python 3.11?
Extension modules can use '#' format with ssize_t, without
PY_SSIZE_T_CLEAN defined.
Or should we wait one more version?
Regards,
--
Inada Naoki
___
Python-Dev mailing li
Python 3.12 will be released at 2023-10.
So we can change PY_SSIZE_T_CLEAN by default from 3.12.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail
e_SizeT().
> Could we remove or merge them after making PY_SSIZE_T_CLEAN not mandatory?
They are part of stable ABIs. So we can remove/merge them at Python 4.0.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsu
n do it in Python 3.12 or 3.13.
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 a
le ABIs already.
If I am wrong, can we stop keeping stable ABI at Python 3.12?
Python 4.0 won't come in foreseeable future. Stable ABI blocks Python evolution.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To uns
FWIW, GitHub announced new powerful Issues today.
https://github.com/features/issues
It may fill some gap between GitHub Issues and Roundup.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to
+1
2021年7月29日(木) 19:46 Mark Shannon :
> Hi everyone,
>
> I would like to repeal PEP 509. We don't really have a process for
> repealing a PEP. Presumably I would just write another PEP.
>
> Before I do so, I would like to know if anyone thinks we should keep
> PEP 509.
>
> The dictionary version
tion of PEP 649 has been suspended.
We need to revive it and measure performance/memory impact.
As far as I remember, the reference implementation created a function
object for each methods.
It means doubles function objects. It has major impact to memory
usage, startup time, and
/archives/list/python-dev@python.org/message/2OOCEE6OMBQYEIJXEGFWIBE62VPIJHP5/
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/pytho
> 2021/08/11 19:22、Paul Moore のメール:
>
> Also, I don't think that improving performance is a
> justification for a non-trivial backward compatibility break (I don't
> recall a case where we've taken that view in the past) so "PEP 649
> solves forward references without a backward compatibility imp
deprecating PEP 563.
--
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
thon-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/52VFBHR7AHTXPLC434E4BPXNXVUU3SVF/
> Code of Conduct: http://python.org/psf/codeofconduct/
--
Inada N
something?
>
>
> --- Giampaolo
> https://code.google.com/p/pyftpdlib/
> https://code.google.com/p/psutil/
> https://code.google.com/p/pysendfile/
> ___
> Python-Dev mailing list
> Python-Dev@pyth
efore finishing implementation, I want to see comments and tests from core
developers.
Please come to core-mentorship ML or pull request and try it if you
interested in.
Regards,
--
INADA Naoki
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.pyt
?). I'll discuss them in core-mentor ML or bugs.python.org.
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
>
> pybench: https://gist.github.com/methane/cfad1427d87ceff9310350e78a214880
> benchmark: https://gist.github.com/methane/5eb11fdd93863813b222e795ca0bfc1f
>
> Is it acceptable?
latest result is here
https://gist.github.com/methane/22cf5d1dadb62bc87a15e9244a9d0ab8
.
In case of very small dict, index hash (8byte) and first two entries
(24*2=48byte)
can be on one cache line.
* Easy to implement "split dictionary" (aka. key sharing dictionary).
You can see what I implemented in here.
https://github.com/methane/cpython/pull/1/files
--
INADA Na
I've sent my patch to issue tracker, since I can't fix some remains
TODOs by myself.
http://bugs.python.org/issue27350
On Fri, Jun 17, 2016 at 6:15 PM, INADA Naoki wrote:
> Hi, developers.
>
> I'm trying to implement compact dict.
> https://github.com/methane/cpytho
>>
>> Finally, it seems someone is working on making all dicts ordered. Does that
>> mean this will soon be obsolete?
>
> Nope. Having an ordered definition namespace by default does not give
> us __definition_order__ for free. Furthermore, the compact dict under
> consideration isn't strictly or
On Tue, Jun 21, 2016 at 12:17 PM, Oleg Broytman wrote:
> Hi!
>
> On Tue, Jun 21, 2016 at 11:14:39AM +0900, INADA Naoki
> wrote:
>> Here is my draft, but I haven't
>> posted it yet since
>> my English is much worse than C.
>> https://www.dropbox.com/s/
_dict__.items()
dict_items([('a', 1), ('b', 2)])
>>> b.__dict__.items()
dict_items([('a', 4), ('b', 3)])
This doesn't affects to **kwargs and class namespace.
But if we change the language spec to dict preserves insertion order,
this should be add
On Wed, Jun 22, 2016 at 2:50 AM, Raymond Hettinger
wrote:
>
>> On Jun 21, 2016, at 10:18 AM, Guido van Rossum wrote:
>>
>> Judging from Inada's message there seems to be some confusion about how well
>> the compact dict preserves order (personally I think if it doesn't guarantee
>> order after
and harmless
change may cause
sudden memory usage increase. (__slots__ is more predicable).
On Wed, Jun 22, 2016 at 12:10 AM, INADA Naoki wrote:
> I'm sorry, but I hadn't realized which compact ordered dict is
> not ordered for split table.
>
> For example:
>>>> c
FYI, Here is calculated size of each dict by len(d).
https://docs.google.com/spreadsheets/d/1nN5y6IsiJGdNxD7L7KBXmhdUyXjuRAQR_WbrS8zf6mA/edit?usp=sharing
On Tue, Jun 21, 2016 at 12:17 PM, Oleg Broytman wrote:
> Hi!
>
> On Tue, Jun 21, 2016 at 11:14:39AM +0900, INADA Naoki
> wrote
hen all keys are interned already.
If we provide _PyDict_NewForNamespace to extension modules,
json decoder can have option to use this, too.
--
INADA Naoki
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/pytho
;
> Interned key only dict is still larger than key-shared dict.
>
> But it can be used for more purpose. It can be used for interning string
> for example. It can be used to kwargs dict when all keys are interned
> already.
>
> If we provide _PyDict_NewForNamespace
erhead.
If "orderd, except key sharing dict" is acceptable, no problem.
Key sharing compact dict is smaller than current key sharing dict of Python 3.5
for most cases.
https://docs.google.com/spreadsheets/d/1nN5y6IsiJGdNxD7L7KBXmhdUyXjuRAQR_WbrS8zf6mA/edit#gid=0
Regards,
--
INADA Naoki
tem 1:12.16elapsed 99%CPU (0avgtext+0avgdata
165884maxresident)k
480inputs+200792outputs (0major+56947minor)pagefaults 0swaps
71.84user 0.27system 1:12.13elapsed 99%CPU (0avgtext+0avgdata
166888maxresident)k
640inputs+200792outputs (5major+56834minor)pagefaults 0swaps
--
INADA
On Fri, Jun 24, 2016 at 12:03 AM, Eric Snow wrote:
> On Mon, Jun 20, 2016 at 11:02 PM, INADA Naoki wrote:
>> On Tue, Jun 21, 2016 at 12:17 PM, Oleg Broytman wrote:
>>> (if a PEP is needed at all)
>>
>> I don't think so. My PEP is not for changing Python Langua
pipermail/python-dev/2016-June/145391.html
Compact ordered dict is more efficient than key-sharing dict in case of Sphinx.
It means, instance __dict__ is not dominance.
I'll implement POC of my new idea and compare it with Sphinx.
If you know another good *real application*, which is ea
thub.com/methane/cpython/tree/interned-dict
(cb0a125c79 passes most tests, except tests using sys.getsizeof()).
--
INADA Naoki
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.py
On Sun, Jun 26, 2016 at 8:40 AM, Franklin? Lee
wrote:
> On Jun 21, 2016 11:12 AM, "INADA Naoki" wrote:
>>
>> I'm sorry, but I hadn't realized which compact ordered dict is
>> not ordered for split table.
>>
>> For example:
>> &
increase so
> much thanks to compact dict.
I did it. issue27350 is now ordered for key sharing dict, too.
--
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
>
> "PEP 520 -- Preserving Class Attribute Definition Order"
> https://www.python.org/dev/peps/pep-0520/
> => accepted -- what is the status of its implementation?
>
...
>
>
> I also see some discussions for even more compact dict implementation.
>
Here is implementation of the compact dict preser
>> propose and implement some changes prior to 3.6.0b1 and this discussion will
>> shape that proposal.
>>
>> I don't think OS X support should be a gating factor in deciding to move
>> ahead with C99 adoption but it does point ou
>>
>> * inline function
>> static inline function can be used instead of may macros.
>> It is more readable, and type safe.
>
> My experience from a few months ago with some cross-platform code is
> that clang, GCC and MSVC have different ideas about how inline
> functions in C work. Are they stati
https://morepypy.blogspot.jp/2015/01/faster-more-memory-efficient-and-more.html
--
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/ar
PI)
> * there are nice speedups
> * the C version of OrderedDict can be killed
> * it saves memory, on 64bit by quite a bit (not everyone stores more
> than 4bln items in a dictionary)
> * it solves the problem of tests relying on order in dictionaries
>
> In short, it has no d
>>
>> I've implemented compact and ordered dictionary [1], which PyPy
>> implemented in 2015 [2].
>
>
> Does this mean that keyword arguments will become ordered?
>
> Yury
>
Yes, regardless it will be language spec or just an implementation detail
like PyPy
Last call. There are only two weeks until 3.6 beta.
Please review it if possible.
On Tue, Aug 9, 2016 at 10:12 PM, INADA Naoki wrote:
> Hi, devs.
>
> I've implemented compact and ordered dictionary [1], which PyPy
> implemented in 2015 [2].
>
> Since it is my first large
gt;
> --
> --Guido van Rossum (python.org/~guido)
--
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
Thank you for all core devs!
I'll polish the implementation until 3.6b2.
On Fri, Sep 9, 2016 at 6:42 AM, Guido van Rossum wrote:
> It's in! Congrats, and thanks for your great work! See longer post by Victor.
>
> On Sun, Aug 28, 2016 at 12:16 AM, INADA Naoki wrote:
>>
On Tue, Sep 13, 2016 at 1:35 AM, Guido van Rossum wrote:
> Couldn't we use the order in the actual hash table (which IIUC now
> contains just indexes into the ordered vector of key/value/hash
> structs)? That would probably simulate the pre-3.6 order quite
> effectively.
Maybe, it can.
But curren
> From what I understood, Python 3.6 dict got two *different* changes:
>
> * modify the dict structure to use two tables instead of only one: an
> "index" table (the hash table) and a second key/value table
> * tune the dict implementation to only append to the key/value table
>
> The second change
>
> I mean using a compact representation, if not an ordered one.
>
> I have no particular usecase in mind. As far as I understand the compact
> implementation, sets can do it just as well. The original discussion
> proposed trying to implement it for sets first.
>
> Like dict, they would (probably
>
>
> Note that this is made at the expense of the 20% slowing down an iteration.
>
> $ ./python -m timeit -s "d = dict.fromkeys(range(10**6))" -- "list(d)"
> Python 3.5: 66.1 msec per loop
> Python 3.6: 82.5 msec per loop
>
>
Are two Pythons built with same options?
In my environ:
~/local/python
On Thu, Sep 15, 2016 at 5:57 PM Victor Stinner
wrote:
> 2016-09-15 10:02 GMT+02:00 INADA Naoki :
> > In my environ:
> >
> > ~/local/python-master/bin/python3 -m timeit -s "d =
> > dict.fromkeys(range(10**6))" 'list(d)'
>
> Stop! Please
On Tue, Sep 20, 2016 at 7:02 PM, INADA Naoki wrote:
> On Tue, Sep 20, 2016 at 6:56 PM, Dima Tisnek wrote:
>> Totally random thought:
>>
>> Can lru_cache be simplified to use an ordered dict instead of dict +
>> linked list?
>>
>
> I think so.
> S
es(m[:3])
'
Median +- std dev: 1.11 us +- 0.03 us
Proposed solution
===
Adding one more constructor to bytes:
# when length=-1 (default), use until end of *byteslike*.
bytes.frombuffer(byteslike, length=-1, offset=0)
With ths API
with memoryview
discussion.
> Regards,
> Nick.
>
> P.S. The length/offset API design is also problematic due to the way
> it differs from range() & slice(), but I don't think it makes sense to
> get into that kind of detail before discussing the larger question of
> adding a new h
On Wed, Oct 12, 2016 at 2:32 PM, Serhiy Storchaka wrote:
> On 12.10.16 07:08, INADA Naoki wrote:
>>
>> Sample code:
>>
>> def read_line(buf: bytearray) -> bytes:
>> try:
>> n = buf.index(b'\r\n')
>> excep
stream.py#L784-L817
When Tornado drop Python 2.7 support, they can use bytearray, and
iostream can be more simple and fast.
So I hope "amortized O(1) deletion from the front" is language spec,
at least for Python 3.5+
--
INADA Naoki
___
Py
om the buffer, and return the line. Let
> the caller explicitly convert when needed.
>
> --
> Terry Jan Reedy
>
Because it's public module API.
While bytearray is mostly API compatible (passes duck typing),
isinstance(b, bytes) is False when b is bytearray.
So, I feel changing
Py issue tracker.
https://bitbucket.org/pypy/pypy/issues/2367/del-bytearray-n-should-be-optimized
In case of micropython, it doesn't support deletion for now.
https://github.com/micropython/micropython/blob/b9672bcbe8dd29b61326af8eb026df4d10a8f0ce/py/objarray.
(Added python-dev in CC list, because there are enough +1 already).
On Mon, Oct 17, 2016 at 3:06 PM, Chris Angelico wrote:
> On Mon, Oct 17, 2016 at 5:02 PM, INADA Naoki wrote:
>> $ ./python.exe -V
>> Python 3.6.0b2+
>>
>> $ ./python.exe -VV
>> Python 3.6.0b2
>
> I agree with Barry. I'm open to adding this feature to 3.6.0b3 but
> first we need an issue and a final patch to review.
>
Here is the issue and patch. Could someone review it?
http://bugs.python.org/issue28532
--
INADA Naoki
_
6 libpython3.5m.so.1.0*
...
$ chmod u+w lib/libpython3.5m.so.1.0
$ bin/python3.5
Python 3.5.2+ (3.5:0ee76f3afd70, Nov 23 2016, 02:39:08)
[GCC 6.2.0 20161005] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> f = open
.python.org/issue19332
>
>
>
> ___
> 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
Hi.
IRC #python-dev channel is nice place to know what happens recently.
But I can't log in always because I use only laptop PC.
I found BotBot.me seems nice IRC log service and used by some major channels.
https://botbot.me/
I wonder if #python-dev is logged by BotBot.me.
I'm sorry if it had r
>
> bytes.frombuffer(x) is bytes(memoryview(x)) or memoryview(x).tobytes().
>
There is pitfall: memoryview should be closed.
So b = bytes.frombuffer(x) is:
with memoryview(x) as m:
b = bytes(m)
# or b = m.tobytes()
___
Python-Dev mailing list
Py
I submit an issue about it.
See https://bugs.python.org/issue29178
On Fri, Jan 6, 2017 at 7:38 PM, INADA Naoki wrote:
>>
>> Thinking more about this, and after looking at my own code in asyncpg and
>> uvloop, I'm now in favor of adding bytes.frombuffer() with th
>
> Thinking more about this, and after looking at my own code in asyncpg and
> uvloop, I'm now in favor of adding bytes.frombuffer() with the proposed
> signature: ``bytes.frombuffer(byteslike, length=-1, offset=0)``
>
Do you prefer a signature proposed first?
I thought it from asyncio usage too.
>> > with memoryview(x) as m:
>> > b = bytes(m)
>> > # or b = m.tobytes()
>>
>> Thinking more about this, and after looking at my own code in asyncpg
>> and uvloop, I'm now in favor of adding bytes.frombuffer() with the
>> proposed signature: ``bytes.frombuffer(byteslike, length=-1, offse
Hi.
---
This discussion is started in http://bugs.python.org/issue29259, and
there is separated issue at http://bugs.python.org/issue29260 .
But I want to see more comments, before issue 29259 is committed.
---
Since Python 3.6, some of C99 features are accepted in PEP 7.
"designated initializer"
On Wed, Jan 18, 2017 at 8:48 AM, Larry Hastings wrote:
>
> On 01/17/2017 12:02 PM, Steve Dower wrote:
>
> Avoiding header files would be my only request. As Brett says, the C99
> requirement should not be enforced on all embedders or extenders, so we
> should try and keep the headers they'll use a
On Wed, Jan 18, 2017 at 9:00 AM, Erik wrote:
> On 17/01/17 06:32, INADA Naoki wrote:
>>
>> With designated initializer, it becomes:
>>
>> 0, /* tp_free */
>> +.tp_fastcall = (fastternaryfunc)attrgetter_call,
>> };
Hi, all.
After reading Instagram's blog article [1], I’m thinking about how
Python can reduce memory usage of Web applications.
My company creating API server with Flask, SQLAlchemy and typing.
(sorry, it's closed source).
So I can get some data from it's codebase.
[1]:
https://engineering.insta
>
> "this script counts static memory usage. It doesn’t care about dynamic
> memory usage of processing real request"
>
> You may be trying to optimize something which is only a very small
> fraction of your actual memory footprint. That said, the marshal
> module could certainly try to intern som
On Fri, Jan 20, 2017 at 8:52 PM, Ivan Levkivskyi wrote:
> On 20 January 2017 at 11:49, INADA Naoki wrote:
>>
>> * typing may increase memory footprint, through functions
>> __attributes__ and abc.
>>* Can we add option to remove or lazy evaluate __attributes_
On Fri, Jan 20, 2017 at 8:17 PM, Victor Stinner
wrote:
> 2017-01-20 11:49 GMT+01:00 INADA Naoki :
>> Report is here
>> https://gist.github.com/methane/ce723adb9a4d32d32dc7525b738d3c31
>
> Very interesting report, thanks!
>
>> My thoughts are:
>>
>> * I
>
> Moving the refcount out of the PyObject will probably make increfs /
> decrefs more costly, and there are a lot of them. We'd have to see
> actual measurements if a patch is written, but my intuition is that the
> net result won't be positive.
>
> Regards
>
> Antoine.
I agree with you. But I
I've filed an issue about merging tuples: http://bugs.python.org/issue29336
I'll try the patch with my company's codebase again in next week.
But could someone try the patch with realworld large application too?
Or if you know OSS large application easy to install, could you share
requirements.tx
On Fri, Jan 20, 2017 at 8:52 PM, Ivan Levkivskyi wrote:
> On 20 January 2017 at 11:49, INADA Naoki wrote:
>>
>> * typing may increase memory footprint, through functions
>> __attributes__ and abc.
>>* Can we add option to remove or lazy evaluate __attributes_
On Mon, Jan 23, 2017 at 8:33 PM, Victor Stinner
wrote:
> 2017-01-23 12:25 GMT+01:00 INADA Naoki :
>> I gave advice to use 'List[User]' instead of List[User] to the team of
>> the project,
>> if the team think RAM usage or boot speed is important.
>
> I
>> So basically the equivalent of -OO for docstrings? Maybe this can be the
>> final motivator for some of us to come up with a design to generalize -O or
>> something as it keeps coming up.
> Yes, please. We've talked about generalizing this for years now. FWIW, I know
> of projects that run wi
> 3. I am -1 on ignoring annotations altogether. Sometimes they could be
> helpful at runtime: typing.NamedTuple and mypy_extensions.TypedDict are two
> examples.
ignoring annotations doesn't mean ignoring typing at all.
You can use typing.NamedTuple even when functions doesn't have __annotations_
FWIW, I tried to skip compiler_visit_annotations() in Python/compile.c
a) default: 41278060
b) remove annotations: 37140094
c) (b) + const merge: 35933436
(a-b)/a = 10%
(a-c)/a = 13%
And here are top 3 tracebacks from tracemalloc:
15109615 (/180598)
File "", line 488
File
On Tue, Jan 24, 2017 at 11:08 PM, Victor Stinner
wrote:
> 2017-01-24 15:00 GMT+01:00 INADA Naoki :
>> And here are top 3 tracebacks from tracemalloc:
>>
>> 15109615 (/180598)
>> File "", line 488
>> File "", line 780
>> File &q
More detailed information:
## With annotations
=== tracemalloc stat ===
traced: (46969277, 46983753)
18,048,888 / 181112
File "", line 488
File "", line 780
File "", line 675
=== size by types ===
dict 9,083,816 (8,870.91KB) / 21846 = 415.811bytes (21.38%)
tuple
On Thu, Jan 26, 2017 at 2:33 AM, Antoine Pitrou wrote:
> On Wed, 25 Jan 2017 20:54:02 +0900
> INADA Naoki wrote:
>>
>> ## Stripped annotation + without pydebug
>
> Does this mean the other measurements were done with pydebug enabled?
> pydebug is not meant to be us
b.com/python/typing/pull/383
> It should reduce the memory consumption significantly (and also increase
> isinstance() speed).
> Could you please try it with your real code base and test memory consumption
> (and maybe speed) as compared to master?
>
> --
> Ivan
>
>
>
As reading [4], mtime is not 0.
data = bytearray(MAGIC_NUMBER)
data.extend(_w_long(mtime))
data.extend(_w_long(source_size))
data.extend(marshal.dumps(code))
First 4 bytes are magic.
Next 4 bytes are mtime.
│ │ │ │ -: 160d 0d0a 6b2e 9c58 6c21 e300 k..Xl!
to be sets.
Maybe, PYTHONHASHSEED help you.
https://docs.python.org/3/using/cmdline.html#envvar-PYTHONHASHSEED
>
> On Thu, Feb 9, 2017 at 6:04 PM, INADA Naoki wrote:
>>
>> As reading [4], mtime is not 0.
>>
>> data = bytearray(MAGIC_NUMBER)
>> data.extend(
On Fri, Feb 10, 2017 at 7:58 PM, Freddy Rietdijk
wrote:
> For Python 3.5 PYTHONHASHSEED doesn't seem to be sufficient, these items
> still seem indeterministic.
> To be sure, I ran `PYTHONHASHSEED=1 $out/bin/python -m compileall -f $out`
> where $out is the path where I installed Python.
>
> Do yo
> Where should these translated docs live and how does one make it clear to
> users reading them that doc bugs shouldn't be submitted to the main bug
> tracker/github repo?
>
We setup github page. See https://python-doc-ja.github.io/py36/ (note that
version switcher won't work because this html i
Thanks, Victor and all.
This thread is very encouraging for me.
Currently, I have a suspended pull request:
https://github.com/python/cpython/pull/195
This pull request (1) fixes "CPython implementation detail:" label is
disappear when it's body is translated, and
(2) make the label translatable.
On Fri, Feb 24, 2017 at 9:20 PM, Berker Peksağ wrote:
> On Thu, Feb 23, 2017 at 12:01 AM, Victor Stinner
> wrote:
>> 2017-02-22 19:04 GMT+01:00 Serhiy Storchaka :
>>> What percent of lines is changed between bugfix releases? Feature releases?
>>>
>>> My largest apprehension is that the documentat
Yes, right place to discussion is one of important things what I want.
I haven't know about i18n-sig. Is it better than docs-sig?
Another thing I want is agreement to use project name looks like
(semi)official project.
We used "python-doc-jp" name on Transifex at first. But since some people
o
On Thu, Mar 2, 2017 at 4:07 AM, Antoine Pitrou wrote:
> On Wed, 1 Mar 2017 19:58:14 +0100
> Matthias Klose wrote:
>> On 01.03.2017 18:51, Antoine Pitrou wrote:
>> > As for the high level: what if the training set used for PGO in Xenial
>> > has become skewed or inadequate?
>>
>> running the tests
LGTM and I love this PEP and PEP 540.
Some comments:
...
> * PEP 540 proposes to entirely decouple CPython's default text encoding from
> the C locale system in that case, allowing text handling inconsistencies
> to
> arise between CPython and other C/C++ components running in the same
> pro
> It seems to based on an assumption that the C locale is always some kind of
> pathology. Admittedly, it sometimes is a result of misconfiguration or a
> mistake. (But I don't see why it's the interpreter's job to correct such
> mistakes.) However, in some cases the C locale is a normal environmen
On Mon, Mar 13, 2017 at 8:01 PM, Nick Coghlan wrote:
> On 13 March 2017 at 18:37, INADA Naoki wrote:
>>
>> But locale coercing works nice on platforms like android.
>> So how about simplified version of PEP 538? Just adding configure
>> option for locale coercing
>
On Mon, Mar 13, 2017 at 10:31 PM, Random832 wrote:
> On Mon, Mar 13, 2017, at 04:37, INADA Naoki wrote:
>> But locale coercing works nice on platforms like android.
>> So how about simplified version of PEP 538? Just adding configure
>> option for locale coercing
>> w
There is already http://bugs.python.org/issue29642
On Thu, Mar 23, 2017 at 11:04 PM, Ilya Kazakevich
wrote:
> Hello.
> I have following layout:
>
> \---tests
> | test_module.py
> | __init__.py
>
>
> When I launch "python.exe" -m unittest discover -t . -s tests" it works
> perfectly.
>
hes normal directly, it may walk deep into very
large tree containing
millions of directories. I don't like it.
On Fri, Mar 24, 2017 at 12:53 AM, INADA Naoki wrote:
> There is already http://bugs.python.org/issue29642
>
> On Thu, Mar 23, 2017 at 11:04 PM, Ilya Kazakevich
> wrote:
&g
Hi.
Currently, changelog of Python 3.7a1 [1] contains changes between
3.6b1 and 3.7a1.
So lot's of bugfixes are listed twice or more in changelog.
For example, "bpo-28258: Fixed build with Estonian locale..." are
listed under 3.5.3rc1,
3.6.0b2 and 3.7.0a1.
[1] https://docs.python.org/3.7/whatsnew
On Tue, Mar 28, 2017 at 11:07 PM, Ned Deily wrote:
> On Mar 28, 2017, at 08:49, INADA Naoki wrote:
>> Currently, changelog of Python 3.7a1 [1] contains changes between
>> 3.6b1 and 3.7a1.
>> So lot's of bugfixes are listed twice or more in changelog.
>> For examp
301 - 400 of 538 matches
Mail list logo
