Larry Hastings added the comment:
New changeset 095373c32d16df575ba5fcb5f44bf44119b26193 by larryhastings (Victor
Stinner) in branch '3.5':
bpo-36742: Corrects fix to handle decomposition in usernames (GH-13812)
(GH-13814) (#14772)
https://github.com/python/cpyt
Larry Hastings added the comment:
New changeset c28e4a5160d3283b12514c7c28ed6e0a2a52271a by larryhastings
(Abhilash Raj) in branch '3.5':
[3.5] bpo-37461: Fix infinite loop in parsing of specially crafted email
headers (GH-14794) (#15446)
https://github.com/python/cpyt
Change by Larry Hastings :
--
title: Use less statics in Argument Clinic. -> Use fewer statics in Argument
Clinic.
___
Python tracker
<https://bugs.python.org/issu
Larry Hastings added the comment:
shared objects x threads = contention for notification of invalidated cache
lines
If you're not running multiple threads, there's no problem. If it's only a few
shared objects, it probably wouldn't be a big deal. As they say in medici
Larry Hastings added the comment:
Should we open a separate issue to track fixing the regression?
--
___
Python tracker
<https://bugs.python.org/issue30
Larry Hastings added the comment:
FWIW I planned to tag and release 3.5.8 final early next week. I don't have
the domain knowledge to assess the severity of this bug--much less pitch in and
help fix it--so I suspect this will simply hold up 3.5.8 final.
Depending on the complexity o
Larry Hastings added the comment:
So, following this recent flurry of activity, all that remains are to sort out
2.7 and 3.5. 3.5.8 is still in a holding pattern; at this point I think I'm
going to insert another RC, so I can add the new version of expat.
Will a makes-everyone-hap
Larry Hastings added the comment:
New changeset 2784e78dc3445c6dd59e915d86c336374c1fa09a by larryhastings (Jason
R. Coombs) in branch '3.5':
[3.5] bpo-38216, bpo-36274: Allow subclasses to separately override validation
and encoding behavior (GH-16448) (#16475)
https://github.
Larry Hastings added the comment:
New changeset 2784e78dc3445c6dd59e915d86c336374c1fa09a by larryhastings (Jason
R. Coombs) in branch '3.5':
[3.5] bpo-38216, bpo-36274: Allow subclasses to separately override validation
and encoding behavior (GH-16448) (#16475)
https://github.
Change by Larry Hastings :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Larry Hastings added the comment:
New changeset c386c8b06c6e92786f083ef6aba27b37087fdd20 by larryhastings (Victor
Stinner) in branch '3.5':
closes bpo-38174: Update vendored expat library to 2.2.8. (GH-16346) (#16434)
https://github.com/python/cpyt
Change by Larry Hastings :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Larry Hastings :
--
versions: +Python 3.8, Python 3.9 -Python 3.5, Python 3.6
___
Python tracker
<https://bugs.python.org/issue12178>
___
___
Python-bug
Change by Larry Hastings :
--
nosy: -larry
___
Python tracker
<https://bugs.python.org/issue12178>
___
___
Python-bugs-list mailing list
Unsubscribe:
Larry Hastings added the comment:
For what it's worth, I'm cherry-picking this back into 3.5 for 3.5.8 final. I
(finally?) got bit by this, and since the patch is literally only changes in
the Lib/test directory I consider it safe to merge even after 3.5.8rc2. (I was
in a bit
Larry Hastings added the comment:
New changeset 3fe1b19265b55c290fc956e9aafcf661803782de by larryhastings (Victor
Stinner) in branch '3.5':
bpo-38243, xmlrpc.server: Escape the server_title (GH-16373) (GH-16441) (#16516)
https://github.com/python/cpyt
Change by Larry Hastings :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue38243>
___
___
Python-bugs-list
Larry Hastings added the comment:
New changeset d7b336fe5d54f73c758802df426e06e8a674bd63 by Larry Hastings
(Serhiy Storchaka) in branch '3.5':
[3.5] bpo-31026: Fix test_dbm if dbm.ndbm is build with Berkeley DB. (GH-6632)
https://github.com/python/cpyt
Change by Larry Hastings :
--
nosy: -larry
___
Python tracker
<https://bugs.python.org/issue20408>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Larry Hastings :
--
nosy: -larry
___
Python tracker
<https://bugs.python.org/issue27929>
___
___
Python-bugs-list mailing list
Unsubscribe:
Larry Hastings added the comment:
Do you have an actual use case for self-referential annotations?
--
nosy: +larry
___
Python tracker
<https://bugs.python.org/issue43
New submission from Larry Hastings :
The implementation of the | operator for TypeVar objects is as follows:
def __or__(self, right):
return Union[self, right]
def __ror__(self, right):
return Union[self, right]
I think the implementation of __ror__ is ever-so
Larry Hastings added the comment:
By "use case", I mean, what problem are you solving in a useful program by
doing this? So far it seems like a pointless exercise in seeing what funny
behavior you can try with annotations.
--
___
Pyth
New submission from Larry Hastings :
Currently, with PEP 563 looming over us, people who use annotations for
something besides type hints are kind of stuck. Converting stringized
annotations back into useful values is a complicated problem, and there's only
function in the standard li
Larry Hastings added the comment:
(realized mid-issue-creation that it should have a different name)
--
title: Add typing.eval_annotations() -> Add typing.get_annotations()
___
Python tracker
<https://bugs.python.org/issu
Larry Hastings added the comment:
To be honest, I'm not 100% sure. But I observe that typing.get_type_hints() is
about fifty lines of code, and very few of them are the opinionated lines I
want to avoid.
Some things typing.get_type_hints() seems to do for you:
* Work around the &qu
Larry Hastings added the comment:
> I'd say just submit the PR. Shouldn't be problematic.
Okey-doke, I can do it. Though I have plenty to do at the moment, though, so
it wouldn't be this week.
Is there anybody who would *enjoy* taking this on, who we could farm it out to
Larry Hastings added the comment:
> Should this feature implemented in typing module? How about inspect module?
That's a reasonable idea.
Part of the reasoning behind putting it in the typing module was to share its
implementation with typing.get_type_hints(). However, I was rea
Larry Hastings added the comment:
Assuming this function is added for Python 3.10, I propose that uses of
typing.get_type_hints() in the standard library that aren't specifically
dealing with type hints should change to calling this function instead. I
currently know of two
Larry Hastings added the comment:
> Hey Larry, it would seem that PEP 649 as currently specified would make it
> impossible to access annotations via the inspect module in cases where
> x.__annotations__ raises (because one of the annotations references an
> undefined variab
Larry Hastings added the comment:
It would also cause the code generated for the annotations function to
balloon--the calculation of every value would have to be wrapped in a
try/except, and for what I assume is an obscure use case. I'm already getting
some pushback on the code gene
Larry Hastings added the comment:
I admit I hadn't looked that closely at Jelle's PR. You're right, its effects
on code size should be minimal.
If I'm reading it correctly, Jelle's PR would suppress NameError by replacing
the failed value with a new "Annota
Larry Hastings added the comment:
I note that Python already ships with some #ifdefs around SSE and the like.
So, yes, we already do this sort of thing, although I think this usually uses
compiler intrinsics rather than actual assembly. A quick grep shows zero .s
files and only one .asm
New submission from Larry Hastings :
I'm working on a branch to implement PEP 649:
https://github.com/larryhastings/co_annotations/
Inada Naoki discovered a crash in that branch, discussed here, including steps
to reproduce:
https://github.com/larryhastings/co_annotations/issu
Larry Hastings added the comment:
(Sorry, the name of the function is stackdepth(), not stackeffect().)
--
___
Python tracker
<https://bugs.python.org/issue43
Change by Larry Hastings :
--
title: Add typing.get_annotations() -> Add inspect.get_annotations()
___
Python tracker
<https://bugs.python.org/issu
New submission from Larry Hastings :
The behavior of the __annotations__ member is wildly different between the
three objects (function, class, module) that support it. Many of these
differences are minor, but one in particular has been an awful wart for years:
classes can inherit
Change by Larry Hastings :
--
title: Add an empty annotations dict to all classes and modules -> Add an empty
annotations dict to all unannotated classes and modules
___
Python tracker
<https://bugs.python.org/issu
Larry Hastings added the comment:
Huh. The sample code in my thread got goofed up somewhere along the way--maybe
it's my fault, maybe it was done to me by some automated process. Anyway, the
example demonstrating classes inheriting annotations was meant to be formatted
like
Larry Hastings added the comment:
Preliminary patch is 17 lines. Ah well. I must be terrible at this!
--
___
Python tracker
<https://bugs.python.org/issue43
Larry Hastings added the comment:
Just over twelve hours ago, the Python Steering Committee announced that
stringized annotations would no longer be default behavior in Python 3.10.
They will go back to being gated with "from __future__ import annotations". I
think we still
Larry Hastings added the comment:
Hmm. If o.__annotations__ is None, should this function set the empty dict on
the object? That seems slightly too opinionated to me. On the other hand, the
user would probably expect that they could change the dict they got back. (If
Python shipped with
Larry Hastings added the comment:
> Are you saying the user would expect to be able to change __annotations__ my
> modifying the dict they get back?
As the docs are currently written, it's ambiguous.
> Is it ever the case that the user can modify __annotations__ through the
Larry Hastings added the comment:
Just to round the bases: get_annotations() won't return an unmodified
__annotations__ dict, but it *could* return a *consistent* dict. It could keep
a cache (lru or otherwise) of all responses so far. I don't think that's what
we want, I
Larry Hastings added the comment:
> - Is it possible to create __annotations__ lazily? (IIRC in January we came
> to a conclusion about this, something like yes for modules but for classes,
> or the other way around?)
Maybe for modules, definitely not for classes. The problem is
Larry Hastings added the comment:
By the way, here's a tidbit I never got around to posting in c.l.p-d.
I noted in the conversation in January that attrs is an outlier here: it
*doesn't* look in the class dict for __annotations__. Instead, it has some
complicated code where i
Larry Hastings added the comment:
It occurs to me that part of this work should also be a new "best practices for
__annotations__" entry in the Python docs.
Best practices for working with annotations, for code that requires a minimum
Python version of 3.10+:
Best practice
Larry Hastings added the comment:
> * Never modify o.__annotations__.
Let me revise that to:
* If o.__annotations__ is a dict, never modify the contents of that dict.
--
___
Python tracker
<https://bugs.python.org/issu
Larry Hastings added the comment:
When I proposed this new function, stringized annotations were the default
behavior in Python 3.10, and there were two calls to typing.get_type_hints() in
the standard library:
* inspect.signature()
* functools.singledispatch()
Now that stringized
Change by Larry Hastings :
--
keywords: +patch
pull_requests: +24242
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/25522
___
Python tracker
<https://bugs.python.org/issu
Larry Hastings added the comment:
I think it gets a little murkier when we talk about *annotations* vs *type
hints*. Type hints have a defined meaning for a string: a string is a sort of
forward declaration, and you eval() the string to get the real value. (Or,
not, if you're comfor
Larry Hastings added the comment:
PR is up, passes all checks. I think it's ready for the first round of reviews!
--
___
Python tracker
<https://bugs.python.org/is
Change by Larry Hastings :
--
assignee: -> larry
___
Python tracker
<https://bugs.python.org/issue43817>
___
___
Python-bugs-list mailing list
Unsubscrib
Larry Hastings added the comment:
I think stringized annotations should prohibit the same things PEP 649
prohibits: walrus, yield / yield from, and await.
This was easy in my 649 branch; walrus adds locals, and yield / yield from make
it a generator. So the code raises an error if the
Larry Hastings added the comment:
Wouldn't it be easier to just throw an exception in the stringizing code? I
note that there are dedicated functions to generate walrus, yield, yield from,
and await in Python/ast_unparse.c. In theory this is a general-purpose
facility, but in pra
Larry Hastings added the comment:
Time runs short for Python 3.10b1. Can I get a review from anybody here, say
over the weekend?
--
___
Python tracker
<https://bugs.python.org/issue43
Larry Hastings added the comment:
> I’d say that best practices for 3.9+ are more useful.
My point in writing this up was that the best practices change as of 3.10. So,
I could add a section to the Python 3.10 documentation giving best practices
for 3.10+ and 3.9-. But 3.9 and 3.10 h
Larry Hastings added the comment:
For what it's worth: I changed the name to ONLY_IF_STRINGIZED in the PR.
Since I propose that it be the default, everyone who called
inspect.get_annotations(), and inspect.signature(), would use it. I think
Pydantic would prefer it, because Pydantic
Larry Hastings added the comment:
The difference between eval_str=True and eval_str=ONLY_IF_STRINGIZED:
def foo(a:int, b:"howdy howdy"): ...
inspect.get_annotations(foo, eval_str=True) throws an exception.
inspect.get_annotations(foo, eval_str=ONLY_IF_STRINGIZED) returns {&
Larry Hastings added the comment:
Perhaps eval_str=ONLY_IF_STRINGIZED should also add the semantics "if
evaluating any string fails, behave as if eval_str=false". I would *not*
propose adding that for eval_str=true. But people keep asking for this. Hmm.
The heuristic is a tr
Larry Hastings added the comment:
I'm not breaking backwards compatibility--that's the point of all this. But
I'm improving the experience. And if you don't care about 3.9 and before, you
can stick to the new improved experience.
Looking in the class dict for annotati
Larry Hastings added the comment:
I'm please you folks are as supportive as you are of what I'm doing here, given
that you seem a little unsure of the details. I concede that there's a lot
going on and it can be hard to keep it all in your head.
The point of this issue / P
Larry Hastings added the comment:
And I just had a realization. Lazy creation of an empty annotations dict,
for both classes and modules, will work fine.
As stated in my previous comment in this issue, my goal here is to improve best
practices in 3.10+, while preserving the unfortunate
Change by Larry Hastings :
--
title: Add an empty annotations dict to all unannotated classes and modules ->
Lazy-create an empty annotations dict in all unannotated user classes and
modules
___
Python tracker
<https://bugs.python.org/issu
Larry Hastings added the comment:
Hmm. Sorry for the stream-of-consciousness thought process here, but this
approach adds wrinkles too.
Function objects from the very beginning have lazy-created their annotations
dict if it's not set. Which means this works fine:
while
Larry Hastings added the comment:
> Functions don't store __annotations__ in their __dict__, it is a
> separate slot named func_annotations (see funcobject.c). I guess
> that's because the __dict__ is purely for user-defined function
> attributes.
I brought up fun
New submission from Larry Hastings :
Recent Python source trees fail a regression test in test_gdb. Oddly, the
behavior only appears up when optimization is turned off.
To reproduce:
% git clone cpython buildtrunk
% cd buildtrunk
% ./configure
% vi Makefile # change "-O3&quo
Change by Larry Hastings :
--
keywords: +patch
pull_requests: +24322
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/25623
___
Python tracker
<https://bugs.python.org/issu
Larry Hastings added the comment:
I keep thinking about it, and I think letting inspect.get_annotations() and
inspect.signature() raise exceptions is the right API choice.
I note that that's what typing.get_type_hints() did in Python 3.9. During the
development of Python 3.10, thi
Larry Hastings added the comment:
> I'm not a big user of the inspect module, but I always thought that
> its use was so that you could look at a function (or other object)
> *produced by a 3rd party* and learn something about it.
That's interesting! I always thought i
Larry Hastings added the comment:
> I use inspect.signature for getting information about callables
> (third-party and first-party) in my type checker:
> https://github.com/quora/pyanalyze/blob/master/pyanalyze/arg_spec.py#L436.
> In that context, I'd much rather get string
Larry Hastings added the comment:
> There may be a (deliberate? :-) misunderstanding. When I wrote about
> "you" inspecting code by a "3rd party" I meant that as a symmetric
> relationship -- the "you" could be a library and from the library's
&g
Larry Hastings added the comment:
I like Eric's suggestion best of all. I'd be willing to add a "silence errors
on a case-by-case basis" flag to inspect.signature(). I imagine that would add
a new field to the Parameter object (as Guido suggested) indicating which
ob
Larry Hastings added the comment:
Just to be clear: I would *not* want this new mode to be the *default*
behavior. So far I think ONLY_IF_STRINGIZED is the best compromise for default
behavior.
--
___
Python tracker
<https://bugs.python.
Larry Hastings added the comment:
One final thought on that idea. Part of the reason why I didn't go back to the
drawing board and re-think the API was because I thought folks were pushing
back on the idea of *default* behavior possibly raising exceptions.
If I misread it, and the pus
New submission from Larry Hastings :
While working on another issue, I noticed two minor nits in the C
implementation of the module object. Both are related to getting a module's
name.
--
First, the C function module_dir() (module.__dir__) starts by ensuring the
module dict is valid
Change by Larry Hastings :
--
keywords: +patch
pull_requests: +24349
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/25658
___
Python tracker
<https://bugs.python.org/issu
Larry Hastings added the comment:
I'm on "Pop!_OS 20.10". Current versions:
* Linux kernel 5.11.0-7612
* gcc version 10.2.0 (Ubuntu 10.2.0-13ubuntu1)
* GNU gdb (Ubuntu 9.2-0ubuntu2) 9.2
% ./python -m sysconfig | grep CFLAGS
BASECFLAGS = "-Wno-unused-r
Larry Hastings added the comment:
Did that. Well, technically, I replaced two lines with the equivalent:
% CFLAGS='-O0 -g3' ./configure
I do see this in the Makefile:
CONFIGURE_CFLAGS= -O0 -g3
so, I didn't screw it up!
The te
Larry Hastings added the comment:
I think the PR is in good shape. If anybody has the time for a review, I'd
appreciate it!
--
___
Python tracker
<https://bugs.python.org/is
Change by Larry Hastings :
--
nosy: -larry
___
Python tracker
<https://bugs.python.org/issue43954>
___
___
Python-bugs-list mailing list
Unsubscribe:
Larry Hastings added the comment:
Ie debated about this with myself (and with a friend!) over the last few days,
and I've concluded that evaluating strings by default is too opinionated for
the standard library. I've changed both inspect.signature() and
inspect.get_annota
Larry Hastings added the comment:
kj: I just added support for default locals to inspect.get_annotation(), and I
basically copied-and-pasted your dict(vars(base)) approach.
Is this "surprising, but required" behavior due specifically to this being a
backwards-incompati
Larry Hastings added the comment:
Thank you for your in-depth and thoughtful reply!
I think that APIs should behave in a predictable way. So, for my use case, I
tell the user that I'm passing "globals" and "locals" into eval()--and I think
I'd have to have
Larry Hastings added the comment:
New changeset 2f2b69855d6524e15d12c15ddc0adce629e7de84 by larryhastings in
branch 'master':
bpo-43901: Lazy-create an empty annotations dict in all unannotated user
classes and modules (#25623)
https://github.com/python/cpyt
Larry Hastings added the comment:
Thanks for your feedback and reviews, everybody! Python just got an eensy
teensy tiny bit better.
--
assignee: -> larry
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
__
Larry Hastings added the comment:
Thanks for the review, Victor!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Larry Hastings added the comment:
New changeset 74613a46fc79cacc88d3eae4105b12691cd4ba20 by larryhastings in
branch 'master':
bpo-43817: Add inspect.get_annotations(). (#25522)
https://github.com/python/cpython/commit/74613a46fc79cacc88d3eae4105b12
Larry Hastings added the comment:
Thanks for your feedback, everybody! It's now checked in.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.pyth
New submission from Larry Hastings :
Dealing with annotations is complicated. I think there should be a section of
the Python documentation describing best practices for working
with annotations. So, here goes.
The best spot I found for it was as a new HOWTO. I added links to that HOWTO
Change by Larry Hastings :
--
keywords: +patch
pull_requests: +24436
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/25746
___
Python tracker
<https://bugs.python.org/issu
Change by Larry Hastings :
--
nosy: +Jelle Zijlstra
___
Python tracker
<https://bugs.python.org/issue43987>
___
___
Python-bugs-list mailing list
Unsubscribe:
Larry Hastings added the comment:
Gee whiz! Sorry about that. I swear, it works fine on my machine.
I'll incorporate import_helper.import_fresh_module helper into the test as you
suggest, and once I get it to work I'll send you a PR. I don't know how to
test fixing this
Change by Larry Hastings :
--
pull_requests: +24442
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/25752
___
Python tracker
<https://bugs.python.org/issu
Larry Hastings added the comment:
Eek! I swear I did a refleak check and got a clean bill of health. Again,
sorry about this!
--
___
Python tracker
<https://bugs.python.org/issue43
Larry Hastings added the comment:
You want a separate PR for the refleak fix, or should I roll them both up into
one?
--
___
Python tracker
<https://bugs.python.org/issue43
Larry Hastings added the comment:
Obviously the original assertion failure ("AssertionError: False is not true")
wasn't caused by the refleaks. So I'm still puzzled about why that test worked
on POSIX and failed on Windows. I admit I was pulling some wacky import
she
Larry Hastings added the comment:
Ah, I see. So it wasn't a Windows thing, it was a "we run the test multiple
times and that particular test assumed it was only run once" thing. And
reflink testing is guaranteed to run every test
Larry Hastings added the comment:
New changeset 49b26fa517165f991c35a4afcbef1fcb26836bec by larryhastings in
branch 'master':
bpo-43987: Add "Annotations Best Practices" HOWTO doc. (#25746)
https://github.com/python/cpython/commit/49b26fa517165f991c35
Larry Hastings added the comment:
Thanks to Jelle for an enormous amount of reviewing and re-reviewing! That was
just spiffy.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracke
101 - 200 of 2389 matches
Mail list logo
