Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On 10 November 2017 at 19:17, Greg Ewing wrote: > Ethan Furman wrote: > >> Contriwise, "annotation_strings" sounds like a different type of >> annotation -- they are now being stored as strings, instead of something >> else. >> > > How about "annotations_as_strings"?

Re: [Python-Dev] The current dict is not an "OrderedDict"

Does it matter whether the dict order after pop/delete is explicitly specified, or just specified that it's deterministic? On 7 November 2017 at 11:28, Antoine Pitrou wrote: > On Wed, 8 Nov 2017 06:19:46 +1100 > Chris Angelico wrote: > > > > I've used a

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

Isn't ordered dict also useful for **kwargs? If it turns out that there's a dict implementation that's faster by not preserving order, collections.UnorderedDict could be added. There could also be specialized implementations that pre-size the dict (cf: C++ unordered_map::reserve), etc., etc. But

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

If type annotations are treated like implicit lambdas, then that's a first step to something similar to Lisp's "special forms". A full generalization of that would allow, for example, logging.debug to not evaluate its args unless debugging is turned on (I use a logging.debug wrapper that allows

Re: [Python-Dev] \G (match last position) regex operator non-existant in python?

On 28 October 2017 at 16:48, Steven D'Aprano wrote: > On Sun, Oct 29, 2017 at 12:31:01AM +0100, MRAB wrote: > > > Not that I'm planning on making any further additions, just bug fixes > > and updates to follow the Unicode updates. I think I've crammed enough > > into it

Re: [Python-Dev] TextIO seek and tell cookies

On 25 September 2016 at 21:18, Guido van Rossum wrote: > Be careful though, comparing these to plain integers should probably > be allowed, ​There's a good reason why it's "opaque" ... why would you want to make it less opaque? And I'm curious why Python didn't adopt the

Re: [Python-Dev] Do PEP 526 type declarations define the types of variables or not?

I would take the opposite approach from Greg Ewing, namely that the annotation is not a permission of values but a starting point for the type inferencer; and the type checker/inferencer can complain if there's an inconsistency (for some definition of "inconsistency", which is not defined in the

Re: [Python-Dev] Adding NewType() to PEP 484

I'm surprised that nobody has suggested UniqueType. ;) On 28 May 2016 at 10:17, Ivan Levkivskyi wrote: > My final vote goes to "distinct type alias". > But how should we call the function? NewType? Or should we change it to > DistinctAlias or something? > > -- > Ivan > 28

Re: [Python-Dev] Why does PEP 7/8 explicitly suggest 2 spaces after a period?

I just tried a re-flow in emacs (M-q or fill-paragraph) and it didn't change my single space to two (it also changed 3 spaces after a period to 2; and it preserved my hanging indents). I have no idea what vim does. (OTOH, emacs annoyingly adds a blank line to my """ docstrings, which I remove

Re: [Python-Dev] Adding Type[C] to PEP 484

e database.) > > --Guido > > >> >> >> On 14 May 2016 at 11:30, Guido van Rossum <gvanros...@gmail.com> wrote: >> >>> What would Type[C, D] mean? >>> >>> --Guido (mobile) >>> On May 14, 2016 11:21 AM, "Pet

Re: [Python-Dev] Adding Type[C] to PEP 484

ned with a TypeVar(..., bound=...), in which case multiple types aren't allowed with Type[...]? On 14 May 2016 at 11:30, Guido van Rossum <gvanros...@gmail.com> wrote: > What would Type[C, D] mean? > > --Guido (mobile) > On May 14, 2016 11:21 AM, "Peter Ludemann via

Re: [Python-Dev] Adding Type[C] to PEP 484

Is Type[C,D] allowed? Or should multiple types be restricted to TypeVar? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

Re: [Python-Dev] PEP 8 updated on whether to break before or after a binary update

If Python ever adopts the BCPL rule for implicit line continuation if the last thing on a line is an operator (or if there's an open parentheses), then the break-after-an-operator rule would be more persuasive. ;) [IIRC, the BCPL rule was that there was an implicit continuation if the grammar

Re: [Python-Dev] Speeding up CPython 5-10%

Also, modern compiler technology tends to use "infinite register" machines for the intermediate representation, then uses register coloring to assign the actual registers (and generate spill code if needed). I've seen work on inter-function optimization for avoiding some register loads and stores

Re: [Python-Dev] FAT Python (lack of) performance

About benchmarks ... I've been there and it's not benchmarks that decide whether something succeeds or fails. (I found this old discussion which mentions FIB (also TAK , which is

Re: [Python-Dev] Update PEP 7 to require curly braces in C

On 18 January 2016 at 23:25, Alexander Walters wrote: > > > On 1/19/2016 02:21, Larry Hastings wrote: > > > On 01/18/2016 08:40 PM, Alexander Walters wrote: > > I am not a core developer, but I just kind of feel its hypocritical to > oppose always using brackets for the

Re: [Python-Dev] type(obj) vs. obj.__class__

I re-coded the "too clever by half" RingBuffer to use the same design but with delegation ... and it ran 50% slower. (Code available on request) Then I changed it to switch implementations of append() and get() when it got full (the code is below) and it ran at essentially the same speed as the

Re: [Python-Dev] type(obj) vs. obj.__class__

On 18 October 2015 at 17:41, Chris Angelico wrote: > On Mon, Oct 19, 2015 at 11:35 AM, David Mertz wrote: > > That's interesting about the `self._full` variable slowing it down, I > think > > I'm not surprised (but obviously it depends on just how it's used).

Re: [Python-Dev] PEP-498 PEP-501: Literal String Formatting/Interpolation

Cannon br...@python.org wrote: On Sun, Aug 9, 2015, 13:51 Peter Ludemann via Python-Dev python-dev@python.org wrote: Most of my outputs are log messages, so this proposal won't help me because (I presume) it does eager evaluation of the format string and the logging methods are designed to do

Re: [Python-Dev] PEP-498: Literal String Formatting

Most of my outputs are log messages, so this proposal won't help me because (I presume) it does eager evaluation of the format string and the logging methods are designed to do lazy evaluation. Python doesn't have anything like Lisp's special forms, so there doesn't seem to be a way to implicitly

Re: [Python-Dev] PEP-498: Literal String Formatting

: On Sun, Aug 9, 2015, 13:51 Peter Ludemann via Python-Dev python-dev@python.org wrote: Most of my outputs are log messages, so this proposal won't help me because (I presume) it does eager evaluation of the format string and the logging methods are designed to do lazy evaluation. Python

Re: [Python-Dev] Enable access to the AST for Python code

On 21 May 2015 at 17:12, Ethan Furman et...@stoneleaf.us wrote: On 05/21/2015 04:33 PM, Greg Ewing wrote: Steve Dower wrote: It's only a macro system when you generate code in unexpected/unobvious places with it. This is more like inspect.getsource(), but going straight to the AST. Is