[Python-Dev] Re: PEP 637 - Support for indexing with keyword arguments: request for feedback for SC submission

On 2/5/21 4:25 PM, Stefano Borini wrote: dicts and lists will keep working as before. They will not support keyword arguments (probably ever, as there is no clear semantic for them) and the current implementation simply throws an error if the user tries to. Is the plan to add PEP 637 support

[Python-Dev] Re: PEP 647 (type guards) -- final call for comments

On 2/14/21 2:34 PM, Guido van Rossum wrote: On Sun, Feb 14, 2021 at 12:51 PM David Mertz > wrote: On Sun, Feb 14, 2021, 2:53 PM Gregory P. Smith mailto:g...@krypto.org>> wrote: *TL;DR of my TL;DR* - Not conveying bool-ness directly in the return anno

[Python-Dev] Re: PEP: Deferred Evaluation Of Annotations Using Descriptors

I don't work on these sorts of codebases, and I don't use type hints or static type checking.  So I'm not really qualified to judge how bad / widespread a problem this is.  It's my hope that the greater Python core dev / user community can ascertain how serious this is. My main observation i

[Python-Dev] Re: Python 0.9.1

On 2/17/21 4:45 PM, Brett Cannon wrote: If we can get a clean copy of the original sources I think we should put them up under the Python org on GitHub for posterity. Call me crazy, but... shouldn't they be checked in?  I thought we literally had every revision going back to day zero.  It /s

[Python-Dev] Happy 30th Birthday, Python!

I guess we forgot to observe it yesterday, but: February 19, 1991, was the day Guido first posted Python 0.9.1 to alt.sources: https://groups.google.com/g/alt.sources/c/O2ZSq7DiOwM/m/gcJTvCA27lMJ Happy 30th birthday, Python! //arry/ ___ Python

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On 2/27/21 2:37 AM, Paul Moore wrote: On Fri, 26 Feb 2021 at 23:36, Jim J. Jewett wrote: Whenever I've used except Exception or stronger, it was a sanitary barrier around code that might well do unpredictable or even stupid things. Adding a new kind of exception that I hadn't predicted -- i

[Python-Dev] Re: Status of PEP 649 -- Deferred Evaluation Of Annotations Using Descriptors

On 3/27/21 4:23 PM, Jelle Zijlstra wrote: Now, PEP 649 doesn't actually fix this at the moment, since it still resolves all annotations in the global scope, but that's easily fixed by removing the special case in https://github.com/larryhastings/co_annotations/blob/co_annotations/Python/compil

[Python-Dev] PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

