Re: [Python-Dev] LZO bug
On Jun 27, 2014, at 9:56 AM, MRAB wrote:> Is this something that we need to worry about?> > Raising Lazarus - The 20 Year Old Bug that Went to Mars> http://blog.securitymouse.com/2014/06/raising-lazarus-20-year-old-bug-that.html Debunking the LZ4 "20 years old bug" myth http://fastcompres
Re: [Python-Dev] == on object tests identity in 3.x
On Jul 7, 2014, at 4:37 PM, Andreas Maier wrote:> I do not really buy into the arguments that try to show how identity and > value are somehow the same. They are not, not even in Python.> > The argument I can absolutely buy into is that the implementation cannot be > changed within a major
Re: [Python-Dev] sum(...) limitation
On Aug 8, 2014, at 11:09 AM, Ethan Furman wrote:>> So why not apply a similar optimization to sum() for strings?> > That I cannot answer -- I find the current situation with sum highly > irritating.> It is only irritating if you are misusing sum(). The str.__add__ optimization was put in
Re: [Python-Dev] PEP 467: Minor API improvements for bytes & bytearray
On Aug 14, 2014, at 10:50 PM, Nick Coghlan wrote:> Key points in the proposal:> > * deprecate passing integers to bytes() and bytearray() I'm opposed to removing this part of the API. It has proven useful and the alternative isn't very nice. Declaring the size of fixed length arrays is no
Re: [Python-Dev] PEP 467: Minor API improvements for bytes & bytearray
On Aug 17, 2014, at 1:41 AM, Nick Coghlan wrote:> If I see "bytearray(10)" there is nothing there that suggests "this> creates an array of length 10 and initialises it to zero" to me. I'd> be more inclined to guess it would be equivalent to "bytearray([10])".> > "bytearray.zeros(10)", on th
Re: [Python-Dev] PEP 467: Minor API improvements for bytes & bytearray
On Aug 17, 2014, at 11:33 AM, Ethan Furman wrote:> I've had many of the problems Nick states and I'm also +1. There are two code snippets below which were taken from the standard library. Are you saying that: 1) you don't understand the code (as the pep suggests) 2) you are willing to break th
Re: [Python-Dev] PEP 467: Minor API improvements for bytes & bytearray
On Aug 17, 2014, at 4:08 PM, Nick Coghlan wrote:> Purely deprecating the bytes case and leaving bytearray alone would likely > address my concerns. That is good progress. Thanks :-) Would a warning for the bytes case suffice, do you need an actual deprecation?> bytes.byte() thus becomes t
Re: [Python-Dev] [python-committers] new hg.python.org server
On Sep 12, 2014, at 5:34 PM, Benjamin Peterson wrote:> The> new VM is a bit beefier and has what I think is better network> connectivity, so hopefully that will improving the speed of repository> operations. Thanks Benjamin, the repo is noticeably faster. Raymond
Re: [Python-Dev] Real-world use of Counter
> On Nov 5, 2014, at 8:33 AM, Ethan Furman wrote:> > I'm looking for real-world uses of collections.Counter, specifically to see > if anyone has been surprised by, or had to spend extra-time debugging, issues > with the in-place operators. Please stop using the mailing lists as way to make a
Re: [Python-Dev] PEP 479: Change StopIteration handling inside generators
> On Nov 19, 2014, at 12:10 PM, Guido van Rossum wrote:> > There's a new PEP proposing to change how to treat StopIteration bubbling up > out of a generator frame (not caused by a return from the frame). The > proposal is to replace such a StopIteration with a RuntimeError (chained to > the
Re: [Python-Dev] PEP 479: Change StopIteration handling inside generators
> On Nov 22, 2014, at 6:31 AM, Nick Coghlan wrote:> > I'm definitely coming around to the point of view that, even if we wouldn't > design it the way it currently works given a blank slate, the alternative > design doesn't provide sufficient benefit to justify the cost of changing the > beha
Re: [Python-Dev] PEP 479: Change StopIteration handling inside generators
> On Nov 22, 2014, at 2:45 PM, Chris Angelico wrote:> > Does your middleware_generator work with just a single element,> yielding either one output value or none? I apologize if I didn't make the point clearly. The middleware example was just simple outline of calling next(), doing some pr
Re: [Python-Dev] Please reconsider PEP 479.
> On Nov 27, 2014, at 8:52 AM, Guido van Rossum wrote:> > I understand that @allow_import_stop represents a compromise, an attempt at > calming the waves that PEP 479 has caused. But I still want to push back > pretty hard on this idea.> > - It means we're forever stuck with two possible se
[Python-Dev] PEP 455 -- TransformDict
ferred mapping (an ordereddict, a persistentdict, a chainmap, etc) and the flexibility of establishing your own rules for whether and how to do a reverse lookup. Raymond Hettinger P.S. Besides the core conceptual issues listed above, there are a number of smaller issues with the TD that surfaced
Re: [Python-Dev] PEP 557: Data Classes
> On Sep 10, 2017, at 4:54 PM, Eric V. Smith wrote:> > And now I've pushed a version that works with Python 3.6 to PyPI at > https://pypi.python.org/pypi/dataclasses> > It implements the PEP as it currently stands. I'll be making some tweaks in > the coming weeks. Feedback is welcomed.> >
Re: [Python-Dev] Investigating time for `import requests`
> On Oct 1, 2017, at 7:34 PM, Nathaniel Smith wrote:> > In principle re.compile() itself could be made lazy -- return a> regular exception object that just holds the string, and then compiles> and caches it the first time it's used. Might be tricky to do in a> backwards compatibility way if
Re: [Python-Dev] Investigating time for `import requests`
$ cat > demo_github_rest_api.py import requests info = requests.get('https://api.github.com/users/raymondh').json() print('%(name)s works at %(company)s. Contact at %(email)s' % info) $ time python3.6 demo_github_rest_api.py Raymond Hettinger works at Sa
Re: [Python-Dev] PEP 557: Data Classes
> On Oct 12, 2017, at 7:46 AM, Guido van Rossum wrote:> > I am still firmly convinced that @dataclass is the right name for the > decorator (and `dataclasses` for the module). +1 from me. The singular/plural pair has the same nice feel as "from fractions import Fraction", "from itertools im
Re: [Python-Dev] The type of the result of the copy() method
> On Oct 29, 2017, at 8:19 AM, Serhiy Storchaka wrote:> > The copy() methods of list, dict, bytearray, set, frozenset, > WeakValueDictionary, WeakKeyDictionary return an instance of the base type > containing the content of the original collection.> > The copy() methods of deque, defaultdic
Re: [Python-Dev] The type of the result of the copy() method
> On Oct 29, 2017, at 10:04 AM, Guido van Rossum wrote:> > Without an answer to these questions I think it's better to admit defeat and > return a dict instance I think it is better to admit success and recognize that these APIs have fared well in the wild. Focusing just on OrderedDict() a
Re: [Python-Dev] Remove typing from the stdlib
> On Nov 3, 2017, at 9:15 AM, Victor Stinner wrote:> > 2017年11月03日 15:36 GMT+01:00 Guido van Rossum :>> Maybe we should remove typing from the stdlib?>> https://github.com/python/typing/issues/495> > I'm strongly in favor on such move.> > My experience with asyncio in the stdlib is that us
Re: [Python-Dev] Guarantee ordered dict literals in v3.7?
> On Nov 4, 2017, at 7:04 PM, Nick Coghlan wrote:> > When I asked Damien George about this for MicroPython, he indicated> that they'd have to choose between guaranteed order and O(1) lookups> given their current dict implementation. That surprised me a bit> (since PyPy and CPython both *save
Re: [Python-Dev] Guarantee ordered dict literals in v3.7?
> On Nov 5, 2017, at 4:31 PM, Nathaniel Smith wrote:> > CPython does in practice provide ordering guarantees for dicts, and this > solves a whole bunch of pain points: it makes json roundtripping work better, > it gives ordered kwargs, it makes it possible for metaclasses to see the > order
Re: [Python-Dev] Guarantee ordered dict literals in v3.7?
> On Nov 6, 2017, at 8:05 PM, David Mertz wrote:> > I strongly opposed adding an ordered guarantee to regular dicts. If the > implementation happens to keep that, great. Maybe OrderedDict can be > rewritten to use the dict implementation. But the evidence that all > implementations will alwa
Re: [Python-Dev] Add Py_SETREF and Py_XSETREF to the stable C API
> On Nov 8, 2017, at 8:30 AM, Serhiy Storchaka wrote:> > Macros Py_SETREF and Py_XSETREF were introduced in 3.6 and backported to all > maintained versions ([1] and [2]). Despite their names they are private. I > think that they are enough stable now and would be helpful in third-party > cod
Re: [Python-Dev] Add Py_SETREF and Py_XSETREF to the stable C API
> On Nov 9, 2017, at 2:44 AM, Serhiy Storchaka wrote:> > If the problem is with naming, what names do you prefer? This already was > bikeshedded (I insisted on discussing names before introducing the macros), > but may now you have better ideas? It didn't really seem like a bad idea until af
Re: [Python-Dev] What's the status of PEP 505: None-aware operators?
> I also cc python-dev to see if anybody here is strongly in favor or against > this inclusion. Put me down for a strong -1. The proposal would occasionally save a few keystokes but comes at the expense of giving Python a more Perlish look and a more arcane feel. One of the things I like
Re: [Python-Dev] PEP 557 Data Classes 5th posting
> On Dec 4, 2017, at 9:17 AM, Guido van Rossum wrote:> > And with this, I'm accepting PEP 557, Data Classes. Woohoo! I think everyone was looking forward to this moment. Raymond ___ Python-Dev mailing list [email protected] https://mail.pyt
[Python-Dev] Issues with PEP 526 Variable Notation at the class level
Both typing.NamedTuple and dataclasses.dataclass use the somewhat beautiful PEP 526 variable notations at the class level: @dataclasses.dataclass class Color: hue: int saturation: float lightness: float = 0.5 and class Color(typing.NamedTuple): hue: i
Re: [Python-Dev] Issues with PEP 526 Variable Notation at the class level
> On Dec 7, 2017, at 12:47 PM, Eric V. Smith wrote: > > On 12/7/17 3:27 PM, Raymond Hettinger wrote: > ... > >> I'm looking for guidance or workarounds for two issues that have arisen. >> >> First, the use of default values seems to completely preclude
[Python-Dev] Is static typing still optional?
The make_dataclass() factory function in the dataclasses module currently requires type declarations. It would be nice if the type declarations were optional. With typing (currently works): Point = NamedTuple('Point', [('x', float), ('y', float), ('z', float)]) Point = make_dataclass('P
Re: [Python-Dev] Is static typing still optional?
> On Dec 10, 2017, at 1:37 PM, Eric V. Smith wrote: > > On 12/10/2017 4:29 PM, Ivan Levkivskyi wrote: >> On 10 December 2017 at 22:24, Raymond Hettinger >> mailto:[email protected]>> wrote: >>Without typing (only the first currently works): >
Re: [Python-Dev] Guarantee ordered dict literals in v3.7?
> On Dec 14, 2017, at 6:03 PM, INADA Naoki wrote:> > If "dict keeps insertion order" is not language spec and we> continue to recommend people to use OrderedDict to keep> order, I want to optimize OrderedDict for creation/iteration> and memory usage. (See https://bugs.python.org/issue31265
Re: [Python-Dev] Guarantee ordered dict literals in v3.7?
> I support having regular dicts maintain insertion order but am opposed to > Inada changing the implementation of collections.OrderedDict We can have > the first without having the second.> > It seems like the two quoted paragraphs are in vociferous agreement. The referenced tracker entry
Re: [Python-Dev] Guarantee ordered dict literals in v3.7?
> On Dec 15, 2017, at 7:53 AM, Guido van Rossum wrote:> > Make it so. "Dict keeps insertion order" is the ruling. Thanks! Thank you. That is wonderful news :-) Would it be reasonable to replace some of the OrderedDict() uses in the standard library with dict()? For example, have namedtuple
Re: [Python-Dev] New crash in test_embed on macOS 10.12
> On Dec 15, 2017, at 11:55 AM, Barry Warsaw wrote:> > I haven’t bisected this yet, but with git head, built and tested on macOS > 10.12.6 and Xcode 9.2, I’m seeing this crash in test_embed:> > ==> FAIL: test_bpo20891 (tes
Re: [Python-Dev] Guarantee ordered dict literals in v3.7?
> On Dec 15, 2017, at 7:53 AM, Guido van Rossum wrote:> > Make it so. "Dict keeps insertion order" is the ruling. On Twitter, someone raised an interesting question. Is the guarantee just for 3.7 and later? Or will the blessing also cover 3.6 where it is already true. The 3.6 guidance is
Re: [Python-Dev] Guarantee ordered dict literals in v3.7?
> On Dec 15, 2017, at 1:47 PM, Guido van Rossum wrote: > > On Fri, Dec 15, 2017 at 12:45 PM, Raymond Hettinger > wrote: > > > On Dec 15, 2017, at 7:53 AM, Guido van Rossum wrote: > > > > Make it so. "Dict keeps insertion order" is the ruling. >
Re: [Python-Dev] pep-0557 dataclasses top level module vs part of collections?
> On Dec 21, 2017, at 3:21 PM, Gregory P. Smith wrote:> > It seems a suggested use is "from dataclasses import dataclass"> > But people are already familiar with "from collections import namedtuple" > which suggests to me that "from collections import dataclass" would be a more > natural s
Re: [Python-Dev] Concerns about method overriding and subclassing with dataclasses
> On Dec 29, 2017, at 4:52 PM, Guido van Rossum wrote:> > I still think it should overrides anything that's just inherited but nothing > that's defined in the class being decorated. This has the virtue of being easy to explain, and it will help with debugging by honoring the code proximate t
Re: [Python-Dev] Is static typing still optional?
>>> 2) Change the default value for "hash" from "None" to "False". This might >>> take a little effort because there is currently an oddity where setting >>> hash=False causes it to be hashable. I'm pretty sure this wasn't intended >>> ;-)>> I haven't looked at this yet.> > I think the has
Re: [Python-Dev] Is static typing still optional?
> On Jan 28, 2018, at 11:52 PM, Eric V. Smith wrote:> > I think it would be a bad design to have to opt-in to hashability if using > frozen=True. I respect that you see it that way, but it doesn't make sense to me. You can have either one without the other. It seems to me that it is clear
Re: [Python-Dev] Dataclasses, frozen and __post_init__
> On Feb 20, 2018, at 2:38 PM, Guido van Rossum wrote:> > But then the class would also inherit a bunch of misfeatures from tuple (like > being indexable and having a length). It would be nicer if it used __slots__ > instead. FWIW, George Sakkis made a tool like this about nine years ago.
[Python-Dev] Should the dataclass frozen property apply to subclasses?
When working on the docs for dataclasses, something unexpected came up. If a dataclass is specified to be frozen, that characteristic is inherited by subclasses which prevents them from assigning additional attributes:>>> @dataclass(frozen=True) class D: x: int = 10>>
[Python-Dev] Symmetry arguments for API expansion
There is a feature request and patch to propagate the float.is_integer() API through rest of the numeric types ( https://bugs.python.org/issue26680 ). While I don't think it is a good idea, the OP has been persistent and wants his patch to go forward. It may be worthwhile to discuss on this l
Re: [Python-Dev] Symmetry arguments for API expansion
> On Mar 12, 2018, at 12:15 PM, Guido van Rossum wrote:> > There's a reason why adding this to int feels right to me. In mypy we treat > int as a sub*type* of float, even though technically it isn't a sub*class*. > The absence of an is_integer() method on int means that this code has a bug >
Re: [Python-Dev] Symmetry arguments for API expansion
> On Mar 13, 2018, at 10:43 AM, Guido van Rossum wrote:> > So let's make as_integer_ratio() the standard protocol for "how to make a > Fraction out of a number that doesn't implement numbers.Rational". We already > have two examples of this (float and Decimal) and perhaps numpy or the > som
Re: [Python-Dev] Symmetry arguments for API expansion
On Tue, Mar 13, 2018 at 11:39 AM, Raymond Hettinger > wrote: > > > > On Mar 13, 2018, at 10:43 AM, Guido van Rossum wrote: > > > > So let's make as_integer_ratio() the standard protocol for "how to make a > > Fraction out of a number that doesn'
Re: [Python-Dev] Replacing self.__dict__ in __init__
> On Mar 24, 2018, at 7:18 AM, Tin Tvrtković wrote:> > it's faster to do this:> > self.__dict__ = {'a': a, 'b': b, 'c': c}> > i.e. to replace the instance dictionary altogether. On PyPy, their core devs > inform me this is a bad idea because the instance dictionary is special > there,
Re: [Python-Dev] Replacing self.__dict__ in __init__
On Mar 25, 2018, at 8:08 AM, Tin Tvrtković wrote:> > That's reassuring, thanks. I misspoke. The object size is the same but the underlying dictionary loses key-sharing and doubles in size. Raymond ___ Python-Dev mailing list [email protected]
Re: [Python-Dev] Soliciting comments on the future of the cmd module (bpo-33233)
> On Apr 6, 2018, at 3:02 PM, Ned Deily wrote:> > We could be even bolder and officially deprecate "cmd" and consider closing > open enhancement issues for it on b.p.o." FWIW, the pdb module depends on the cmd module. Also, I still teach people how to use cmd and I think it still serves a u
Re: [Python-Dev] PEP 575: Unifying function/method classes
> On Apr 12, 2018, at 9:12 AM, Jeroen Demeyer wrote:> > I would like to request a review of PEP 575, which is about changing the > classes used for built-in functions and Python functions and methods. The > text of the PEP can be found at> > https://www.python.org/dev/peps/pep-0575/ Thanks
Re: [Python-Dev] PEP 575: Unifying function/method classes
> On Apr 15, 2018, at 5:50 AM, Jeroen Demeyer wrote:> > On 2018年04月14日 23:14, Guido van Rossum wrote:>> That actually sounds like a pretty big problem. I'm sure there is lots>> of code that doesn't *just* duck-type nor calls inspect but uses>> isinstance() to decide how to extract the desire
Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20
> On Apr 25, 2018, at 8:11 PM, Yury Selivanov wrote:> > FWIW I started my thread for allowing '=' in expressions to make sure that> we fully explore that path. I don't like ':=' and I thought that using '='> can make the idea more appealing to myself and others. It didn't, sorry if> it cau
Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20
> On Apr 26, 2018, at 12:40 AM, Tim Peters wrote: > > [Raymond Hettinger ] >> After re-reading all the proposed code samples, I believe that >> adopting the PEP will make the language harder to teach to people >> who are not already software engineers. > > C
Re: [Python-Dev] PEP 572: A backward step in readability
> On Apr 30, 2018, at 9:37 AM, Steven D'Aprano wrote:> > On Mon, Apr 30, 2018 at 08:09:35AM +0100, Paddy McCarthy wrote:> [...]>> A PEP that can detract from readability; *readability*, a central>> tenet of Python, should>> be rejected, (on principle!), when such objections are treated so
Re: [Python-Dev] PEP 572: Usage of assignment expressions in C
> On Apr 28, 2018, at 8:45 AM, Antoine Pitrou wrote:> >> I personally haven't written a lot of C, so have no personal experience,>> but if this is at all a common approach among experienced C developers, it>> tells us a lot.> > I think it's a matter of taste and personal habit. Some peopl
Re: [Python-Dev] Hashes in Python3.5 for tuples and frozensets
> On May 16, 2018, at 5:48 PM, Anthony Flury via Python-Dev > wrote:> > However the frozen set hash, the same in both cases, as is the hash of the > tuples - suggesting that the vulnerability resolved in Python 3.3 wasn't > resolved across all potentially hashable values. You are correct.
Re: [Python-Dev] Add __reversed__ methods for dict
> On May 25, 2018, at 9:32 AM, Antoine Pitrou wrote:> > It's worth nothing that OrderedDict already supports reversed().> The argument could go both ways:> > 1. dict is similar to OrderedDict nowadays, so it should support> reversed() too;> > 2. you can use OrderedDict to signal explic
Re: [Python-Dev] PEP 574 (pickle 5) implementation and backport available
> On May 24, 2018, at 10:57 AM, Antoine Pitrou wrote:> > While PEP 574 (pickle protocol 5 with out-of-band data) is still in> draft status, I've made available an implementation in branch "pickle5"> in my GitHub fork of CPython:> https://github.com/pitrou/cpython/tree/pickle5> > Also I've
Re: [Python-Dev] Add __reversed__ methods for dict
> 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 dict like PyPy (and CPython) for efficiency.> But I don't know much about current MicroPython and other Python> implementation's> pl
Re: [Python-Dev] Accepting PEP 489 (Multi-phase extension module initialization)
> On May 22, 2015, at 2:52 PM, Guido van Rossum wrote:> > Congrats! Many thanks to all who contributed.> > On May 22, 2015 2:45 PM, "Eric Snow" wrote:> Hi all,> > After extended discussion over the last several months on import-sig,> the resulting proposal for multi-phase (PEP 451) exten
Re: [Python-Dev] Computed Goto dispatch for Python 2
ABI or API level. +1 from me a well. We probably should have done this long ago. Raymond Hettinger ___ 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] Computed Goto dispatch for Python 2
> On May 28, 2015, at 1:54 AM, Berker Peksağ wrote:> > * Performance improvements are not bug fixes Practicality beats purity here. Recognize that a huge number of Python users will remain in the Python2.7 world for some time. We have a responsibility to the bulk of our users (my estimate
Re: [Python-Dev] What's New editing
FWIW, it took me 100+ hours. Doing this right is a non-trivial undertaking (in modern times, there are an astonishing number of changes per release). That said, it is rewarding work that makes a difference. Raymond [David Murray] I can tell you that 3.4 took me approximately 67 hours accordin
Re: [Python-Dev] cpython: Tighten-up code in the set iterator to use an entry pointer rather than
> On Jul 7, 2015, at 12:42 AM, Serhiy Storchaka wrote:> > What if so->table was reallocated during the iteration, but so->used is left > the same? This change looks unsafe to me. FWIW, the mutation detection code in the iterator logic has always been vulnerable to being fooled the way you d
Re: [Python-Dev] PEP-498: Literal String Formatting
> On Aug 7, 2015, at 6:39 PM, Eric V. Smith wrote:> > I'm open to any suggestions to improve the PEP. Thanks for your feedback. Here's are few thoughts: * I really like the reduction in verbosity for passing in the variable names. * Because of my C background, I experience a little mental hi
Re: [Python-Dev] semantics of subclassing things from itertools
> On Sep 10, 2015, at 3:23 AM, Maciej Fijalkowski wrote:> > I would like to know what are the semantics if you subclass something> from itertools (e.g. islice).> > Right now it's allowed and people do it, which is why the> documentation is incorrect. It states "equivalent to: a function-or
Re: [Python-Dev] Choosing an official stance towards module deprecation in Python 3
> On Sep 11, 2015, at 1:57 PM, Brett Cannon wrote:> > In order to facilitate writing code that works in both Python 2 & 3> simultaneously, any module that exists in both Python 3.5 and> Python 2.7 will not be removed from the standard library until> Python 2.7 is no longer supported as speci
Re: [Python-Dev] semantics of subclassing things from itertools
> On Sep 13, 2015, at 3:49 AM, Maciej Fijalkowski wrote:> >> The intended semantics are that the itertools are classes (not functions>> and not generators). They are intended to be sub-classable (that is>> why they have Py_TPFLAGS_BASETYPE defined).> > Ok, so what's completely missing from
Re: [Python-Dev] semantics of subclassing things from itertools
> On Sep 13, 2015, at 3:09 PM, Maciej Fijalkowski wrote:> > Well, fair enough, but the semantics of "whatever happens to happen> because we decided subclassing is a cool idea" is possibly the worst> answer to those questions. It's hard to read this in any way that isn't insulting. It was su
Re: [Python-Dev] [Python-checkins] cpython: In-line the append operations inside deque_inplace_repeat().
> On Sep 14, 2015, at 12:49 PM, Brett Cannon wrote:> > Would it be worth adding a comment that the block of code is an inlined copy > of deque_append()?> Or maybe even turn the append() function into a macro so you minimize code > duplication? I don't think either would be helpful. The poi
Re: [Python-Dev] An example of Python 3 promotion attitude
> On Oct 7, 2015, at 7:12 AM, Nick Coghlan wrote:> > On 6 October 2015 at 21:29, Maciej Fijalkowski wrote:>> Now I sometimes feel that there is not enough sentiment in python-dev>> to distance from such ideas. It *is* python-dev job to promote>> python3, but it's also python-dev job sometim
Re: [Python-Dev] PEP 0484 - the Numeric Tower
#x27;3.14') + 2.71828 Traceback (most recent call last): File "", line 1, in Decimal('3.14') + 2.71828 TypeError: unsupported operand type(s) for +: 'decimal.Decimal' and 'float' Raymond Hettinger __
Re: [Python-Dev] PEP 0484 - the Numeric Tower
> On Oct 13, 2015, at 9:16 AM, Random832 wrote:> >> ## >> ## Decimal has all of the methods specified by the Real abc, but it should>> ## not be registered as a Real because decimals do not interoperate with>> ## binary floats (i.e. Decimal('3.14') + 2.71828 is undefined).
Re: [Python-Dev] [Python-checkins] Daily reference leaks (d7e490db8d54): sum=61494
, 10820, 10820] references, sum=32460 >>> test_threading leaked [2842, 2844, 2844] memory blocks, sum=8530 > > Bisection shows they were probably introduced by: > > changeset: 97413:dccc4e63aef5 > user:Raymond Hettinger > date:Sun Aug 16 19:43:34 2015
Re: [Python-Dev] Generated Bytecode ...
> On Oct 25, 2015, at 12:33 PM, Raymond Hettinger > wrote: > >> On Oct 22, 2015, at 10:02 AM, Brett Cannon wrote: >> >> So my question is, the byte code generator removes the unused functions, >> variables etc..., is it right? >> >> Technical
Re: [Python-Dev] Generated Bytecode ...
can't avoid it. IIRC, the code was never generated in the first place (before the peephole pass). This used to be true before the AST branch was added and I think it may still be true. Raymond Hettinger ___ Python-Dev mailing list P
Re: [Python-Dev] [Python-checkins] cpython (2.7): Backport early-out 91259f061cfb to reduce the cost of bb1a2944bcb6
> On Nov 11, 2015, at 10:50 PM, Benjamin Peterson wrote:> >> +if (Py_SIZE(deque) == 0)>> +return;>> +> > dequeue is not varsized in Python 2.7, so using Py_SIZE() is incorrect. Fixed in a2a518b6ded4. -if (Py_SIZE(deque) == 0) +if (deque->len == 0) Raymond ___
Re: [Python-Dev] Support of UTF-16 and UTF-32 source encodings
> On Nov 15, 2015, at 9:34 AM, Guido van Rossum wrote:> > Let me just unilaterally end this discussion. It's fine to disregard> the future possibility of using UTF-16 or -32 for Python source code.> Serhiy can happily rip out any comments or dead code dealing with that> possibility. Thank y
Re: [Python-Dev] collections.Counter __add__ implementation quirk
> On Nov 23, 2015, at 10:43 AM, Vlastimil Brom wrote:> >> Is there any particular reason counters drop negative values when you add>> them together? I definitely expected them to act like ints do when you add>> negatives, and had to subclass it to get what I think is the obvious>> behavior.
Re: [Python-Dev] Code formatter bot
ar's Pycon) Almost nothing that is wrong with CPython is stylistic, the real issues are more substantive. That is where you should devote your talents. Raymond Hettinger ___ Python-Dev mailing list [email protected] https://mail.python.org/m
Re: [Python-Dev] When should pathlib stop being provisional?
> On Apr 5, 2016, at 3:55 PM, Guido van Rossum wrote:> > It's been provisional since 3.4. I think if it is still there in 3.6.0> it should be considered no longer provisional. But this may indeed be> a test case for the ultimate fate of provisional modules -- should we> remove it? I lean sl
Re: [Python-Dev] PEP 506 secrets module
> On Apr 10, 2016, at 11:43 AM, Guido van Rossum wrote:> > I will approve the PEP as soon as you've updated the two function> names in the PEP. Congratulations Steven. Raymond ___ Python-Dev mailing list [email protected] https://mail.python
Re: [Python-Dev] Wordcode: new regular bytecode using 16-bit units
> On Apr 23, 2016, at 8:59 AM, Serhiy Storchaka wrote:> > I collected statistics for use opcodes with different arguments during > running CPython tests. Estimated size with using wordcode is 1.33 times less > than with using current bytecode.> > [1] http://comments.gmane.org/gmane.comp.pyt
Re: [Python-Dev] Wordcode: new regular bytecode using 16-bit units
> On Apr 24, 2016, at 1:16 PM, Victor Stinner wrote:> > I proposed to not try to optimize ceval.c to fetch (oparg, opval) in a> single 16-bit operation. It should be easy to implement it later, but> I prefer to focus on changing the format of the bytecode. Improving instruction decoding was
Re: [Python-Dev] Wordcode: new regular bytecode using 16-bit units
> On Apr 24, 2016, at 2:31 PM, Victor Stinner wrote: > > 2016年04月24日 23:16 GMT+02:00 Raymond Hettinger : >>> On Apr 24, 2016, at 1:16 PM, Victor Stinner >>> wrote: >>> I proposed to not try to optimize ceval.c to fetch (oparg, opval) in a >>>
Re: [Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512
> On May 25, 2016, at 3:29 AM, Christian Heimes wrote:> > I have three hashing-related patches for Python 3.6 that are waiting for> review. Altogether the three patches add ten new hash algorithms to the> hashlib module: SHA3 (224, 256, 384, 512), SHAKE (SHA3 XOF 128, 256),> BLAKE2 (blake2b,
Re: [Python-Dev] Improving the bytecode
I have mixed feelings on this one, at once applauding efforts to simplify an eternally messy part of the eval loop and at the same time worried that it throws aways years of tweaks and improvements that came beforehand. This is more of a major surgery than the other patches. Raymond Hettinger
[Python-Dev] Coding practice for context managers
Two of the new context managers in contextlib are now wrapped in pass-through factory functions. The intent is to make the help() look cleaner. This practice does have downsides however. The usual way to detect whether something is usable with a with-statement is to check the presence of th
Re: [Python-Dev] A C implementation of OrderedDict
On Oct 20, 2013, at 9:21 AM, Eric Snow wrote:> If anyone is interested in having a (faithful) C implementation of> OrderedDict for the 3.4 release, I have a patch up [1]. My interest> in having the patch applied is relative to proposals that won't apply> to 3.4, so I haven't felt the need t
Re: [Python-Dev] PEP 455: TransformDict
On Oct 28, 2013, at 1:16 PM, Victor Stinner wrote:> so what is the> status of the PEP 455 (TransformDict)? I'm giving a thorough evaluation of the proposal and am devoting chunks of time each weekend to reviewing the email threads, the links provided in the PEPs, looking at how well the TD f
Re: [Python-Dev] Changing Clinic's output
On Jan 14, 2014, at 9:12 PM, Antoine Pitrou wrote:> I'm +1 on the sidefile approach. +0 on the various buffer approaches.> -0.5 on the current "sprinkled everywhere" approach. I concur with Antoine except that I'm a full -1 on commingling generated code with hand edited code. Sprinked every
Re: [Python-Dev] Deprecation policy
On Jan 25, 2014, at 5:29 AM, Ezio Melotti wrote:> Nick also suggested to document> our deprecation policy in PEP 5 (Guidelines for Language Evolution:> http://www.python.org/dev/peps/pep-0005/ ). Here's a few thoughts on deprecations: * If we care at all about people moving to Python 3, the
Re: [Python-Dev] lambda (x, y):
On Jan 25, 2014, at 4:01 PM, Brett Cannon wrote:> As the author of the PEP and I can say that `lambda (x, y): x + y` can just > as easily be expressed as `lambda x, y: x + y` and then be called by using > *args in the argument list. Anything that gets much fancier typically calls > for a def
Re: [Python-Dev] collections.sortedtree
On Mar 26, 2014, at 1:31 PM, Marko Rauhamaa wrote:> I have made a full implementation of a balanced tree and would like to> know what the process is to have it considered for inclusion in Python> 3.> > To summarize, the implementation closely parallels dict() features and> resides in _coll
Re: [Python-Dev] Treating tokenize.Untokenizer as private
On Feb 18, 2014, at 1:09 PM, Terry Reedy wrote:> While the function could be implemented as one 70-line function, it happens > to be implemented as a 4-line wrapper for a completely undocumented > (Untokenizer class with 4 methods. (It is unmentioned in the doc and there > are currently no d
Re: [Python-Dev] PEP 469: Restoring the iterkeys/values/items() methods
On Apr 18, 2014, at 7:31 PM, Nick Coghlan wrote:> After spending some time talking to the folks at the PyCon Twisted> sprints, they persuaded me that adding back the iterkeys/values/items> methods for mapping objects would be a nice way to eliminate a key> porting hassle for them (and likely
Re: [Python-Dev] List vs Tuple / Homogeneous vs Heterogeneous / Mutable vs Immutable
On Apr 18, 2014, at 1:21 AM, Jeff Allen wrote:> The "think of tuples like a struct in C" explanation immediately reminded me > that ...> > On 16/04/2014 21:42, Taavi Burns wrote (in his excellent notes from the > language summit):>> The demographics have changed. How do>> we change the d
Re: [Python-Dev] [Python-checkins] cpython: Remove the redundant and poorly worded warning message.
On May 10, 2014, at 2:18 PM, Alex Gaynor wrote:> I think this change is a considerable usability regression for the > documentation. Right now the warnings about CSPRNGs are hidden in the > introductory paragraph, which users are likely to skip In the past couple of years, we've grown an un