17.07.13 00:09, victor.stinner написав(ла):
http://hg.python.org/cpython/rev/533eb9ab895a
changeset: 84669:533eb9ab895a
user:Victor Stinner
date:Tue Jul 16 21:36:02 2013 +0200
summary:
Issue #18408: Fix fileio_read() on _PyBytes_Resize() failure
bytes is NULL on _PyBytes_Re
17.07.13 01:03, Victor Stinner написав(ла):
2013/7/16 Serhiy Storchaka :
http://hg.python.org/cpython/rev/533eb9ab895a
summary:
Issue #18408: Fix fileio_read() on _PyBytes_Resize() failure
bytes is NULL on _PyBytes_Resize() failure
Why not Py_DECREF?
Because Py_DECREF(NULL) does crash
16.07.13 20:21, Guido van Rossum написав(ла):
The situation is most egregious if the target string is a bytearray,
where there is currently no way to get the result as an immutable
bytes object without an extra copy. (There's no API that lets you
create a bytes object directly from a slice of a b
What type of dash is preferable in the documentation? The en dash (–) or
the em dash (—)?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-d
18.07.13 20:48, Guido van Rossum написав(ла):
I believe there are only a few places where en-dashes should be used,
for most things you should use either em-dash or hyphen. Consult your
trusted typography source (for US English, please, punctuation
preferences vary by locale). E.g. Google for "em
18.07.13 21:54, Brian Curtin написав(ла):
Besides visual consistency in a couple of places, is there a reason to
care enough to make a wholesale change?
Single hyphen instead of a dash just looks too ugly to me.
Trying to fix this I noticed that the documentation is inconsistent
regarding the
18.07.13 21:55, Guido van Rossum написав(ла):
On Thu, Jul 18, 2013 at 11:46 AM, Serhiy Storchaka wrote:
Or we should replace a half-dozen of em-dashes found in Python documentation
to en-dashes?
If my theory is right that makes sense. Especially if it's only a half-dozen.
I'm sor
19.07.13 00:49, Ezio Melotti написав(ла):
On Thu, Jul 18, 2013 at 7:38 PM, Serhiy Storchaka wrote:
What type of dash is preferable in the documentation? The en dash (–) or the
em dash (—)?
Both should be used where appropriate [0].
Of course I looked in Wikipedia before asking on this
19.07.13 10:25, Ben Finney написав(ла):
Serhiy Storchaka writes:
What type of dash is preferable in the documentation? The en dash (–)
or the em dash (—)?
They have different purposes; use whichever is appropriate for the
context.
I mean only a context where a dash is used to denote a
19.07.13 07:51, Steven D'Aprano написав(ла):
Optimistically, I think it would probably be safe[1] to replace " -- "
or " --- " in text with "\N{THIN SPACE}\N{EM DASH}\N{THIN SPACE}" (or
\N{HAIR SPACE} if you prefer) without human review, but for any other
changes, I wouldn't even try to automate
19.07.13 22:32, Ben Finney написав(ла):
Serhiy Storchaka writes:
I'm asking only about this case, when the dash is used to denote a
break in a sentence or to set off parenthetical statements.
That's two separate cases:
* denote a break in a sentence
* set off parenthetical state
20.07.13 15:12, christian.heimes написав(ла):
http://hg.python.org/cpython/rev/c92f4172d122
changeset: 84723:c92f4172d122
user:Christian Heimes
date:Sat Jul 20 14:11:28 2013 +0200
summary:
Use strncat() instead of strcat() to silence some warnings.
CID 486616, CID 486617, CI
20.07.13 15:36, Antoine Pitrou написав(ла):
On Sat, 20 Jul 2013 15:23:46 +0300
Serhiy Storchaka wrote:
20.07.13 15:12, christian.heimes написав(ла):
http://hg.python.org/cpython/rev/c92f4172d122
changeset: 84723:c92f4172d122
user:Christian Heimes
date:Sat Jul 20 14:11:28
20.07.13 16:27, Christian Heimes написав(ла):
This will wrong when strlen(fname) is 30. strncat() will copy only 30
bytes, without terminal NUL.
That's not how strncat() works. strncat(dest, src, n) writes n+1 chars
to the end of dest: n chars from src and +1 for the final NUL char. For
this re
I have opened an issue (http://bugs.python.org/issue18529) for patches.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-a
Some tests uses the following idiom:
def test_main():
try:
test.support.run_unittest(...)
finally:
test.support.reap_children()
Other tests uses the following idiom:
def test_main():
key = test.support.threading_setup()
try:
test.support.run_unittest(...)
12.08.13 22:22, Brett Cannon написав(ла):
I have created http://bugs.python.org/issue18716 to deprecate the
formatter module for removal in Python 3.6 unless someone convinces me
otherwise that deprecation and removal is the wrong move.
The formatter module doesn't look such buggy as the audioo
15.08.13 01:07, Ethan Furman написав(ла):
From http://bugs.python.org/issue18738:
Actually the problem not only in IntEnum, but in any in subclass.
Currently for empty format specifier int.__format__(x, '') returns
str(x). But __str__ can be overloaded in a subclass. I think that for
less s
15.08.13 06:23, Eli Bendersky написав(ла):
Yes, the problem here is certainly not IntEnum - specific; it's just
that IntEnum is the first "for real" use case of subclassing 'int' in
the stdlib.
Even not the first.
>> '{}'.format(True)
'True'
>>> '{:10}'.format(True)
' 1'
22.08.13 02:59, victor.stinner написав(ла):
http://hg.python.org/cpython/rev/0a1e1b929665
changeset: 85308:0a1e1b929665
user:Victor Stinner
date:Thu Aug 22 01:58:12 2013 +0200
summary:
Cleanup test_builtin
files:
Lib/test/test_builtin.py | 16
1 files
22.08.13 14:48, Victor Stinner написав(ла):
You forgot self.addCleanup(unlink, TESTFN) (here and in other places).
These functions call write_testfile() which creates the file but also
schedules its removal when the test is done (since my changeset):
def write_testfile(self):
# N
28.08.13 14:37, Victor Stinner написав(ла):
No, my question is: how can we detect that a test is never run? Do we
need test covertage on the test suite? Or inject faults in the code to
test the test suite? Any other idea?
Currently a lot of tests are skipped silently. See issue18702 [1].
Perha
08.09.13 20:52, Guido van Rossum написав(ла):
Well, to me zip(*x) is unnatural, and it's inefficient when the arrays are long.
Perhaps we need zip.from_iterable()?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/lis
There is a question about specifying the transform function.
There are three ways to do this:
1. Positional argument of the constructor.
d = TransformDict(str.casefold, Foo=5)
2. Subclassing.
class CaseInsensitiveDict(TransformDict):
def transform(self, key):
return key.casefold()
I work on enhancement of audio modules testing [1], and I need free (in
both senses) small sample audio files in different formats. We already
have audiotest.au (mono, and sunau has a bug in processing multichannel
files [2]) and Sine-1000Hz-300ms.aif, but this is not enough. I have
generated a
11.09.13 12:52, Antoine Pitrou написав(ла):
Le Wed, 11 Sep 2013 12:38:13 +0300,
Serhiy Storchaka a écrit :
2. Subclassing.
class CaseInsensitiveDict(TransformDict):
def transform(self, key):
return key.casefold()
d = CaseInsensitiveDict(Foo=5)
I thought about this first, and
11.09.13 14:07, Antoine Pitrou написав(ла):
But I don't think the "type generator" API would be easier to implement
in C, anyway.
No, I mean subclassing approach.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/list
11.09.13 16:50, Stephen J. Turnbull написав(ла):
Which modules in the stdlib would benefit from rewriting using
"transformdict"? How about on PyPI?
At least _threading_local, cProfile, doctest, json, and perhaps future
implementations of __sizeof__ for some classes would benefit from
rewriti
11.09.13 15:45, Antoine Pitrou написав(ла):
If you want to edit, shorten, convert sounds between different formats,
you can try Audacity, a free sound editor:
http://audacity.sourceforge.net/
Yes, Audacity is great.
___
Python-Dev mailing list
Pytho
11.09.13 15:46, Victor Stinner написав(ла):
Use your microphone, say "python" and save the file in your favorite
file format. Try for example Audacity. I suppose that you don't need
specific audio content and you don't need a huge file.
My voice is even more ugly than my English. I don't want p
11.09.13 17:10, Oleg Broytman написав(ла):
Wouldn't his name be enough? http://www.python.org/~guido/guido.au
It is Lib/test/audiotest.au. 1-channel and 8-bit. No, it wouldn't enough.
___
Python-Dev mailing list
Python-Dev@python.org
https://mai
11.09.13 17:10, Barry Warsaw написав(ла):
I have some pro-audio recording capabilities and would be happy to generate
some copyright-donated clips for Python. Please contact me off-list if
needed.
Thank you.
___
Python-Dev mailing list
Python-Dev@p
13.09.13 21:40, Antoine Pitrou написав(ла):
Both are instances of a more general pattern, where a given
transformation function is applied to keys when looking them up: that
function being ``str.lower`` in the former example and the built-in
``id`` function in the latter.
Please use str.casefol
13.09.13 21:40, Antoine Pitrou написав(ла):
Alternative proposals and questions
===
Yet one alternative proposal is to add the dict.__transform__() method.
Actually this not contradict TransformDict, but generalize it.
TransformDict will be just handly interfac
13.09.13 23:02, Antoine Pitrou написав(ла):
On Fri, 13 Sep 2013 16:54:01 -0300
"Joao S. O. Bueno" wrote:
I see the PEP does not contemplate a way to retrieve the original key
- like we've talked about somewhere along the thread.
Indeed. If that's important I can add it. I was hoping to keep v
13.09.13 22:37, Antoine Pitrou написав(ла):
That's true. But it's only important if TransformDict is the
bottleneck. I doubt the memoizing dictionary is a bottleneck in
e.g. the pure Python implementation of pickle or json.
It can be used in the C implementation.
_
13.09.13 23:21, Antoine Pitrou написав(ла):
On Fri, 13 Sep 2013 23:16:10 +0300
Serhiy Storchaka wrote:
13.09.13 21:40, Antoine Pitrou написав(ла):
Alternative proposals and questions
===
Yet one alternative proposal is to add the dict.__transform__() method
14.09.13 20:41, Antoine Pitrou написав(ла):
On Sat, 14 Sep 2013 09:43:13 -0700
Ethan Furman wrote:
Still, I think it would be useful to expose the transform function.
Any good reason not to?
No good reason. What's the name? transform_func?
There is one reason -- serialization. For example p
14.09.13 20:41, Antoine Pitrou написав(ла):
No good reason. What's the name? transform_func?
transform_func looks... truncated. Why not transform_function or trans_func?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailma
15.09.13 00:58, Antoine Pitrou написав(ла):
On Sun, 15 Sep 2013 00:55:35 +0300
Serhiy Storchaka wrote:
14.09.13 20:41, Antoine Pitrou написав(ла):
No good reason. What's the name? transform_func?
transform_func looks... truncated. Why not transform_function or trans_func?
The s
15.09.13 14:23, Antoine Pitrou написав(ла):
On Sun, 15 Sep 2013 13:56:26 +0900
Larry Hastings wrote:
On 09/14/2013 07:30 PM, Antoine Pitrou wrote:
On Sat, 14 Sep 2013 14:33:56 +0900
Larry Hastings wrote:
Whenever I read a discussion about the dict, I always wonder whether the
same thing appl
15.09.13 16:57, Antoine Pitrou написав(ла):
I don't really care. What's the point in the end? TransformDict is
non-trivial to implement, while the so-called "TransformSet" is just a
dict with a different API.
I don't see a difference. To me TransformDict is just a dict (or two).
_
02.10.13 20:31, Antoine Pitrou написав(ла):
On Wed, 2 Oct 2013 18:16:48 +0200 (CEST)
serhiy.storchaka wrote:
http://hg.python.org/cpython/rev/d48ac94e365f
changeset: 85931:d48ac94e365f
user:Serhiy Storchaka
date:Wed Oct 02 19:15:54 2013 +0300
summary:
Use cached builtins
Just some comments.
> the first time time with a bit shift of 7
Double "time".
> with a 128bit seed and 64-bit output
Inconsistancy with hyphen. There are same issues in other places.
> bytes_hash provides the tp_hash slot function for unicode.
Typo. Should be "unicode_hash".
> len = PyUnic
03.10.13 23:47, Guido van Rossum написав(ла):
On Thu, Oct 3, 2013 at 12:55 PM, Christian Heimes mailto:christ...@python.org>> wrote:
Am 03.10.2013 21:45, schrieb Guido van Rossum:
> But fixing that shouldn't need all the extra stuff you're
> proposing.
I have proposed some of
Please remember me, what was common decision about CPython-only
optimizations which change computation complexity? I.g. constant
amortization time of += for byte objects and strings, or linear time of
sum() for sequences?
___
Python-Dev mailing list
05.10.13 23:11, Georg Brandl написав(ла):
Am 05.10.2013 21:42, schrieb Serhiy Storchaka:
Please remember me, what was common decision about CPython-only
optimizations which change computation complexity? I.g. constant
amortization time of += for byte objects and strings, or linear time of
sum
06.10.13 00:08, Victor Stinner написав(ла):
2013/10/4 Raymond Hettinger >:
> This contrasts with other tools like OrderedDict, ChainMap,
> and namedtuple which started their lives outside the standard
> library where we we able observe their fitness for real problems
> being solved by real us
06.10.13 00:06, Victor Stinner написав(ла):
The str type is immutable, bytearray is not. It's easier to justify
optimisations on mutable types, like overallocate lists for example.
We can resize str or bytes if its refcount is 1. And resize is cheap in
some circumstances. This optimization is
06.10.13 02:37, Antoine Pitrou написав(ла):
It's only strange because you don't understand the main use case for
bytearrays. They may look like arrays of 8-bit integers but they are
really used for buffers, so optimizing for stuff like FIFO operation
makes sense.
Could you please provide severa
07.10.13 16:54, A.M. Kuchling написав(ла):
On Mon, Oct 07, 2013 at 12:13:18AM +0100, Michael Foord wrote:
Wing is only a good example of PyGtk until Wing 5 is out of beta. They too
have switched to PyQt...
Perhaps Gramps is a good example: http://www.gramps-project.org/ I
just glanced at their
10.10.13 15:25, Christian Heimes написав(ла):
Benchmark of 1000 times "python -c ''"
What about "python -S -c ''"?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.pytho
11.10.13 13:33, Eric V. Smith написав(ла):
And Antoine has again taught me a new word:
polysemic: having more than one meaning; having multiple meanings
There is no such word in my dictionaries. :( Only polysemous and
polysemantic.
___
Python-Dev m
11.10.13 10:24, Antoine Pitrou написав(ла):
Ezio was -1 on the tracker, and Eric Smith was -0. I'd like to add my
-1 too. This is a useless addition (the traditional idiom is perfectly
obvious) and makes reading foreign code more tedious by adding
superfluous API calls.
I am -1 too. But I want
11.10.13 21:41, Glenn Linderman написав(ла):
Seriously, "with" is the wrong spelling for this using. It should be
while ignorning(FileNotFoundError)
We need extended bool for while condition:
http://thedailywtf.com/Articles/What_Is_Truth_0x3f_.aspx
__
12.10.13 21:04, Georg Brandl написав(ла):
in light of the recent thread about PEPs not forming part of the docs,
I've just pushed a change that allows to document C API elements
not part of the limited API as such. It is done like this:
... c:function:: int _PyTuple_Resize(PyObject **p, Py_ssiz
12.10.13 22:19, Georg Brandl написав(ла):
Am 12.10.2013 20:20, schrieb Serhiy Storchaka:
12.10.13 21:04, Georg Brandl написав(ла):
in light of the recent thread about PEPs not forming part of the docs,
I've just pushed a change that allows to document C API elements
not part of the limite
12.10.13 22:56, Antoine Pitrou написав(ла):
On Sat, 12 Oct 2013 21:19:16 +0200
Georg Brandl wrote:
Am 12.10.2013 20:20, schrieb Serhiy Storchaka:
12.10.13 21:04, Georg Brandl написав(ла):
in light of the recent thread about PEPs not forming part of the docs,
I've just pushed a change
13.10.13 15:50, Nick Coghlan написав(ла):
On 13 October 2013 22:34, Antoine Pitrou wrote:
There's actually more typing involved, and one more API to know about...
It is just another case of those "one-liners" that we generally refrain
from adding to the stdlib.
It meets my threshold for inclu
13.10.13 13:39, Christian Heimes написав(ла):
Am 13.10.2013 08:32, schrieb Nick Coghlan:
+1 to hashlib from me (especially since we used that as the best
available home for compare_digest).
I'm afraid your memory doesn't serve you well. :(
compare_digest is implemented in _operator.c. Its offi
14.10.13 13:07, Antoine Pitrou написав(ла):
Le Mon, 14 Oct 2013 12:47:03 +0300,
Serhiy Storchaka a écrit :
13.10.13 13:39, Christian Heimes написав(ла):
Am 13.10.2013 08:32, schrieb Nick Coghlan:
+1 to hashlib from me (especially since we used that as the best
available home for
15.10.13 15:55, Larry Hastings написав(ла):
So, quick poll: do you approve of me checking Argument Clinic in to
Python 3.4 trunk in its current state before 3.4a4?
Could you get us a week for preliminary review before checking? I
remember I proposed a little different syntax and I don't know w
On 07.06.16 20:51, Eric Snow wrote:
Hi all,
Following discussion a few years back (and rough approval from Guido
[1]), I started work on using OrderedDict for the class definition
namespace by default. The bulk of the effort lay in implementing
OrderedDict in C, which I got landed just in time
On 07.06.16 23:28, Ethan Furman wrote:
Minor changes: updated version numbers, add punctuation.
The current text seems to take into account Guido's last comments.
Thoughts before asking for acceptance?
PEP: 467
Title: Minor API improvements for binary sequences
Version: $Revision$
Last-Modi
On 08.06.16 11:04, Victor Stinner wrote:
Currently, the ``bytes`` and ``bytearray`` constructors accept an integer
argument and interpret it as meaning to create a zero-initialised sequence
of the given size::
(...)
This PEP proposes to deprecate that behaviour in Python 3.6, and remove it
entire
On 08.06.16 02:03, Nick Coghlan wrote:
That said, it occurs to me that there's a reasonably strong
composability argument in favour of a view-based approach: a view will
work with operator.itemgetter() and other sequence consuming APIs,
while special methods won't. The "like-memoryview-but-not" v
On 08.06.16 13:37, Paul Sokolovsky wrote:
The obvious way to create the bytes object of length n is b'\0' * n.
That's very inefficient: it requires allocating useless b'\0', then a
generic function to repeat arbitrary memory block N times. If there's a
talk of Python to not be laughed at for be
On 08.06.16 14:26, Paul Sokolovsky wrote:
On Wed, 8 Jun 2016 14:05:19 +0300
Serhiy Storchaka wrote:
On 08.06.16 13:37, Paul Sokolovsky wrote:
The obvious way to create the bytes object of length n is b'\0' *
n.
That's very inefficient: it requires allocating useless b'
There is a design question. If you read file in some format or with some
protocol, and the data is ended unexpectedly, when to use general
EOFError exception and when to use format/protocol specific exception?
For example when load truncated pickle data, an unpickler can raise
EOFError, Unpick
On 22.06.16 00:17, Victor Stinner wrote:
When loading truncated data with pickle, I expect a pickle error, not a
generic ValueError nor EOFError.
Many modules raise EOFError when read truncated data.
___
Python-Dev mailing list
Python-Dev@python.org
On 22.06.16 19:22, André Malo wrote:
I often concatenate multiple pickles into one file. When reading them, it
works like this:
try:
while True:
yield pickle.load(fp)
except EOFError:
pass
In this case the truncation is not really unexpected. Maybe it should
distinguish betwe
On 09.08.16 00:59, Chris Angelico wrote:
class TooSimpleContextManager:
"""Now this time you've gone too far."""
def __init__(self, func):
self.func = func
def __call__(self):
self.gen = self.func()
return self
def __enter__(self):
next(self.gen)
On 28.08.16 01:25, Terry Reedy wrote:
0. Do nothing.
The problem is not in pathological __index__. The problem is in
executing Python code and releasing GIL. In multithread production code
one thread can read a slice when other thread modifies a collection. In
very very rare case it causes a
On 30.08.16 15:31, Dima Tisnek wrote:
On 30 August 2016 at 14:13, Serhiy Storchaka wrote:
1. Detect length change and raise.
It would be simpler solution. But I afraid that this can break third-party
code that "just works" now. For example slicing a list "just works"
On 30.08.16 21:20, Antoine Pitrou wrote:
On Tue, 30 Aug 2016 18:12:01 +
Brett Cannon wrote:
Why not make it always a list? List objects are reasonably cheap in
memory and access time... (unlike dicts)
Because I would prefer to avoid any form of unnecessary performance
overhead for the co
On 30.08.16 20:42, Nick Coghlan wrote:
On 28 August 2016 at 08:25, Terry Reedy wrote:
Slicing can be made to malfunction and even crash with an 'evil' __index__
method. https://bugs.python.org/issue27867
The crux of the problem is this: PySlice_GetIndicesEx
receives a slice object and a sequen
On 07.09.16 07:21, Eric V. Smith wrote:
The implementation of '_' in numeric literals is here:
http://bugs.python.org/issue26331
And to add '_' in int.__format__ is here:
http://bugs.python.org/issue27080
But I don't want to add support in int.__format__ unless numeric literal
support is added.
On 01.09.16 22:36, Ethan Furman wrote:
* Add ``bytes.iterbytes`` and ``bytearray.iterbytes`` alternative iterators
Could you please add a mention of alternative: seqtools.chunks()?
seqtools.chunks(bytes, 1) and seqtools.chunks(bytearray, 1) should be
equivalent to bytes.iterbytes() and bytear
On 12.09.16 11:41, Victor Stinner wrote:
2016-09-12 8:23 GMT+02:00 Benjamin Peterson :
That seems like a good idea in abstract. However, the boundaries will
have to be delineated. Many functions beginning _Py are effectively part
of the public API even for "well-behaved" 3rd-party extensions
O
On 08.09.16 23:22, Victor Stinner wrote:
I pushed INADA Naoki's implementation of the "compact dict". The hash
table now stores indices pointing to a new second table which contains
keys and values: it adds one new level of indirection. The table of
indices is "compact": use 1, 2, 4 or 8 bytes pe
On 14.09.16 17:36, Guido van Rossum wrote:
Fortunately that page isn't linked from anywhere on the home page
AFAIK. If it is, could someone file an issue in the pydotorg tracker?
The url is at the bottom of every page.
This is on of the first results (actually the first besides manually
edited
On 15.09.16 11:02, INADA Naoki wrote:
Are two Pythons built with same options?
Both are built from clean checkout with default options (hg update -C
3.x; ./configure; make -s). The only difference is -std=c99 and
additional warnings in 3.6:
Python 3.5:
gcc -pthread -c -Wno-unused-result -Ws
On 15.09.16 11:57, Victor Stinner wrote:
Stop! Please stop using timeit, it's lying!
* You must not use the minimum but average or median
* You must run a microbenchmark in multiple processes to test
different randomized hash functions and different memory layouts
In short: you should use m
On 15.09.16 12:43, Raymond Hettinger wrote:
On Sep 14, 2016, at 11:31 PM, Serhiy Storchaka wrote:
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 l
On 15.09.16 19:13, Antoine Pitrou wrote:
Since this micro-benchmark creates the keys in order just before
filling the dict with them, randomizing the insertion order destroys
the temporal locality of object header accesses when iterating over the
dict keys. *This* looks like the right explanation
On 15.09.16 09:48, Berker Peksağ wrote:
Fixed, it should redirect to https://www.python.org/blogs/ now. Thanks
for noticing this!
Thanks Berker!
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Un
On 03.10.16 16:37, Skip Montanaro wrote:
I'm sure this has a simple explanation (and is probably only of
historical interest at this point), but ...
While starting to port the Python Sybase module to Python 3, among other
hurdles, I noticed that RO is no longer defined. Looking in
structmember.h
A number of builtin iterator classes (but not all builtin iterator
classes) are registered with the Iterator ABC in
Lib/_collections_abc.py. But isinstance(it, Iterable) check works
without explicit registration, because Iterable has __subclasshook__
that checks iterator methods. Is there a n
On 07.10.16 17:37, Guido van Rossum wrote:
On Fri, Oct 7, 2016 at 6:36 AM, Serhiy Storchaka wrote:
A number of builtin iterator classes (but not all builtin iterator classes)
are registered with the Iterator ABC in Lib/_collections_abc.py. But
isinstance(it, Iterable) check works without
On 07.10.16 18:08, Guido van Rossum wrote:
On Fri, Oct 7, 2016 at 7:47 AM, Serhiy Storchaka wrote:
Should we register missed builtin iterators? For example longrange_iterator.
I don't feel strongly about this either way. Let sleeping dogs lie,
etc. (Is this related to issue 26906?)
Since dict is ordered in CPython 3.6, it can be used instead of
OrderedDict in some places (e.g. for implementing simple limited
caches). But since this is implementation detail, it can't be used in
the stdlib unconditionally. Needed a way to check whether dict is ordered.
Actually there are t
On 12.10.16 07:08, INADA Naoki wrote:
Sample code:
def read_line(buf: bytearray) -> bytes:
try:
n = buf.index(b'\r\n')
except ValueError:
return b''
line = bytes(buf)[:n] # bytearray -> bytes -> bytes
Wouldn't be more correct to write this
On 12.10.16 08:03, Nathaniel Smith wrote:
On Tue, Oct 11, 2016 at 9:08 PM, INADA Naoki wrote:
From Python 3.4, bytearray is good solution for I/O buffer, thanks to
#19087 [1].
Actually, asyncio uses bytearray as I/O buffer often.
Whoa what?! This is awesome, I had no idea that bytearray had O
On 12.10.16 09:31, Nathaniel Smith wrote:
But amortized O(1) deletes from the front of bytearray are totally
different, and more like amortized O(1) appends to list: there are
important use cases[1] that simply cannot be implemented without some
feature like this, and putting the implementation i
On 13.10.16 00:14, Nathaniel Smith wrote:
AFAIK basically the only project that would be affected by this is
PyPy,
And MicroPython.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
h
On 20.10.16 13:56, Victor Stinner wrote:
Last months, I worked a lot on benchmarks. I ran benchmarks, analyzed
results in depth (up to the hardware and kernel drivers!), I wrote new
tools and enhanced existing tools.
Great work! Thank you Victor.
__
Classes that doesn't define the __format__ method for custom PEP 3101
formatting inherits it from parents.
Originally the object.__format__ method was designed as [1]:
def __format__(self, format_spec):
return format(str(self), format_spec)
An instance is converted to string and re
On 27.10.16 02:44, Eric V. Smith wrote:
But on the other hand, the existing behavior is well specified and has
been around since object.__format__ was added. I'm not sure it needs
changing. What's the harm in leaving it?
More complicated code. And maybe this behavior is less intuitive. It
cont
On 27.10.16 19:59, Steve Dower wrote:
Having the default __format__ behave like this makes me happiest:
def __format__(self, fmt):
return format(str(self), fmt)
My 2c. YMMV. etc.
See issue7994 [1] for arguments against this.
[1] http://bugs.python.org/issue7994
__
On 28.11.16 09:06, Benjamin Peterson wrote:
I've have just updated PEP 373 to say that Python 2.7.13 release
candidate 1 will be released on December 3. The final will follow two
weeks later on December 17. If there are delays in the process, the
final will likely to pushed into January.
Could
701 - 800 of 1152 matches
Mail list logo