LOAD_NAME opcodes to function normally. I look forward to your comments, //arry/ PEP: 649 Title: Deferred Evaluation Of Annotations Using Descriptors Author: Larry Hastings Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 11-Jan-2021 Post-History: 11-Jan-2021, 11-Apr

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/11/21 7:55 PM, Paul Bryan wrote: PEP 563 also requires using ``eval()`` or ``typing.get_type_hints()`` to examine annotations. Code updated to work with PEP 563 that calls ``eval()`` directly would have to be updated simply to remove the ``eval()`` call. Code using ``typing.get_type_hints(

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/12/21 4:50 PM, Inada Naoki wrote: As PEP 597 says, eval() is slow. But it can avoidable in many cases with PEP 563 semantics. PEP 597 is "Add optional EncodingWarning".  You said PEP 597 in one other place too.  Did you mean PEP 649 in both places? Cheers, //arry/ __

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/12/21 4:50 PM, Inada Naoki wrote: PEP 563 solves all problems relating to types not accessible in runtime. There are many reasons users can not get types used in annotations at runtime: * To avoid circular import * Types defined only in pyi files * Optional dependency that is slow to impor

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/12/21 7:24 PM, Guido van Rossum wrote: I've been thinking about this a bit, and I think that the way forward is for Python to ignore the text of annotations ("relaxed annotation syntax"), not to try and make it available as an expression. To be honest, the most pressing issue with annota

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/13/21 3:28 PM, Terry Reedy wrote: On 4/13/2021 4:21 AM, Baptiste Carvello wrote: Le 12/04/2021 à 03:55, Larry Hastings a écrit : * in section "Interactive REPL Shell": For the sake of simplicity, in this case we forego delayed evaluation. The intention of the code + code

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/13/21 1:52 PM, Guido van Rossum wrote: On Tue, Apr 13, 2021 at 12:32 PM Larry Hastings <mailto:la...@hastings.org>> wrote: On 4/12/21 7:24 PM, Guido van Rossum wrote: I've been thinking about this a bit, and I think that the way forward is for Python to igno

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/12/21 7:24 PM, Guido van Rossum wrote: To be honest, the most pressing issue with annotations is the clumsy way that type variables have to be introduced. The current convention, `T = TypeVar('T')`, is both verbose (why do I have to repeat the name?) and widely misunderstood (many help re

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/14/21 10:44 AM, Guido van Rossum wrote: besides the cost of closing the door to relaxed annotation syntax, there's the engineering work of undoing the work that was done to make `from __future__ import annotations` the default (doing this was a significant effort spread over many commits,

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

https://github.com/python/steering-council/issues <https://github.com/python/steering-council/issues> as ready for pronouncement, so we have not started officially discussing this PEP yet. -Brett On Wed, Apr 14, 2021 at 11:12 AM Larry Hastings mailto:la...@hastings.org>> w

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/14/21 1:42 PM, Baptiste Carvello wrote: Are there specific annoyances associated with quoting always, apart from the 2 more characters? Yes.  Since the quoted strings aren't parsed by Python, syntax errors in these strings go undetected until somebody does parse them (e.g. your static t

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

Thanks for doing this!  I don't think PEP 649 is going to be accepted or rejected based on either performance or memory usage, but it's nice to see you confirmed that its performance and memory impact is acceptable. If I run "ann_test.py 1", the annotations are already turned into strings.

[Python-Dev] Re: In support of PEP 649

On 4/15/21 2:49 PM, Paul Ganssle wrote: I haven't followed this closely enough — if PEP 649 were accepted today, would it even be ready for use before the 3.10 code freeze (which is in a few weeks)? Perhaps I'm a poor judge of the quality of my own code.   But I'd say I have a working protot

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/15/21 2:02 PM, Sebastián Ramírez wrote: ## Questions I'm not very familiar with the internals of Python, and I'm not sure how the new syntax for `Union`s using the vertical bar character ("pipe", "|") work. But would PEP 649 still support things like this?: def run(arg: int | str = 0): p

[Python-Dev] Re: In support of PEP 649

On 4/15/21 6:09 PM, Barry Warsaw wrote: On Apr 15, 2021, at 17:47, Oscar Benjamin wrote: Would it be problematic to postpone making __future__.annotations the default? This is a good question, and I think the SC would really like to know if anybody has objections to postponing this to 3.11.

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/15/21 9:24 PM, Inada Naoki wrote: Unlike simple function case, PEP 649 creates function object instead of code object for __co_annotation__ of methods. It cause this overhead. Can we avoid creating functions for each annotation? As the implementation of PEP 649 currently stands, there a

[Python-Dev] Re: PEP 563 in light of PEP 649

Please don't confuse Inada Naoki's benchmark results with the effect PEP 649 would have on a real-world codebase.  His artifical benchmark constructs a thousand empty functions that take three parameters with randomly-chosen annotations--the results provides some insights but are not directl

[Python-Dev] Re: PEP 563 in light of PEP 649

On 4/16/21 5:00 PM, Guido van Rossum wrote: (3) Ditto run with Larry's branch (PEP 649, assuming it's on by default there -- otherwise, modify the source by inserting the needed future import at the top) The co_annotations stuff in my branch is gated with "from __future__ import co_annotati

[Python-Dev] Re: PEP 563 in light of PEP 649

Obviously that's a bug.  Can you send me this test case?  Anything works--Github, private email, whatever is most convenient for you.  Thank you! //arry/ On 4/16/21 11:22 PM, Inada Naoki wrote: ## memory error on co_annotations I modifled py_compile to add `from __future__ import co_anno

[Python-Dev] PEP 563 and 649: The Great Compromise

The heart of the debate between PEPs 563 and 649 is the question: what should an annotation be?  Should it be a string or a Python value?  It seems people who are pro-PEP 563 want it to be a string, and people who are pro-PEP 649 want it to be a value. Actually, let me amend that slightly. 

[Python-Dev] Re: PEP 563 and 649: The Great Compromise

"stock" semantics.  Accessing "o.__annotations__" always gets you the real annotations values, every time. Cheers, //arry/ On 4/18/21 7:06 AM, Jelle Zijlstra wrote: El sáb, 17 abr 2021 a las 20:45, Larry Hastings (<mailto:la...@hastings.org>>) escribió:

[Python-Dev] Re: PEP 563 and 649: The Great Compromise

On 4/18/21 9:10 AM, Damian Shaw wrote: Hi Larry, all, I was thinking also of a compromise but a slightly different approach: Store annotations as a subclass of string but with the required frames attached to evaluate them as though they were in their local context. Then have a function "get_a

[Python-Dev] Re: PEP 563 and 649: The Great Compromise

On 4/18/21 9:14 AM, Richard Levasseur wrote: Alternatively: what if the "trigger" to resolve the expression to an object was moved from a module-level setting to the specific expression? e.g. def foo(x: f'{list[int]}') -> f'{str}':   bar: f'{tuple[int]}' = () @pydantic_or_whatever_that_need

[Python-Dev] Re: PEP 563 and 649: The Great Compromise

On 4/17/21 8:43 PM, Larry Hastings wrote: TBD: how this interacts with PEP 649.  I don't know if it means we only do this, or if it would be a good idea to do both this and 649.  I just haven't thought about it.  (It would be a runtime error to set both "o.__str_annota

[Python-Dev] Re: PEP 563 in light of PEP 649

module that have identical signatures.  The annotation-tuples optimization naturally takes advantage of that.  PEP 649 doesn't.  Should it? Would this really be beneficial to real-world code bases? Cheers, //arry/ On 4/16/21 12:26 PM, Larry Hastings wrote: Please don't confuse Ina

[Python-Dev] Re: PEP 563 in light of PEP 649

Oops: where I said nine, I should have said, twenty-seven.  3-cubed.  Should have had my coffee /before/ posting.  Carry on! //arry/ On 4/19/21 10:51 AM, Larry Hastings wrote: I noticed something this morning: there's another way in which Inada Naoki's benchmark here is

[Python-Dev] Re: PEP 563 in light of PEP 649

On 4/19/21 1:37 PM, Ethan Furman wrote: On 4/19/21 10:51 AM, Larry Hastings wrote: Something analogous /could/ happen in the PEP 649 branch but currently doesn't.  When running Inada Noki's benchmark, there are a total of nine possible annotations code objects.  Except, each

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

python-dev@python.org/thread/AWKVI3NRCHKPIDPCJYGVLW4HBYTEOQYL/ Here's kind of where we left it: On 1/12/21 7:48 PM, Guido van Rossum wrote: On Tue, Jan 12, 2021 at 6:35 PM Larry Hastings <mailto:la...@hastings.org>> wrote: On 1/12/21 5:28 PM, Brett Cannon wrote: The other thi

[Python-Dev] Re: Keeping Python a Duck Typed Language.

On 4/20/21 10:03 AM, Mark Shannon wrote: Then came PEP 563 and said that if you wanted to access the annotations of an object, you needed to call typing.get_type_hints() to get annotations in a meaningful form. This smells a bit like enforced static typing to me. I'm working to address this.

[Python-Dev] Re: Keeping Python a Duck Typed Language.

On 4/20/21 10:03 AM, Mark Shannon wrote: If you guarded your code with `isinstance(foo, Sequence)` then I could not use it with my `Foo` even if my `Foo` quacked like a sequence. I was forced to use nominal typing; inheriting from Sequence, or explicitly registering as a Sequence. If I'm re

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 4/23/21 9:26 PM, Guido van Rossum wrote: This is happening, right? Adding a default `__annotations = {}` to modules and classes. (Though https://bugs.python.org/issue43901 seems temporarily stuck.) It's happening, and I wouldn't say it's stuck.  I'm act

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

I've hit a conceptual snag in this. What I thought I needed to do: set __annotations__= {} in the module dict, and set __annotations__= {} in user class dicts.  The latter was more delicate than the former but I think I figured out a good spot for both.  I have this much working, including f

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 4/24/21 7:11 AM, Nick Coghlan wrote: On Sat, 24 Apr 2021, 5:53 pm Larry Hastings, <mailto:la...@hastings.org>> wrote: So I now suspect that my knee-jerk answer is wrong.  Am I going too far down the rabbit hole? Should I /just/ make the change for user classes and leav

[Python-Dev] Re: Let's Fix Class Annotations -- And Maybe Annotations Generally

On 4/24/21 8:09 AM, Petr Viktorin wrote: On 24. 04. 21 9:52, Larry Hastings wrote: I've hit a conceptual snag in this. What I thought I needed to do: set __annotations__= {} in the module dict, and set __annotations__= {} in user class dicts. The latter was more delicate than the forme

[Python-Dev] In what tense should the changelog be written?

When one writes one's "blurb" for the changelog, in what tense should it be?  I mostly see entries in present tense: bpo-43660: Fix crash that happens when replacing sys.stderr with a callable that can remove the object while an exception is being printed. Patch by Pablo Galindo.

[Python-Dev] Re: In what tense should the changelog be written?

bar state when spam happens,” because that isn’t clear about whether that’s the before or after behavior.) On Thu, Apr 29, 2021 at 17:37 Ethan Furman <mailto:et...@stoneleaf.us>> wrote: On 4/29/21 7:57 PM, Larry Hastings wrote:  > When one writes one's "blurb&q

[Python-Dev] Re: In what tense should the changelog be written?

ed by parentheses, unless demonstrating an example call. Slapping my forehead, //arry/ On 4/29/21 9:50 PM, Larry Hastings wrote: I'll wait to see if anybody else has contrary opinions, but for now here's a first draft: Your NEWS entry should be written in the present te

[Python-Dev] Re: In what tense should the changelog be written?

On 4/30/21 4:51 AM, Victor Stinner wrote: On Fri, Apr 30, 2021 at 6:57 AM Larry Hastings wrote: Function and class names should not be followed by parentheses, unless demonstrating an example call. Oh, I love putting parentheses when mentionning a function: "foo() now does thigs new

[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

On 5/7/21 2:45 PM, Pablo Galindo Salgado wrote: Given that column numbers are not very big compared with line numbers, we plan to store these as unsigned chars or unsigned shorts. We ran some experiments over the standard library and we found that the overhead of all pyc files is: * If we use

[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

On 5/9/21 3:00 AM, M.-A. Lemburg wrote: BTW: For better readability, I'd also not output the lines for every stack level in the traceback, but just the last one, since it's usually clear where the call to the next stack level happens in the upper ones. Playing devil's advocate: in the un-

[Python-Dev] Re: The repr of a sentinel

On 5/13/21 10:46 AM, Eric V. Smith wrote: >>> MISSING I think a repr of just "MISSING", or maybe "dataclasses.MISSING" would be better. I literally just went down this road--for a while there was a special sentinel value for the eval_str parameter to inspect.get_annotations().  The repr I

[Python-Dev] Re: Critique of PEP 657 -- Include Fine Grained Error Locations in Tracebacks

On 5/18/21 5:25 AM, Pablo Galindo Salgado wrote: Yet another problem that I found: One integer is actually not enough to assign IDs. One unsigned integer can cover 4,294,967,295 AST nodes, but is technically possibleto have more than that in a single file. Surely you could use a 64-bit int

[Python-Dev] Re: change of behaviour for '.' in sys.path between 3.10.0a7 and 3.10.0b1

On 6/3/21 4:20 AM, Chris Johns wrote: Might be out of context here, but IMHO "." shouldn't be assumed to be the current directory anyway. As someone who has ported python to a system where it isn't, these assumptions tend to cause problems. That sounds miserable.  What does "." signify on

[Python-Dev] Re: enum in the stable ABI (Was: PEP 558: Defined semantics for locals)

On 7/23/21 7:38 AM, Petr Viktorin wrote: (In both C & C++, the size of an `enum` is implementation-defined. That's unlikely to be a problem in practice, but one more point against enum.) True, but there's always the old trick of sticking in a value that forces it to be at least 32-bit:

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

On 8/10/21 11:09 AM, Damian Shaw wrote: Could PEP 649 be modified to say that if a NameError is raised the result is not cached and therefore you can inspect it later at runtime to get the real type once it is defined? Wouldn't that then allow users to write code that allows for all use cases u

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

On 8/10/21 11:15 AM, Thomas Grainger wrote: Although the co_annoations code could intercept the NameError and replace return a ForwardRef object instead of the resolved name No, it should raise a NameError, just like any other Python code.  Annotations aren't special enough to break the rule

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

On 8/9/21 8:25 PM, Inada Naoki wrote: Currently, reference implementation of PEP 649 has been suspended. We need to revive it and measure performance/memory impact. Perhaps this sounds strange--but I don't actually agree. PEP 563 was proposed to solve a forward-references problem for the typi

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

On 8/11/21 12:02 AM, Thomas Grainger wrote: I think as long as there's a test case for something like ``` @dataclass class Node: global_node: ClassVar[Node | None] left: InitVar[Node | None] right: InitVar[None | None] ``` the bug https://bugs.python.org/issue33453 and the curren

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

On 8/11/21 2:48 AM, Jukka Lehtosalo wrote: On Wed, Aug 11, 2021 at 10:32 AM Thomas Grainger <mailto:tagr...@gmail.com>> wrote: Larry Hastings wrote: > On 8/11/21 12:02 AM, Thomas Grainger wrote: > > I think as long as there's a test case for something

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

On 8/11/21 5:21 AM, Inada Naoki wrote: But memory footprint and GC time is still an issue. Annotations in PEP 649 semantics can be much heavier than docstrings. I'm convinced that, if we accept PEP 649 (or something like it), we can reduce its CPU and memory consumption. Here's a slightly c

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

On 8/11/21 5:15 AM, Chris Angelico wrote: On Wed, Aug 11, 2021 at 10:03 PM Larry Hastings wrote: This approach shouldn't break reasonable existing code. That said, this change would be observable from Python, and pathological code could notice and break. For example:

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

On 8/12/21 8:25 AM, Guido van Rossum wrote: Maybe we could specialize the heck out of this and not bother with a function object? In the end we want to execute the code, the function object is just a convenient way to bundle defaults, free variables (cells) and globals. But co_annotation has n

[Python-Dev] Re: PEP 654 except* formatting

It seems like, for this to work, "group" would have to become a keyword.  This would play havoc with a lot of existing code.  I can't tell you how many times I've used the identifier "group" in my code, particularly when dealing with regular expressions. Even making it a soft keyword, a la "

[Python-Dev] Re: PEP 654 except* formatting

On 10/6/21 2:34 PM, Łukasz Langa wrote: On 6 Oct 2021, at 12:06, Larry Hastings <mailto:la...@hastings.org>> wrote: It seems like, for this to work, "group" would have to become a keyword. No, just like `match` and `case` didn't have to. This would play havoc wit

[Python-Dev] Re: Python multithreading without the GIL

On 10/7/21 8:52 PM, Sam Gross wrote: I've been working on changes to CPython to allow it to run without the global interpreter lock. Before anybody asks: Sam contacted me privately some time ago to pick my brain a little.  But honestly, Sam didn't need any help--he'd already taken the proje

[Python-Dev] Announcing PEP 436: The Argument Clinic DSL

Following up on a conversation on python-dev from last December: http://mail.python.org/pipermail/python-dev/2012-December/122920.html I'm pleased to announced PEP 436, proposing Argument Clinic for adoption into the CPython source tree. http://www.python.org/dev/peps/pep-0436/ Argum

Re: [Python-Dev] Announcing PEP 436: The Argument Clinic DSL

On 02/26/2013 08:11 AM, Terry Reedy wrote: The PEP gives an internal, developer-focused rationale. I think there is also an external, user-focused rationale. As much as possible (with obvious caveats about type introspection), I think it should be transparent to users (other than speed) whether

Re: [Python-Dev] Announcing PEP 436: The Argument Clinic DSL

On 02/26/2013 06:30 PM, Terry Reedy wrote: On 2/26/2013 1:47 PM, Larry Hastings wrote: I think positional-only functions should be discouraged, but we don't If I were writing something like Clinic, I would be tempted to not have that option. But I was actually thinking about something i

Re: [Python-Dev] [PEP 437] A DSL for specifying signatures, annotations and argument converters

On 03/16/2013 02:17 AM, Stefan Krah wrote: Both PEPs were discussed at PyCon. The state of affairs is that a compromise is being worked upon and will be published by Larry in a revised PEP. I've pushed an update to PEP 436, the Argument Clinic PEP. It's now live on python.org. //arry/ ___

Re: [Python-Dev] [Python-checkins] peps: New DSL syntax and slightly changed semantics for the Argument Clinic DSL.

On 03/17/2013 03:26 PM, Stefan Krah wrote: While I like the syntax better and appreciate the option to condense the function declaration I still fear that the amount of implicitness will distract from what is important: programming in C. This applies especially if people start declaring conver

Re: [Python-Dev] [Python-checkins] peps: New DSL syntax and slightly changed semantics for the Argument Clinic DSL.

On 03/18/2013 12:16 AM, Larry Hastings wrote: I'll amend my PEP soonish to reflect this. Specifically the semantics of the /, [, and ] lines in the parameter section. I've just posted this revision. I'd like to draw everyone's attention to the top entry in the Notes

Re: [Python-Dev] [Python-checkins] peps: New DSL syntax and slightly changed semantics for the Argument Clinic DSL.

On 03/18/2013 02:29 AM, Ronald Oussoren wrote: On 18 Mar, 2013, at 8:16, Larry Hastings wrote: This has some consequences. For example, inspect.getfullargspec, inspect.Signature, and indeed types.FunctionObject and types.CodeObject have no currently defined mechanism for communicating that

[Python-Dev] Rough idea for adding introspection information for builtins

The original impetus for Argument Clinic was adding introspection information for builtins--it seemed like any manual approach I came up with would push the builtins maintenance burden beyond the pale. Assuming that we have Argument Clinic or something like it, we don't need to optimize for

Re: [Python-Dev] Rough idea for adding introspection information for builtins

On 03/19/2013 12:37 AM, Serhiy Storchaka wrote: On 19.03.13 06:45, Larry Hastings wrote: 4. Store a string that looks like the Python declaration of the signature, and parse it (Nick's suggestion). For foo above, this would be "(arg,b=3,*,kwonly='a')". Length: 23 b

Re: [Python-Dev] Rough idea for adding introspection information for builtins

On 03/19/2013 12:23 AM, Nick Coghlan wrote: On Mon, Mar 18, 2013 at 11:08 PM, Stefan Behnel wrote: My first idea for implementation: add a "def x" to the front and ": pass" to the end Why not require it to be there already? Maybe more like def foo(arg, b=3, *, kwonly='a'): ..

[Python-Dev] Early results from Argument Clinic automation discussion

Mark Shannon, Dmitry Jemerov (from PyCharm) and I sat down to talk about rearchitecting the Argument Clinic prototype to make it easily to interact with. We came up with the following. The DSL will now produce an intermediate representation. The output will consume this intermediate repres

Re: [Python-Dev] IDLE in the stdlib

On 03/20/2013 11:34 PM, Georg Brandl wrote: I don't really understand what Antoine's "quiescently torpid" means, "quiescent" = "peaceful, quiet, still" "torpid" = "lethargic, not moving" "antoine" = "thesaurus owner" //arry/ ___ Python-Dev mailing l

Re: [Python-Dev] Semantics of __int__(), __index__()

On 04/03/2013 09:04 AM, Steven D'Aprano wrote: On 04/04/13 01:16, Barry Warsaw wrote: It's analogous to all the other built-in types-as-functions, so int() calls __int__() which must return a concrete integer. Why must it? I think that's the claim which must be justified, not just taken as

Re: [Python-Dev] casefolding in pathlib (PEP 428)

On 04/12/2013 10:05 AM, Guido van Rossum wrote: On Fri, Apr 12, 2013 at 1:39 AM, Antoine Pitrou wrote: I think we want glob("*.py") to find "SETUP.PY" under Windows. Anything else will probably be surprising to users of that platform. Yeah, I suppose so. But there are more crazy details. E.g.

Re: [Python-Dev] Sharing docstrings between the Python and C implementations of a module

On 04/15/2013 09:31 AM, Eli Bendersky wrote: Would it make sense to think about adding this in the scope of the argument clinic work, or is it too unrelated? This seems like a commonly needed thing for large parts of the stdlib (where the C accelerator overrides Python code). From my perspect

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

On 04/26/2013 12:34 AM, Greg Ewing wrote: Or if, as Guido says, the only sensible things to use as enum values are ints and strings, just leave anything alone that isn't one of those. The standard Java documentation on enums: http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html has

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

On 04/26/2013 09:27 AM, Serhiy Storchaka wrote: 26.04.13 18:50, Larry Hastings написав(ла): The standard Java documentation on enums: http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html This example requires more than features discussed here. It requires an enum constructor

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

On 04/26/2013 02:41 PM, Guido van Rossum wrote: I am still optimistic that we can come up with a rule that works well enough in practice (and the Zen rule to which I was referring was, of course, "practicality beats purity"). The rule I liked best is "ignore callables, descriptors, and anything

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

On 04/29/2013 06:51 AM, Eli Bendersky wrote: flufl.enum disallows this: class Color(Enum): red = 1 blue = 2 green = 1 # oops! Has it been decided that this is now allowed? If this is indeed the case, then Color(1) is a problem. The options are: A. Return either Color.red or Color.gree

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

On 04/29/2013 10:35 AM, Steven D'Aprano wrote: On 30/04/13 02:42, Guido van Rossum wrote: On Mon, Apr 29, 2013 at 6:51 AM, Eli Bendersky wrote: I don't feel strongly about allowing ()-lookup in addition to []-lookup, but in this paragraph the issue of multiple definitions has sneaked in :-)

Re: [Python-Dev] Enumeration items: `type(EnumClass.item) is EnumClass` ?

On 04/29/2013 10:01 AM, Guido van Rossum wrote: On Mon, Apr 29, 2013 at 9:12 AM, Ethan Furman wrote: On 04/29/2013 08:39 AM, Guido van Rossum wrote: Indeed, the "type(Color.red) is Color" claim was meant for the situation where red is defined directly in Color, and I used type() instead of isi

Re: [Python-Dev] Enumeration item arguments?

On 04/29/2013 03:33 PM, Ethan Furman wrote: On 04/29/2013 03:25 PM, Eli Bendersky wrote: On Mon, Apr 29, 2013 at 2:59 PM, Ethan Furman wrote: In the Planet example we saw the possibility of specifying arguments to enum item __init__: class Planet(Enum): MERCURY = (3.303e+23, 2.4397e6)

Re: [Python-Dev] enum instances

On 04/29/2013 07:42 PM, Nikolaus Rath wrote: State is a class, it just inherits from enum. Thus: type(State) == type(enum) == type(EnumMetaclass) issubclass(State, enum) == True HTH, -Nikolaus If you'd tried it, you'd have found that that isn't true. enum has a metaclass, EnumMetaclas

Re: [Python-Dev] enum instances

On 04/30/2013 07:05 PM, Nikolaus Rath wrote: Larry Hastings writes: On 04/29/2013 07:42 PM, Nikolaus Rath wrote: State is a class, it just inherits from enum. Thus: type(State) == type(enum) == type(EnumMetaclass) issubclass(State, enum) == True HTH, -Nikolaus If you'd tri

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

On 04/30/2013 11:29 PM, Ethan Furman wrote: On 04/30/2013 11:18 PM, Barry Warsaw wrote: On Apr 28, 2013, at 11:50 PM, Ethan Furman wrote: But as soon as: type(Color.red) is Color # True type(MoreColor.red) is MoreColor # True then: Color.red is MoreColor.red # must be F

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

On 05/02/2013 07:57 AM, Barry Warsaw wrote: On May 01, 2013, at 11:54 AM, Larry Hastings wrote: On 04/30/2013 11:29 PM, Ethan Furman wrote: On 04/30/2013 11:18 PM, Barry Warsaw wrote: On Apr 28, 2013, at 11:50 PM, Ethan Furman wrote: But as soon as: type(Color.red) is Color

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

On 05/04/2013 07:01 AM, Eric V. Smith wrote: On 5/4/2013 2:42 AM, Nick Coghlan wrote: I'm now -1 on my own as_dict() suggestion, due to the general name clash problem for arbitrary enums. To avoid the name collision, namedtuple calls this _asdict(). Although I recall Raymond told me he should

Re: [Python-Dev] PEP 435: pickling enums created with the functional API

On 05/07/2013 08:47 AM, Eli Bendersky wrote: def Color = Enum('red green blue') It's an interesting idea, but as NIck suggested we should probably discuss it on the python-ideas list. [...] A special syntax raises more questions though, because it has to be defined very precisely. Feel

Re: [Python-Dev] PEP 0 maintenance - deferring some currently open PEPs

On 05/10/2013 12:14 AM, Nick Coghlan wrote: I'd like to mark a few PEPs that are not currently being actively considered for 3.4 as Deferred: I swear I posted a list like this a couple years ago. Now I can't find it. Anyway it was completely ignored then, probably because I'm not Nick Coghl

Re: [Python-Dev] Reminder: an oft-forgotten rule about docstring formatting (PEP 257)

On 06/26/2013 08:56 PM, Guido van Rossum wrote: PEP 257 says this on the formatting of multi-line docstrings: """ Multi-line docstrings consist of a summary line just like a one-line docstring, followed by a blank line, followed by a more elaborate description. The summary line may be used by au

Re: [Python-Dev] PyArg_ParseTupe(): parse unsigned integer and check for overflow

On 06/29/2013 06:24 PM, Serhiy Storchaka wrote: Definitely Argument Clinic should use converters for unsigned integers without wraparound by default. Argument Clinic 1.0 is a thin layer over PyArg_ParseTuple. But it will support these sorts of converters, and if people have bright ideas abo

[Python-Dev] Expose stack effects to Python?

I wrote my own assembler for Python bytecode called "Maynard". I had to statically compute the stack effects for each bytecode instruction by hand; what I did was copied and pasted opcode_stack_effect() (which is static) out of Python/compile.c and into my own driver program, then I probed

Re: [Python-Dev] Rough idea for adding introspection information for builtins

Revisiting a four-month-old discussion: On 03/19/2013 11:00 AM, Larry Hastings wrote: As for handling optional argument groups, my gut feeling is that we're better off not leaking it out of Argument Clinic--don't expose it in this string we're talking about, and don't a

Re: [Python-Dev] Rough idea for adding introspection information for builtins

On 07/07/2013 12:32 AM, Nick Coghlan wrote: Rather than perpetuating unwanted complexity, can't we just add a single "incomplete signature" flag to handle the legacy cases, and leave those to the docstrings? As in, if the flag is set, pydoc displays the "..." because it knows the signature

Re: [Python-Dev] Rough idea for adding introspection information for builtins

On 07/07/2013 03:04 AM, Nick Coghlan wrote: On 7 Jul 2013 10:25, "Larry Hastings" <mailto:la...@hastings.org>> wrote: >> >> group >>> >>> If not None, represents which "optional parameter group" this parameter belongs to. Optional pa

Re: [Python-Dev] Rough idea for adding introspection information for builtins

On 07/07/2013 07:19 AM, Ronald Oussoren wrote: Not entirely on topic, but close enough: pydoc currently doesn't use the __signature__ information at all. Adding such support would be easy enough, see #17053 for an implementation ;-) True, it doesn't use inspect.signature, it uses inspect.ge

Re: [Python-Dev] Rough idea for adding introspection information for builtins

On 07/07/2013 01:42 PM, Ronald Oussoren wrote: On 7 Jul, 2013, at 13:35, Larry Hastings wrote: On 07/07/2013 07:25 AM, Ronald Oussoren wrote: Signature objects use a name in angled brackets to indicate that a parameter is positional only, for example "input()". That might be an a

Re: [Python-Dev] Building a Faster Python

On 07/21/2013 04:36 PM, Raymond Hettinger wrote: Our current Mac OS X builds use GCC-4.2. On Python2.7, I ran a comparison of gcc-4.2.1 builds versus gcc-4.8.1 and found that the latter makes a much faster Python. PyBench2.0 shows the total running time dropping from 5653ms to 4571ms. The code

<    1   2   3   4   5   6   7   8   9   >