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
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
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
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
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
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
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
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
> 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
> 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
> 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
> 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
> 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
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
> 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.
>
>
> 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
$ 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
Python-Dev@python.org
https://mail.pyt
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
> 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
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
> 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:raymond.hettin...@gmail.com>> wrote:
>>Without typing (only the first currently works):
>
> 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
> 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
> 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
> 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
> 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
> 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.
>
> 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
> 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
>>> 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
> 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
> 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.
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
>>
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
> 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
>
> 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
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'
> 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,
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
Python-Dev@python.org
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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.
> 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
> 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
> 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
> 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
ABI or API level.
+1 from me a well. We probably should have done this long ago.
Raymond Hettinger
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
> On 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
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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
#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
__
> 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).
, 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
> 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
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
> 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
___
> 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
> 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.
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
Python-Dev@python.org
https://mail.python.org/m
> 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
> 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
Python-Dev@python.org
https://mail.python
> 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
> 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
> 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
>>>
> 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,
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
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
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
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
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
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
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
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
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
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
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
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
1 - 100 of 1487 matches
Mail list logo
