Larry Hastings added the comment:
New changeset 063eba280a11d3c9a5dd9ee5abe4de640907951b by larryhastings
(Abhilash Raj) in branch '3.5':
[3.5] bpo-34155: Dont parse domains containing @ (GH-13079) (#15317)
https://github.com/python/cpython/commit/063eba280a11d3c9a5dd9ee5abe4de
Larry Hastings added the comment:
All PRs merged. Thanks, everybody!
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<https://bugs.python.org/i
Larry Hastings added the comment:
New changeset 4d1c2541c125fe9d211016193ebfd5899a8511aa by larryhastings (Victor
Stinner) in branch '3.5':
bpo-36576: Skip test_ssl and test_asyncio tests failing with OpenSSL 1.1.1
(#12694)
https://github.com/python/cpyt
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:
New submission from Larry Trammell :
== The Problem ==
I have observed a "loss of data" problem using the Python SAX parser, when
processing an oversize but very simple machine-generated xhtml file. The file
represents a single N x 11 data table. W3C "tidy" reports
Larry Trammell added the comment:
Not a bug, strictly speaking... more like user abuse.
The parsers (expat as well as SAX) must be able to return content text as a
sequence of pieces when necessary. For example, as a text sequence interrupted
by grouping or styling tags (like or ). Or
Change by Larry Hastings :
--
nosy: -larry
___
Python tracker
<https://bugs.python.org/issue27929>
___
___
Python-bugs-list mailing list
Unsubscribe:
Larry Trammell added the comment:
I can't find any real errors in documentation. There are subtle design and
implementation decisions that result in unexpected rare side effects. After
processing hundreds of thousands of lines one way, why would the parser
suddenly decide to proces
Larry Trammell added the comment:
Assuming that my understanding is completely correct, the situation is that the
xml parser has an unspecified behavior. This is true in any text content
handler, at any time, and applies to the expat parser as well as SAX. In some
rare cases, the behavior
Larry Trammell added the comment:
Sure... I'll cut and paste some of the text I was organizing to go into a
possible new issue page.
The only relevant documentation I could find was in the "xml.sax.handler" page
in the Python 3.9.2 Documentation for the Python Standard Lib
Larry Trammell added the comment:
Great minds think alike I guess...
I was thinking of a much smaller carryover size... maybe 1K. With individual
text blocks longer than that, the user will almost certainly be dealing with
collecting and aggregating content text anyway, and in that case
Larry Trammell added the comment:
Oh, and whether this affects only content text...
I would presume so, but I don't know how to tell for sure. Unspecified
behaviors can be very mysterious!
--
___
Python tracker
<https://bugs.py
Larry Trammell added the comment:
I think the existing ContentHandler.characters(content) documentation DOES say
that the text can come back in chunks... but it is subtle. It might be
possible to say more explicitly that any content no matter how small is allowed
to be returned as any
Larry Trammell added the comment:
If there were a decision NOT TO FIX... maybe then it would make sense to
consider documentation patches at a higher priority. That way, SAX-Python (and
expat-Python) tutorials across the Web could start patching their presentations
accordingly
Larry Trammell added the comment:
Eric, now that you know as much as I do about the nature and scope of the
peculiar parsing behavior, do you have any suggestions about how to proceed
from here?
--
___
Python tracker
<https://bugs.python.
New submission from Larry Trammell :
Issue 43483 was posted as a "bug" but retracted. Though the problem is real,
it is tricky to declare an UNSPECIFIED behavior to be a bug. See that issue
page for more discussion and a test case. A brief overview is repeated here.
SCENARIO - X
New submission from Larry Trammell :
With reference to improvement issue 43560 :
If those improvements remain unimplemented, or are demoted to "don't fix",
users are left in the tricky situation where XML parsing applications can fail,
apparently "losing content" in
Larry Trammell added the comment:
Check out issues
43560 (an enhancement issue to improve handling of small XML content chunks)
43561 (a documentation issue to give users warning about the hazard in the
interim before the changes are implemented
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
101 - 200 of 2415 matches
Mail list logo
