Any possible type alias that can also set a default value for a function arg?
We have the `Optional[T]` type as a short-hand for Union[T | None] and telling us that said argument may not be present. However, I find that a majority of the time, we also want to set a default value of None on the argument so that it can be evaluated without doing a getattr() check first. iow, a lot of `foo: Optional[str] = None` in method signatures. I'd love to see a companion to the Optional type, I'll call it Default, so that it can take a default value as a second arg, with a default of that being None. For example: foo: Default[str] would be equivalent to foo: Optional[str] = None foo: Default[str, "bar"] would be equivalent to foo: Optional[str] = "bar" or something like that. Basically, any way to avoid writing `= None` over and over again. -- https://mail.python.org/mailman/listinfo/python-list
Re: Tkinter not working
On 01/08/2022 13:17, Daniel Lee wrote: Hello, I my code with tkinter was working before, and now, it has many errors in it. I’m not sure what has happened. The results after running are below: "D:\Python Projects\tes\venv\Scripts\python.exe" "D:/Python Projects/tes/main.py" Traceback (most recent call last): File "D:\Python Projects\tes\main.py", line 1, in import tkinter as tk File "C:\Users\Daniel.LAPTOP-6U1MQ9CR\AppData\Local\Programs\Python\Python310\lib\tkinter\__init__.py", line 3, in import tkinter.messagebox File "C:\Users\Daniel.LAPTOP-6U1MQ9CR\AppData\Local\Programs\Python\Python310\lib\tkinter\messagebox.py", line 25, in from tkinter.commondialog import Dialog File "C:\Users\Daniel.LAPTOP-6U1MQ9CR\AppData\Local\Programs\Python\Python310\lib\tkinter\commondialog.py", line 13, in from tkinter import Frame, _get_temp_root, _destroy_temp_root ImportError: cannot import name 'Frame' from partially initialized module 'tkinter' (most likely due to a circular import) (C:\Users\Daniel.LAPTOP-6U1MQ9CR\AppData\Local\Programs\Python\Python310\lib\tkinter\__init__.py) Process finished with exit code 1 The entry: File "C:\Users\Daniel.LAPTOP-6U1MQ9CR\AppData\Local\Programs\Python\Python310\lib\tkinter\__init__.py", line 3, in import tkinter.messagebox in the traceback does not look right to me. On my PC that file starts with a long docstring. -- https://mail.python.org/mailman/listinfo/python-list
[issue47006] PEP 646: Decide on substitution behavior
Matthew Rahtz added the comment: Ok, https://github.com/python/cpython/pull/32341/files is a reference of how the current implementation behaves. Fwiw, it *is* mostly correct - with a few minor tweaks it might be alright for at least the 3.11 release. In particular, instead of dealing with the thorny issue of what to do about splitting unpacked arbitrary-length tuples over multiple type variables - e.g. C[T, *Ts][*tuple[int, ...]] - instead either deciding to try and evaluate it properly and living with the complexity, or leaving it unsimplified and living with the __args__, __parameters__ and __origin__ problem - for now, we could just raise an exception for any substitutions which involve an unpacked arbitrary-length tuple, since I'd guess it's going to be an extremely rare use-case. -- ___ Python tracker <https://bugs.python.org/issue47006> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47006] PEP 646: Decide on substitution behavior
Change by Matthew Rahtz : -- keywords: +patch pull_requests: +30396 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32341 ___ Python tracker <https://bugs.python.org/issue47006> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47203] ImportError: DLL load failed while importing binascii: %1 is not a valid Win32 application.
Matthew added the comment: > Probably there was also shadowing involved, since the built-in module doesn't > try to load anything else. Would be nice to know for sure (@Matthew) to make > sure we don't have some other issue here, but you're right, I don't see any > way for this to happen without other causes. I'm pretty sure the Python interpreter that was causing the issue was bundled with the MSYS2 Mingw64 compiler. I tried reproducing the bug, but I've recently reinstalled the compiler due to some issues I was having with it, and the bug with importing binascii is no longer present. -- ___ Python tracker <https://bugs.python.org/issue47203> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47006] PEP 646: Decide on substitution behavior
Matthew Rahtz added the comment: [Guido] > 1. Some edge case seems to be that if *tuple[...] is involved on either side > we will never simplify. Alright, let me think this through with some examples to get my head round it. It would prohibit the following difficult case: class C(Generic[*Ts]): ... Alias = C[T, *Ts] Alias[*tuple[int, ...]] # Does not simplify; stays C[T, *Ts][*tuple[int, ...]] That seems pretty reasonable. It would also prohibit these other relatively simple cases, but I guess that's fine: Alias = C[*Ts] Alias[*tuple[int, ...]] # Does not simplify; stays C[*Ts][*tuple[int, ...]] Alias = C[T, *tuple[int, ...]] Alias[str] # Does not simplify; stays C[T, *tuple[int, ...]][str] > Or perhaps a better rule is that *tuple[...] is never simplified away (but > fixed items before and after it may be). Is this to say that we effectively prohibit binding *tuple[...] to anything? If we can simplify without binding *tuple[...] to anything, then we do simplify, but otherwise, we don't simplify? So under this rule, the following WOULD work? Alias = C[T, *tuple[int, ...]] Alias[str] # Simplifies to C[str, *tuple[int, ...]], because we didn't have to bind *tuple[int, ...] to do it > 2. Another edge case is that if neither side has any starred items we will > always simplify (since this is the existing behavior in 3.10). This may raise > an error if the number of subscripts on the right does not match the number > of parameters on the left. Alright, so this is business as usual. > 3. If there's a single *Ts on the left but not on the right, we should be > able to simplify, which again may raise an error if there are not enough > values on the right, but if there are more than enough, the excess will be > consumed by *Ts (in fact that's the only way *Ts is fed). So then: class C(Generic[*Ts]): ... Alias = C[T, *Ts] Alias[()] # Raises error Alias[int] # Simplifies to C[int, *Ts] Alias[int, str]# Simplifies to C[int, str] Alias[int, str, bool] # Simplifies to C[int, str, bool] Yup, seems straightforward. > 4. If there's a *Ts on the right but not on the left, we should _not_ > simplify, since whatever we have on the left serves as a constraint for *Ts. Ok, so this is about the following situations: class C(Generic[*Ts]): ... Alias = C[T1, T2] Alias[*Ts] # Does not simplify; stays C[T1, T2][*Ts] Yikes - in fact, this is actually super hairy; I hadn't thought about this edge case at all in the PEP. Agreed that it seems reasonable not to simplify here. > E.g. tuple[int, int][*Ts] constrains *Ts to being (int, int). Was that a typo? Surely tuple[int, int][*Ts] isn't valid - since tuple[int, int] doesn't have any free parameters? > 5. If there's exactly one *Ts on the left and one on the right, we _might__ > be able to simplify if the prefix and suffix of the __parameters__ match the > prefix and suffix of the subscript on the right. E.g. C[int, T, *Ts, > float][str, *Ts] can be simplified to C[int, str, *Ts, float]. OTOH C[int, T, > *Ts, float][*Ts] cannot be simplified -- but we cannot flag it as an error > either. Note that __parameters__ in this example is (T, Ts); we have to > assume that typevartuples in __parameters__ are always used as *Ts (since the > PEP recognizes no valid unstarred uses of Ts). Ok, this also makes sense. --- Still, though, doesn't the point that Serhiy brought up about __origin__, __parameters__ and __args__ still apply? In cases where we *don't* simplify, there'd still be the issue of what we'd set these things to be. This evening I'll also revisit the PRs adding tests for substitution to try and make them a comprehensive reference as to what's currently possible. -- ___ Python tracker <https://bugs.python.org/issue47006> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47006] PEP 646: Decide on substitution behavior
Matthew Rahtz added the comment: Apologies for the slow reply - coming back to this now that the docs and pickling issues are mostly sorted. [Serhiy] > > Alias = C[T, *Ts] > > Alias2 = Alias[*tuple[int, ...]] > > # Alias2 should be C[int, *tuple[int, ...]] > > tuple[int, ...] includes also an empty tuple, and in this case there is no > value for T. This was my initial intuition too, but Pradeep pointed out to me in https://github.com/python/cpython/pull/31021#discussion_r815853784 that for tuple[int, ...], Python has chosen the opposite mindset: instead of assuming the worst-case scenario, we assume the best-case scenario. Thus, the following type-checks correctly with mypy (https://mypy-play.net/?mypy=latest=3.10=b9ca66fb7d172f939951a741388836a6): def return_first(tup: tuple[int, ...]) -> int: return tup[0] tup: tuple[()] = () return_first(tup) > > We actually deliberately chose not to unpack concrete tuple types - see the > > description of https://github.com/python/cpython/pull/30398, under the > > heading 'Starred tuple types'. (If you see another way around it, though, > > let me know.) > > You assumed that *tuple[str, bool] in def foo(*args: *tuple[str, bool]) > should give foo.__annotations__['args'] = tuple[str, bool], but it should > rather give (str, bool). No confusion with tuple[str, bool]. Fair point, we could *technically* distinguish between tuple[str, bool] and (str, bool). But if I was a naive user and I saw `foo.__annotations__['args'] == (str, bool)`, I don't think it'd be immediately obvious to me that the type of `args` was `*tuple[str, bool]`. Also though, there's a second reason mentioned in https://github.com/python/cpython/pull/30398 why `(str, bool)` wouldn't be the best choice. We decided that the runtime behaviour of `*args: *something` should be that we essentially do `(*something,)[0]`. If we made `tuple[int, str]` unpack to `(int, str)`, then we'd end up with `__annotations__['args'] == (int,)`. > And one of PEP 646 options is to implement star-syntax only in subscription, > not in var-parameter type annotations. As in, we would allow `Generic[*Ts]`, but not `*args: *Ts`? That'd be a *major* change to the PEP - not an option I'm willing to consider at this stage in the process. > > I'm also not sure about this one; disallowing unpacked TypeVarTuples in > > argument lists to generic aliases completely (if I've understood right?) > > No, it will only be disallowed in substitution of a VarType. Tuple[T][*Ts] -- > error. Tuple[*Ts][*Ts2] -- ok. Ah, gotcha. My mistake. [Guido] I ran out of time this evening :) Will reply properly soon. -- ___ Python tracker <https://bugs.python.org/issue47006> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47203] ImportError: DLL load failed while importing binascii: %1 is not a valid Win32 application.
Matthew added the comment: Hello, Thanks for all the help people have given me! I've found the solution to my problem. The Environment Variable was set below every other, leading to a different Python interpreter to being used, which was probably bundled with a different software. I moved the Env. Variable up to the top, and the issue was fixed. Thanks again! -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue47203> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43224] Add support for PEP 646
Matthew Rahtz added the comment: > 1. Finish writing docs Done once https://github.com/python/cpython/pull/32103 is merged. > 2. Implement support for pickling of unpacked native tuples Done once https://github.com/python/cpython/pull/32159 is merged. 4. Resolve the issue of how we implement type substitution (https://bugs.python.org/issue47006) Will re-visit this now. -- ___ Python tracker <https://bugs.python.org/issue43224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47152] Reorganize the re module sources
Matthew Barnett added the comment: For reference, I also implemented .regs in the regex module for compatibility, but I've never used it myself. I had to do some investigating to find out what it did! It returns a tuple of the spans of the groups. Perhaps I might have used it if it didn't have such a cryptic name and/or was documented. -- ___ Python tracker <https://bugs.python.org/issue47152> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43224] Add support for PEP 646
Change by Matthew Rahtz : -- pull_requests: +30237 pull_request: https://github.com/python/cpython/pull/32159 ___ Python tracker <https://bugs.python.org/issue43224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43224] Add support for PEP 646
Matthew Rahtz added the comment: Since things are piling up, here's a quick record of what I think the remaining tasks are: (in approximate order of priority) 1. Finish writing docs (is updating library/typing.html sufficient? https://github.com/python/cpython/pull/32103) 2. Implement support for pickling of unpacked native tuples 3. Implement support and add tests for copy() of TypeVarTuple and unpacked tuple 4. Resolve the issue of how we implement type substitution (https://bugs.python.org/issue47006) -- ___ Python tracker <https://bugs.python.org/issue43224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43224] Add support for PEP 646
Change by Matthew Rahtz : -- pull_requests: +30197 pull_request: https://github.com/python/cpython/pull/32119 ___ Python tracker <https://bugs.python.org/issue43224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47097] Document PEP 646
Change by Matthew Rahtz : -- keywords: +patch pull_requests: +30183 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/32103 ___ Python tracker <https://bugs.python.org/issue47097> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47097] Document PEP 646
Matthew Rahtz added the comment: Ooh, thanks for the reminder! I'll start drafting this now. -- nosy: +matthew.rahtz ___ Python tracker <https://bugs.python.org/issue47097> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47006] PEP 646: Decide on substitution behavior
Matthew Rahtz added the comment: P.s. To be clear, (I think?) these are all substitutions that are computable. We *could* implement the logic to make all these evaluate correctly if we wanted to. It's just a matter of how much complexity we want to allow in typing.py (or in the runtime in general, if we say farmed some of this logic out to a separate module). -- ___ Python tracker <https://bugs.python.org/issue47006> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47006] PEP 646: Decide on substitution behavior
Matthew Rahtz added the comment:
[Guido]
> What would be an example of a substitution that's too complex to do?
We also need to remember the dreaded arbitrary-length tuple. For example, I
think it should be the case that:
```python
T = TypeVar('T')
Ts = TypeVarTuple('Ts')
class C(Generic[*Ts]): pass
Alias = C[T, *Ts]
Alias2 = Alias[*tuple[int, ...]]
# Alias2 should be C[int, *tuple[int, ...]]
```
Ok, this is a bit of a silly example, but if we're committing to evaluating
substitutions correctly, we should probably make even this kind of example
behave correctly so that users who accidentally do something silly can debug
what's gone wrong.
[Serhiy]
> A repr can be less readable.
Definitely true.
> It will break equality comparison and hashing. Good bye caching.
Huh, I didn't know about this one. Fair enough, this is totally a downside.
> What about __origin__, __parameters__, __args__? How will they be calculated?
This could admittedly be thorny. We'd have to think it through carefully.
Admittedly also a downside.
> It can break code which uses annotations for something. For example it can
> break dataclasses.
Oh, also interesting - I didn't know about this one either. Could you give an
example?
> The first case will be practically fixed by GH 32030 after chenging the
> grammar to allow unpacking in index tuple: A[*B].
We actually deliberately chose not to unpack concrete tuple types - see the
description of https://github.com/python/cpython/pull/30398, under the heading
'Starred tuple types'. (If you see another way around it, though, let me know.)
> Two other cases will be fixed by GH 32031. It does not require any C code.
I'm also not sure about this one; disallowing unpacked TypeVarTuples in
argument lists to generic aliases completely (if I've understood right?) seems
like too restrictive a solution. I can imagine there might be completely
legitimate cases where the ability to do this would be important. For example:
```python
DType = TypeVar('DType')
Shape = TypeVarTuple('Shape')
class Tensor(Generic[DType, *Shape]): ...
Uint8Tensor = Tensor[uint8, *Shape]
Unit8BatchTensor = Uint8Tensor[Batch, *Shape]
```
> Note that the alternative proposition is even more lenient to errors.
True, but at least it's predictably lenient to errors - I think the repr makes
it very clear that "Woah, you're doing something advanced here. You're on your
own!" I think it better fits the principle of least astonishment to have
something that consistently lets through all errors of a certain class than
something that sometimes catches errors and sometimes doesn't.
--
___
Python tracker
<https://bugs.python.org/issue47006>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47081] Replace "qualifiers" with "quantifiers" in the re module documentation
Matthew Barnett added the comment: I don't think it's a typo, and you could argue the case for "qualifiers", but I still agree with the proposal as it's a more meaningful term in the context. -- ___ Python tracker <https://bugs.python.org/issue47081> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47023] re.sub shows key error on regex escape chars provided in repl param
Matthew Barnett added the comment: I'd just like to point out that to a user it could _look_ like a bug, that an error occurred while reporting, because the traceback isn't giving a 'clean' report; the stuff about the KeyError is an internal detail. -- ___ Python tracker <https://bugs.python.org/issue47023> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47006] PEP 646: Decide on substitution behavior
Matthew Rahtz added the comment: (Having said that, to be clear: my preferred solution currently would still be the solution where we just return a new GenericAlias for anything involving a TypeVarTuple. The crux is what Serhiy is happy with.) -- ___ Python tracker <https://bugs.python.org/issue47006> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47006] PEP 646: Decide on substitution behavior
Matthew Rahtz added the comment: Thanks for starting this, Jelle - I was a bit unsure about how to proceed here. Given that https://github.com/python/cpython/pull/31800 is already merged, I'd also propose something halfway between the two extremes: return a sensible substitution when the logic to compute that isn't too onerous, and a new GenericAlias object when it is. The upsides are that we'd probably be able to return reasonable substitutions for the vast majority of cases, and that we wouldn't have to remove what's already been merged. The downsides would be lack of consistency, and the potential for changing rules about what does and doesn't return a full substitution as time goes on and new features are added. -- nosy: +matthew.rahtz ___ Python tracker <https://bugs.python.org/issue47006> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43224] Add support for PEP 646
Change by Matthew Rahtz : -- pull_requests: +29945 pull_request: https://github.com/python/cpython/pull/31846 ___ Python tracker <https://bugs.python.org/issue43224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43224] Add support for PEP 646
Change by Matthew Rahtz : -- pull_requests: +29944 pull_request: https://github.com/python/cpython/pull/31845 ___ Python tracker <https://bugs.python.org/issue43224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43224] Add support for PEP 646
Change by Matthew Rahtz : -- pull_requests: +29943 pull_request: https://github.com/python/cpython/pull/31844 ___ Python tracker <https://bugs.python.org/issue43224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43224] Add support for PEP 646
Change by Matthew Rahtz : -- pull_requests: +29905 pull_request: https://github.com/python/cpython/pull/31804 ___ Python tracker <https://bugs.python.org/issue43224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46825] slow matching on regular expression
Matthew Barnett added the comment: The expression is a repeated alternative where the first alternative is a repeat. Repeated repeats can result in a lot of attempts and backtracking and should be avoided. Try this instead: (0|1(01*0)*1)+ -- ___ Python tracker <https://bugs.python.org/issue46825> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46627] Regex hangs indefinitely
Matthew Barnett added the comment: That pattern has: (?P[^]]+)+ Is that intentional? It looks wrong to me. -- ___ Python tracker <https://bugs.python.org/issue46627> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43478] Disallow Mock spec arguments from being Mocks
Change by Matthew Suozzo : -- pull_requests: +29275 pull_request: https://github.com/python/cpython/pull/31090 ___ Python tracker <https://bugs.python.org/issue43478> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46617] CSV Creation occasional off by one error
Matthew Stidham added the comment: the problem was a file in our library screwing up the python configuration -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46617> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46617] CSV Creation occasional off by one error
New submission from Matthew Stidham : The file which I found the error in is in https://github.com/greearb/lanforge-scripts -- components: C API files: debug from pandas failure.txt messages: 412400 nosy: matthewstidham priority: normal severity: normal status: open title: CSV Creation occasional off by one error type: compile error versions: Python 3.10, Python 3.8, Python 3.9 Added file: https://bugs.python.org/file50601/debug from pandas failure.txt ___ Python tracker <https://bugs.python.org/issue46617> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42369] Reading ZipFile not thread-safe
Matthew Davis added the comment: In addition to fixing any unexpected behavior, can we update the documentation [1] to state what the expected behavior is in terms of thread safety? [1] https://docs.python.org/3/library/zipfile.html -- nosy: +mdavis-xyz ___ Python tracker <https://bugs.python.org/issue42369> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46589] Improve documentation for typing._GenericAlias
New submission from Matthew Rahtz : There's currently not much documentation in `typing.py` for `_GenericAlias`. Some fairly weird things go on in there, so it would be great to have more info in the class about what's going on and why various edge cases are necessary. -- components: Library (Lib) messages: 412171 nosy: matthew.rahtz priority: normal pull_requests: 29210 severity: normal status: open title: Improve documentation for typing._GenericAlias type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46589> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43224] Add support for PEP 646
Change by Matthew Rahtz : -- pull_requests: +29202 pull_request: https://github.com/python/cpython/pull/31021 ___ Python tracker <https://bugs.python.org/issue43224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43224] Add support for PEP 646
Change by Matthew Rahtz : -- pull_requests: +29200 pull_request: https://github.com/python/cpython/pull/31019 ___ Python tracker <https://bugs.python.org/issue43224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43224] Add support for PEP 646
Change by Matthew Rahtz : -- pull_requests: +29199 pull_request: https://github.com/python/cpython/pull/31018 ___ Python tracker <https://bugs.python.org/issue43224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46515] Benefits Of Phool Makhana
Change by Matthew Barnett : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46515> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46410] TypeError when parsing regexp with unicode named character sequence escape
Matthew Barnett added the comment:
They're not supported in string literals either:
Python 3.10.1 (tags/v3.10.1:2cd268a, Dec 6 2021, 19:10:37) [MSC v.1929 64 bit
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> "\N{KEYCAP NUMBER SIGN}"
File "", line 1
"\N{KEYCAP NUMBER SIGN}"
^
SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in
position 0-21: unknown Unicode character name
--
___
Python tracker
<https://bugs.python.org/issue46410>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43224] Add support for PEP 646
Change by Matthew Rahtz : -- pull_requests: +28607 pull_request: https://github.com/python/cpython/pull/30398 ___ Python tracker <https://bugs.python.org/issue43224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43224] Add support for PEP 646
Change by Matthew Rahtz : -- components: +Parser, Tests nosy: +lys.nikolaou, pablogsal title: Add support for PEP 646 (Variadic Generics) to typing.py -> Add support for PEP 646 versions: +Python 3.11 -Python 3.10 ___ Python tracker <https://bugs.python.org/issue43224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46220] imaplib.py "select" mailbox names containing spaces.
New submission from Matthew H. McKenzie : A mailbox (folder) need not be for a recipient and need not be the private part of an RFC2822 address. Passing a value of "000 Bookings" to select() results in validation issues when the tokens are parsed as arguments and there are too many. It would be a nice-to-have to accept spaces in the name. Workaround is for a rule to be applied by a desktop email client such as Evolution to move it from the INBOX upon discovery according to filter criteria. -- components: Library (Lib) messages: 409457 nosy: mckenzm priority: normal severity: normal status: open title: imaplib.py "select" mailbox names containing spaces. type: enhancement versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue46220> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45899] NameError on if clause of class-level list comprehension
Matthew Barnett added the comment: It's not just in the 'if' clause: >>> class Foo: ... a = ['a', 'b'] ... b = ['b', 'c'] ... c = [b for x in a] ... Traceback (most recent call last): File "", line 1, in File "", line 4, in Foo File "", line 4, in NameError: name 'b' is not defined -- nosy: +mrabarnett ___ Python tracker <https://bugs.python.org/issue45899> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45869] Unicode and acii regular expressions do not agree on ascii space characters
Matthew Barnett added the comment:
For comparison, the regex module says that 0x1C..0x1F aren't whitespace, and
the Unicode property White_Space ("\p{White_Space}" in a pattern, where
supported) also says that they aren't whitespace.
--
___
Python tracker
<https://bugs.python.org/issue45869>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45746] ftplib please revisit retrlines('RETR as it produces files without newlines
Matthew H. McKenzie added the comment: To answer your original questions : Linux Host and Client, amd MVS (EBCDIC records) to Linux. hacks to overcome (in libftp): def print_line(line): '''Default retrlines callback to print a line.''' print(line, end='')< suppress here and... if not line: break if line[-2:] == CRLF: <== left these line = line[:-2] elif line[-1:] == '\n': line = line[:-1] callback(line + '\n') <== added it back here. -- ___ Python tracker <https://bugs.python.org/issue45746> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45746] ftplib please revisit retrlines('RETR as it produces files without newlines
Matthew H. McKenzie added the comment: On the face of it it is my mistake for using the write method for my file. But read on. your write_line() adds an EOL, OK, because it wraps print(). So the retrlines() function strips them in anticipation? The error is arguably in my own code as I am passing write() as the callback and it is my fault for not adding line endings back? Nothing at all wrong with write_line as the callback, it echoes perfectly, to the console. But my files have no EOL. I need the EOL in my file writes and that is my own problem. It would be maybe be an enhancement not to strip them from the host, as it should understand ascii as CRLF even if the client is not a CRLF system. But that adds complexity - it needs to work as is for listings. My uploaded file was what was being retrieved. Maybe close this and I'll just do what everybody else does and clone retrlines(). Sorry for your trouble. -- resolution: -> wont fix stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue45746> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45746] ftplib please revisit retrlines('RETR as it produces files without newlines
New submission from Matthew H. McKenzie :
Lib/ftplib.py function retrlines
Inspired by documentation the following writes a file without line-endings:
from ftplib import FTP
ftp=FTP()
ftp.connect('hostname')
ftp.login('user','')
ftp.sendcmd('pasv')
with open('crap2.txt', 'w') as fp:
ftp.retrlines('RETR crap.txt', fp.write)
Code goes to pains to slice off the line endings, and then print_line does not
add them back? Apologies if this has been covered before, or I am not following
the documentation correctly. Not going to suggest a fix as there may be a
reason it is like this.
For RETR.
For ascii
--
components: Library (Lib)
files: crap2.txt
messages: 405921
nosy: mckenzm
priority: normal
severity: normal
status: open
title: ftplib please revisit retrlines('RETR as it produces files without
newlines
versions: Python 3.11
Added file: https://bugs.python.org/file50429/crap2.txt
___
Python tracker
<https://bugs.python.org/issue45746>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45539] Negative lookaround assertions sometimes leak capture groups
Matthew Barnett added the comment: It's definitely a bug. In order for the pattern to match, the negative lookaround must match, which means that its subexpression mustn't match, so none of the groups in that subexpression have captured. -- versions: +Python 3.10 ___ Python tracker <https://bugs.python.org/issue45539> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45461] UnicodeDecodeError: 'unicodeescape' codec can't decode byte 0x5c in position 8191: \ at end of string
Matthew Barnett added the comment:
It can be shortened to this:
buffer = b"a" * 8191 + b"\\r\\n"
with open("bug_csv.csv", "wb") as f:
f.write(buffer)
with open("bug_csv.csv", encoding="unicode_escape", newline="") as f:
f.readline()
To me it looks like it's reading in blocks of 8K and then decoding them, but
it isn't correctly handling an escape sequence that happens to cross a block
boundary.
--
nosy: +mrabarnett
___
Python tracker
<https://bugs.python.org/issue45461>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45155] Add default arguments for int.to_bytes()
Matthew Barnett added the comment: I wonder whether there should be a couple of other endianness values, namely, "native" and "network", for those cases where you want to be explicit about it. If you use "big" it's not clear whether that's because you want network endianness or because the platform is big-endian. -- ___ Python tracker <https://bugs.python.org/issue45155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45155] Add default arguments for int.to_bytes()
Matthew Barnett added the comment: I'd probably say "In the face of ambiguity, refuse the temptation to guess". As there's disagreement about the 'correct' default, make it None and require either "big" or "little" if length > 1 (the default). -- nosy: +mrabarnett ___ Python tracker <https://bugs.python.org/issue45155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41254] Add to/from string methods to datetime.timedelta
Matthew Kenigsberg added the comment: I think it would be nice to have a from str method that could reverse the behavior of str(timedelta). I'm trying to parse files that contain the output of str(timedelta), and there's no easy way to get them back to timedelta's -- nosy: +matthewkenigsberg ___ Python tracker <https://bugs.python.org/issue41254> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39658] Include user scripts folder to PATH on Windows
Change by Matthew Morrissette Vance : -- nosy: +yinzara ___ Python tracker <https://bugs.python.org/issue39658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44745] Manual for python 3.9.6 will not let me search
New submission from Matthew Zielinski : The Manual for python 3.9.6 always says there are no entries. I searched things it definitely had, like modules, but it said there were no topics found. -- components: Library (Lib) files: Python Error.png messages: 398261 nosy: matthman2019 priority: normal severity: normal status: open title: Manual for python 3.9.6 will not let me search type: resource usage versions: Python 3.9 Added file: https://bugs.python.org/file50184/Python Error.png ___ Python tracker <https://bugs.python.org/issue44745> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44699] Simple regex appears to take exponential time in length of input
Matthew Barnett added the comment: It's called "catastrophic backtracking". Think of the number of ways it could match, say, 4 characters: 4, 3+1, 2+2, 2+1+1, 1+3, 1+2+1, 1+1+2, 1+1+1+1. Now try 5 characters... -- ___ Python tracker <https://bugs.python.org/issue44699> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44388] venv API Docs for EnvBuilder.ensure_directories incorrectly describe behavior
Matthew Clapp added the comment: To clarify my intent: I'd really love a way to get the paths info from context from an existing native venv without affecting the directories of the venv. It seems like this is what ensure_directories *actually* does if clear==False. I'm hoping that this is also something that could be pledged in the API and noted in the documentation so this behavior can be relied on. -- ___ Python tracker <https://bugs.python.org/issue44388> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44388] venv API Docs for EnvBuilder.ensure_directories incorrectly describe behavior
Change by Matthew Clapp : -- keywords: +patch pull_requests: +25250 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26663 ___ Python tracker <https://bugs.python.org/issue44388> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44388] venv API Docs for EnvBuilder.ensure_directories incorrectly describe behavior
New submission from Matthew Clapp : The docs for the venv module, EnvBuilder class, ensure_directories method, describe behavior that doesn't match what its actual behavior is, (and what the code is). I propose to update the documentation of the API to match the actual behavior. https://docs.python.org/3.9/library/venv.html#venv.EnvBuilder.ensure_directories The last sentence for ensure_directories(env_dir) reads: The directories are allowed to exist already, as long as either clear or upgrade were specified to allow operating on an existing environment directory. After testing and looking at the code (including past commits back over 6 years), this is not true. ensure_directories completely disregards the `upgrade` attribute. Also it allows directories to exist already unconditionally (always operating without error), whether the `clear` attribute is set or not. In addition, if `clear` is not set, it doesn't make any changes to the directories, but helpfully still returns the context of venv paths. Ref: https://github.com/python/cpython/blob/3ce35bfbbe29664942f9a8c50c177a4575a31934/Lib/venv/__init__.py#L95 -- assignee: docs@python components: Documentation messages: 395603 nosy: docs@python, itsayellow priority: normal severity: normal status: open title: venv API Docs for EnvBuilder.ensure_directories incorrectly describe behavior versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44388> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28937] str.split(): allow removing empty strings (when sep is not None)
Matthew Barnett added the comment:
I've only just realised that the test cases don't cover all eventualities: none
of them test what happens with multiple spaces _between_ the letters, such as:
' a b c '.split(maxsplit=1) == ['a', 'b c ']
Comparing that with:
' a b c '.split(' ', maxsplit=1)
you see that passing None as the split character does not mean "any whitespace
character". There's clearly a little more to it than that.
--
___
Python tracker
<https://bugs.python.org/issue28937>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28937] str.split(): allow removing empty strings (when sep is not None)
Matthew Barnett added the comment: We have that already, although it's spelled: ' x y z'.split(maxsplit=1) == ['x', 'y z'] because the keepempty option doesn't exist yet. -- ___ Python tracker <https://bugs.python.org/issue28937> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28937] str.split(): allow removing empty strings (when sep is not None)
Matthew Barnett added the comment:
The best way to think of it is that .split() is like .split(' '), except that
it's splitting on any whitespace character instead of just ' ', and keepempty
is defaulting to False instead of True.
Therefore:
' x y z'.split(maxsplit=1, keepempty=True) == ['', ' x y z']
because:
' x y z'.split(' ', maxsplit=1) == ['', ' x y z']
but:
' x y z'.split(maxsplit=1, keepempty=False) == ['x y z']
At least, I think that's the case!
--
___
Python tracker
<https://bugs.python.org/issue28937>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28937] str.split(): allow removing empty strings (when sep is not None)
Matthew Barnett added the comment: The case: ' a b c '.split(maxsplit=1) == ['a', 'b c '] suggests that empty strings don't count towards maxsplit, otherwise it would return [' a b c '] (i.e. the split would give ['', ' a b c '] and dropping the empty strings would give [' a b c ']). -- ___ Python tracker <https://bugs.python.org/issue28937> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Repair Install of 64 bit python
Hi, Having an issue after installing 64 bit python. Can't pip install any packages. Get the error "No module named pip". Thanks, Matt Matthew Dodson 2020 Data Analytics/Video Intern New York Football Giants Quest Diagnostics Training Center 1925 Giants Drive East Rutherford, NJ 07073 o: 201-806-1749 matthew.dod...@giants.nfl.net This e-mail is intended only for the use of the individual or entity named above and contains confidential and privileged information. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender of the e-mail and destroy the original message. UNLESS CLEARLY STATED, NOTHING IN THIS E-MAIL, IN ANY E-MAIL THREAD OF WHICH IT MAY BE A PART, OR IN ANY ATTACHMENTS THERETO, SHALL CONSTITUTE A BINDING CONTRACT, OR ANY CONTRACTUAL OBLIGATION, OR ANY INTENT TO ENTER INTO ANY BINDING OBLIGATIONS. -- https://mail.python.org/mailman/listinfo/python-list
[issue37251] Mocking a MagicMock with a function spec results in an AsyncMock
Change by Matthew Suozzo : -- pull_requests: +24081 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/25347 ___ Python tracker <https://bugs.python.org/issue37251> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37251] Mocking a MagicMock with a function spec results in an AsyncMock
Matthew Suozzo added the comment: I don't think this was actually fixed for the create_autospec case. create_autospec still uses the only is_async_func check to enable use of AsyncMock and that still does a __code__ check. There was a test submitted to check this case but the test itself was bugged and discovered in the process of implementing https://bugs.python.org/issue43478. -- nosy: +matthew.suozzo ___ Python tracker <https://bugs.python.org/issue37251> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43478] Disallow Mock spec arguments from being Mocks
Change by Matthew Suozzo : -- keywords: +patch nosy: +matthew.suozzo nosy_count: 7.0 -> 8.0 pull_requests: +24061 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25326 ___ Python tracker <https://bugs.python.org/issue43478> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43798] Add position metadata to alias AST type
Matthew Suozzo added the comment: Ah and one other question: Is this normally the sort of thing that would get backported? It should be very straightforward to do so, at least for 3.9 given the support for the new parser. -- versions: -Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue43798> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43798] Add position metadata to alias AST type
Change by Matthew Suozzo : -- keywords: +patch pull_requests: +24059 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25324 ___ Python tracker <https://bugs.python.org/issue43798> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43798] Add position metadata to alias AST type
New submission from Matthew Suozzo : Given the increasing use of long `from typing import foo, bar, ...` import sequences, it's becoming more desirable to address individual components of the import node. Unfortunately, the ast.alias node doesn't contain source location metadata (e.g. lineno, col_offset). This metadata would be comparatively easy to add, backwards compatible, and would enable more precise diagnostics e.g. lints. -- components: Interpreter Core messages: 390663 nosy: matthew.suozzo priority: normal severity: normal status: open title: Add position metadata to alias AST type type: enhancement versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43798> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43714] re.split(), re.sub(): '\Z' must consume end of string if it matched
Matthew Barnett added the comment: Do any other regex implementations behave the way you want? In my experience, there's no single "correct" way for a regex to behave; different implementations might give slightly different results, so if the most common ones behave a certain way, then that's the de facto standard, even if it not what you'd expect or want. -- nosy: +mrabarnett ___ Python tracker <https://bugs.python.org/issue43714> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43535] Make str.join auto-convert inputs to strings.
Matthew Barnett added the comment: I'm also -1, for the same reason as Serhiy gave. However, if it was opt-in, then I'd be OK with it. -- nosy: +mrabarnett ___ Python tracker <https://bugs.python.org/issue43535> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43478] Disallow Mock spec arguments from being Mocks
Matthew Suozzo added the comment: And to give some context for the above autospec child bit, this is the relevant code that determines the spec to use for each child: https://github.com/python/cpython/blob/master/Lib/unittest/mock.py#L2671-L2696 -- ___ Python tracker <https://bugs.python.org/issue43478> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43478] Disallow Mock spec arguments from being Mocks
Matthew Suozzo added the comment: A few more things: Assertions on Mock-autospec'ed Mocks will silently pass since e.g. assert_called_once_with will now be mocked out. This may justify a more stringent stance on the pattern since it risks hiding real test failures. One complicating factor with the implementation is that autospec'd objects may have children that are already Mocked out. Failing eagerly, however, would break cases where the child is never used (and consequently risk causing more friction than may be necessary) but failing only upon access of that child makes it trickier for the user to trace back to where the parent was mocked. -- ___ Python tracker <https://bugs.python.org/issue43478> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43478] Disallow Mock spec arguments from being Mocks
Matthew Suozzo added the comment: I've fixed a bunch of these in our internal repo so I'd be happy to add that to a patch implementing raising exceptions for these cases. -- ___ Python tracker <https://bugs.python.org/issue43478> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43322] Inconsistent '#include' notation in extensions tutorial doc
Change by Matthew Hughes : -- keywords: +patch pull_requests: +23612 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24851 ___ Python tracker <https://bugs.python.org/issue43322> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43478] Disallow Mock spec arguments from being Mocks
New submission from Matthew Suozzo : An unfortunately common pattern over large codebases of Python tests is for spec'd Mock instances to be provided with Mock objects as their specs. This gives the false sense that a spec constraint is being applied when, in fact, nothing will be disallowed. The two most frequently observed occurrences of this anti-pattern are as follows: * Re-patching an existing autospec. def setUp(self): mock.patch.object(mod, 'Klass', autospec=True).start() self.addCleanup(mock.patch.stopall) @mock.patch.object(mod, 'Klass', autospec=True) # :( def testFoo(self, mock_klass): # mod.Klass has no effective spec. * Deriving an autospec Mock from an already-mocked object def setUp(self): mock.patch.object(mod, 'Klass').start() ... mock_klass = mock.create_autospec(mod.Klass) # :( # mock_klass has no effective spec This is fairly easy to detect using _is_instance_mock at patch time however it can break existing tests. I have a patch ready and it seems like this error case is not frequent enough that it would be disruptive to address. Another option would be add it as a warning for a version e.g. 3.10 and then potentially make it a breaking change in 3.11. However considering this is a test-only change with a fairly clear path to fix it, that might be overly cautious. -- components: Tests messages: 388532 nosy: msuozzo priority: normal severity: normal status: open title: Disallow Mock spec arguments from being Mocks type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43478> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43340] json.load() can raise UnicodeDecodeError, but this is not documented
New submission from Matthew Woodcraft : The documentation for json.load() and json.loads() says: « If the data being deserialized is not a valid JSON document, a JSONDecodeError will be raised. » But this is not currently entirely true: if the data is provided in bytes form and is not properly encoded in one of the three accepted encodings, UnicodeDecodeError is raised instead. (I have no opinion on whether the documentation or the behaviour should be changed.) -- components: Library (Lib) messages: 387780 nosy: mattheww priority: normal severity: normal status: open title: json.load() can raise UnicodeDecodeError, but this is not documented type: behavior versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43340> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43322] Inconsistent '#include' notation in extensions tutorial doc
New submission from Matthew Hughes : Just a small thing in these docs, there is a mix of "#include ", e.g. https://github.com/python/cpython/blame/master/Doc/extending/newtypes_tutorial.rst#L243 and '#include "structmember.h"', mostly in the included samples e.g. https://github.com/python/cpython/blob/master/Doc/includes/custom2.c#L3. Should these all be the same? -- assignee: docs@python components: Documentation messages: 387679 nosy: docs@python, mhughes priority: normal severity: normal status: open title: Inconsistent '#include' notation in extensions tutorial doc versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue43322> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43224] Add support for PEP 646 (Variadic Generics) to typing.py
Change by Matthew Rahtz : -- keywords: +patch nosy: +matthew.rahtz nosy_count: 1.0 -> 2.0 pull_requests: +23313 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24527 ___ Python tracker <https://bugs.python.org/issue43224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43224] Add support for PEP 646 (Variadic Generics) to typing.py
Change by Matthew Rahtz : -- components: Library (Lib) nosy: mrahtz priority: normal severity: normal status: open title: Add support for PEP 646 (Variadic Generics) to typing.py versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43156] Python windows installer has a confusing name - add setup to its name
Matthew Barnett added the comment: Sorry to bikeshed, but I think it would be clearer to keep the version next to the "python" and the "setup" at the end: python-3.10.0a5-win32-setup.exe python-3.10.0a5-win64-setup.exe -- nosy: +mrabarnett ___ Python tracker <https://bugs.python.org/issue43156> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42871] Regex compilation crashed if I change order of alternatives under quantifier
Matthew Barnett added the comment: Example 1: ((a)|b\2)* ^^^ Group 2 ((a)|b\2)* ^^ Reference to group 2 The reference refers backwards to the group. Example 2: (b\2|(a))* ^^^ Group 2 (b\2|(a))* ^^ Reference to group 2 The reference refers forwards to the group. As I said, the re module doesn't support forward references to groups. If you have a regex where forward references are unavoidable, try the 3rd-party 'regex' module instead. It's available on PyPI. -- ___ Python tracker <https://bugs.python.org/issue42871> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42871] Regex compilation crashed if I change order of alternatives under quantifier
Matthew Barnett added the comment: It's not a crash. It's complaining that you're referring to group 2 before defining it. The re module doesn't support forward references to groups, but only backward references to them. -- ___ Python tracker <https://bugs.python.org/issue42871> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42668] re.escape does not correctly escape newlines
Matthew Barnett added the comment: In a regex, putting a backslash before any character that's not an ASCII-range letter or digit makes it a literal. re.escape doesn't special-case control characters. Its purpose is to make a string that might contain metacharacters into one that's a literal, and it already does that, although it sometimes escapes more than necessary. -- ___ Python tracker <https://bugs.python.org/issue42668> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42551] Generator `yield`s counted as primitive calls by cProfile
Matthew Suozzo added the comment: One of the problems with my proposed solution that I glossed over was how and where to count the primitive call. If the primitive call is only registered on RETURN (i.e. after all yields), a generator that is incompletely exhausted would have 0 primitive calls. However if the primitive call is registered immediately when the call context is entered, the recorded call would be instantaneous (i.e. 0s duration) which could throw off the percall statistics. Even with the incomplete generator case, I think registering the primitive call on RETURN is the best of the two options. Although seeing 2/0 for the call count when RETURN wasn't reached might seem odd, it lines up with a conceptual model of a coroutine: An iterator represents a function returning a sequence; Exhausting that iterator corresponds to the function call completing; Incompletely exhausting corresponds to an abbreviated/incomplete function call. -- ___ Python tracker <https://bugs.python.org/issue42551> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42633] Wave documentation doesn't mention signed/unsigned requirements
New submission from Matthew Walker : It would be very useful if the documentation for Python's Wave module mentioned that 8-bit samples must be unsigned while 16-bit samples must be signed. See the Wikipedia article on the WAV format: "There are some inconsistencies in the WAV format: for example, 8-bit data is unsigned while 16-bit data is signed" https://en.wikipedia.org/wiki/WAV Although I haven't contributed previously, I would be pleased to make such a contribution if it would be appreciated. -- assignee: docs@python components: Documentation messages: 382957 nosy: docs@python, mattgwwalker priority: normal severity: normal status: open title: Wave documentation doesn't mention signed/unsigned requirements type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42633> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42551] Generator `yield`s counted as primitive calls by cProfile
New submission from Matthew Suozzo :
# Issue
When profiling a generator function, the initial call and all subsequent yields
are aggregated into the same "ncalls" metric by cProfile.
## Example
>>> cProfile.run("""
... def foo():
... yield 1
... yield 2
... assert tuple(foo()) == (1, 2)
... """)
ncalls tottime percall cumtime percall filename:lineno(function)
...
30.0000.0000.0000.000 :2(foo)
...
This was unexpected behavior since it *looks* like a single call from the code.
This also complicates basic analysis about the frequency of a codepath's
execution where a generator might yield a variable number of times depending on
the input.
The profile interface can and does differentiate between call types: Normal
calls and "primitive" calls, i.e. those that are not induced via recursion, are
displayed as "all_calls/primitive_calls" e.g. "3/1" for a single initial calls
with 2 recursed calls (comparable to the example above).
This seems like an appropriate abstraction to apply in the generator case: Each
yield is better modeled as an 'interior' call to the generator, not as a call
on its own.
# Possible fix
I have two ideas that seem like they might address the problem:
* Add a new PyTrace_YIELD constant (and handle it in [3])
* Track some state from the `frame->f_gen` in the ProfilerEntry (injected in
[3], used in [4]) to determine whether this is the first or a subsequent call.
I've not been poking around for long so I don't have an intuition about which
would be less invasive (nor really whether either would work in practice).
As background, this seems to be the call chain from trace invocation to
callcount increment:
[0]:
https://github.com/python/cpython/blob/4e7a69bdb63a104587759d7784124492dcdd496e/Python/ceval.c#L4106-L4107
[1]:
https://github.com/python/cpython/blob/4e7a69bdb63a104587759d7784124492dcdd496e/Python/ceval.c#L4937
[2]:
https://github.com/python/cpython/blob/4e7a69bdb63a104587759d7784124492dcdd496e/Python/ceval.c#L4961
[3]:
https://github.com/python/cpython/blob/4e7a69bdb63a104587759d7784124492dcdd496e/Modules/_lsprof.c#L419
[4]:
https://github.com/python/cpython/blob/4e7a69bdb63a104587759d7784124492dcdd496e/Modules/_lsprof.c#L389
[5]:
https://github.com/python/cpython/blob/4e7a69bdb63a104587759d7784124492dcdd496e/Modules/_lsprof.c#L311-L316
--
components: C API
messages: 382373
nosy: matthew.suozzo
priority: normal
severity: normal
status: open
title: Generator `yield`s counted as primitive calls by cProfile
type: behavior
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue42551>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39116] StreamReader.readexactly() raises GeneratorExit on ProactorEventLoop
Matthew added the comment: Let me preface this by declaring that I am very new to Python async so it is very possible that I am missing something seemingly obvious. That being said, I've been looking at various resources to try to understand the internals of asyncio and it hasn't led to any insights on this problem thus far. - This all sounds quite similar to an experience I am dealing with. I'm working with pub sub within aioredis which internally uses a StreamReader with a function equivalent to readexactly. This all started from debugging "Task was destroyed but it is pending!" to which attempted fixes led to multiple "RuntimeError: aclose(): asynchronous generator is already running" errors. I did the same thing, adding try excepts everywhere in my code to understand what was happening and this led me to identifying that a regular async function would raise GeneratorExit during await. However, even if I suppress this, the caller awaiting on this function would also raise a GeneratorExit. Suppressing this exception at the top level leads to an unsuspecting (to me) error "coroutine ignored GeneratorExit". I understand that GeneratorExit is raised in unfinished generators when garbage collected to handle cleanup. And I understand that async functions are essentially a generator in the sense that they yield when they await. So, if the entire coroutine were garbage collected this might trigger GeneratorExit in each nested coroutine. However, from all of my logging I am sure that prior to the GeneratorExit, nothing returns upwards so there should still be valid references to every object. I'll include some errors below, in case they may be of relevance: === Exception in await of inner async function === Traceback (most recent call last): File ".../site-packages/uvicorn/protocols/http/httptools_impl.py", line 165, in data_received self.parser.feed_data(data) File "httptools/parser/parser.pyx", line 196, in httptools.parser.parser.HttpParser.feed_data httptools.parser.errors.HttpParserUpgrade: 858 During handling of the above exception, another exception occurred: Traceback (most recent call last): File ".../my_code.py", line 199, in wait_for_update return await self.waiter.wait_for_value() GeneratorExit === Exception when suppressing GeneratorExit on the top level === Exception ignored in: Traceback (most recent call last): File ".../site-packages/websockets/protocol.py", line 229, in __init__ self.reader = asyncio.StreamReader(limit=read_limit // 2, loop=loop) RuntimeError: coroutine ignored GeneratorExit -- nosy: +matthew ___ Python tracker <https://bugs.python.org/issue39116> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42475] wrongly cache pattern by re.compile
Matthew Barnett added the comment: That behaviour has nothing to do with re. This line: samples = filter(lambda sample: not pttn.match(sample), data) creates a generator that, when evaluated, will use the value of 'pttn' _at that time_. However, you then bind 'pttn' to something else. Here's a simple example: >>> x = 1 >>> func = lambda: print(x) >>> func() 1 >>> x = 2 >>> func() 2 A workaround is to capture the current value with a default argument: >>> x = 1 >>> func = lambda x=x: print(x) >>> func() 1 >>> x = 2 >>> func() 1 -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue42475> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42473] re.sub ignores flag re.M
Matthew Barnett added the comment: Not a bug. Argument 4 of re.sub is the count: sub(pattern, repl, string, count=0, flags=0) not the flags. -- nosy: +mrabarnett resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue42473> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42353] Proposal: re.prefixmatch method (alias for re.match)
Matthew Suozzo added the comment: > It just won't work unless you add explicit ".*" or ".*?" at the start of the > pattern But think of when regexes are used for validating input. Getting it to "just work" may be over-permissive validation that only actually checks the beginning of the input. They're one missed test case away from a crash or, worse, a security issue. This proposed name change would help make the function behavior obvious at the callsite. In the validator example, calling "prefixmatch" would stand out as wrong to even the most oblivious, documentation-averse user. > My point is that re.match is a common bug when people really want re.search. While I think better distinguishing the interfaces is a nice-to-have for usability, I think it has more absolute benefit to correctness. Again, confusion around the semantics of "match" were the motivation for adding "fullmatch" in the first place but that change only went so far to address the problem: It's still too easy to misuse the existing "match" interface and it's not realistic to remove it from the language. A new name would eliminate this class of error at a very low cost. -- nosy: +matthew.suozzo ___ Python tracker <https://bugs.python.org/issue42353> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41885] Unexpected behavior re.sub() with raw f-strings
Matthew Barnett added the comment:
Arguments are evaluated first and then the results are passed to the function.
That's true throughout the language.
In this instance, you can use \g<1> in the replacement string to refer to group
1:
re.sub(r'([a-z]+)', fr"\g<1>{REPLACEMENT}", 'something')
--
___
Python tracker
<https://bugs.python.org/issue41885>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41788] enhancement: add assertDuration context manager to unittest module
New submission from Matthew Davis : # Summary I propose an additional unit test type for the unittest module. TestCase.assertDuration(min=None, max=None), which is a context manager, similar to assertRaises. It runs the code inside it, and then fails the test if the duration of the code inside was not between min and max. # Use case I want to check that when I call a certain function in my application, it doesn't take far more time than I expect, or far less time. e.g. if I'm trying to do things concurrently, I want to test that they are indeed concurrent, by measuring whether the duration equals the sum of all processes' duration, or the max. # MWE ``` import unittest from time import sleep, time from multiprocessing import Pool def slow(x): sleep(x) # blocking sleep for 0, 1, 2, 3 seconds, concurrently def together(): with Pool(4) as p: p.map(slow, range(4)) class TestConcurrent(unittest.TestCase): # this is how you do it today def test_today(self): start = time() together() end = time() duration = end - start self.assertGreaterEqual(duration, 2) # max should be 3 seconds, plus some overhead # if together() called slow() in series, # total duration would be 0 + 1 + 2 + 3 = 6 > 4 self.assertLessEqual(duration, 4) # this is how I want to do it def test_simpler(self): with self.assertDuration(min=2, max=4): together() ``` # Solution I just need to add a new context manager next to this one: https://github.com/python/cpython/blob/6b34d7b51e33fcb21b8827d927474ce9ed1f605c/Lib/unittest/case.py#L207 -- components: Library (Lib) messages: 376923 nosy: matt-davis priority: normal severity: normal status: open title: enhancement: add assertDuration context manager to unittest module ___ Python tracker <https://bugs.python.org/issue41788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41764] sub function would not work without the flags but the search would work fine
Matthew Barnett added the comment:
The arguments are: re.sub(pattern, repl, string, count=0, flags=0).
Therefore:
re.sub("pattern","replace", txt, re.IGNORECASE | re.DOTALL)
is passing re.IGNORECASE | re.DOTALL as the count, not the flags.
It's in the documentation and the interactive help.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue41764>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41664] re.sub does NOT substitute all the matching patterns when re.IGNORECASE is used
Matthew Barnett added the comment: The 4th argument of re.sub is 'count', not 'flags'. re.IGNORECASE has the numeric value of 2, so: re.sub(r'[aeiou]', '#', 'all is fair in love and war', re.IGNORECASE) is equivalent to: re.sub(r'[aeiou]', '#', 'all is fair in love and war', count=2) -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue41664> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41531] Python 3.9 regression: Literal dict with > 65535 items are one item shorter
Matthew Barnett added the comment: I think what's happening is that in 'compiler_dict' (Python/compile.c), it's checking whether 'elements' has reached a maximum (0x). However, it's not doing this after incrementing; instead, it's checking before incrementing and resetting 'elements' to 0 when it should be resetting to 1. The 65535th element isn't counted. -- nosy: +mrabarnett ___ Python tracker <https://bugs.python.org/issue41531> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29056] logging.Formatter doesn't respect more than one formatException()
Matthew Davis added the comment: The documentation says "you will have to clear the cached value" What does that mean? How do I clear the cached value? Is there a flush function somewhere? Do I `del` the attribute? Set the attribute to None? The documentation as it stands today does not provide enough detail about this workaround. -- nosy: +matt-davis ___ Python tracker <https://bugs.python.org/issue29056> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41255] Argparse.parse_args exits on unrecognized option with exit_on_error=False
Matthew Hughes added the comment: I've attached a patch containing tests showing the current behavior, namely that exit_on_error does not change the behavior of argparse.ArgumentParser.parse_args in either case: * An unrecognized option is given * A required option is not given Should the docs be updated to note this? -- keywords: +patch Added file: https://bugs.python.org/file49310/exit_on_error_tests.patch ___ Python tracker <https://bugs.python.org/issue41255> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41255] Argparse.parse_args exits on unrecognized option with exit_on_error=False
Matthew Hughes added the comment: > typo in the docs that it should have used enabled instead of enable Well spotted, I'll happily fix this up. > I guess the docs by manually mean that ArgumentError will be raised when > exit_on_error is False that can be handled. To be clear, in this case, even with exit_on_error=False, ArgumentError is _not_ being raised, but SystemExit is. -- versions: -Python 3.9 ___ Python tracker <https://bugs.python.org/issue41255> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41255] Argparse.parse_args exits on unrecognized option with exit_on_error=False
New submission from Matthew Hughes : >>> import argparse >>> parser = argparse.ArgumentParser(exit_on_error=False) >>> parser.parse_args(["--unknown"]) usage: [-h] : error: unrecognized arguments: --unknown The docs https://docs.python.org/3.10/library/argparse.html#exit-on-error say: > Normally, when you pass an invalid argument list to the parse_args() method > of an ArgumentParser, it will exit with error info. > If the user would like catch errors manually, the feature can be enable by > setting exit_on_error to False: This description _appears_ to be at odds with the observed behavior. -- components: Library (Lib) messages: 373382 nosy: mhughes priority: normal severity: normal status: open title: Argparse.parse_args exits on unrecognized option with exit_on_error=False type: behavior versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue41255> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37322] test_ssl: test_pha_required_nocert() emits a ResourceWarning
Change by Matthew Hughes : -- pull_requests: +20541 pull_request: https://github.com/python/cpython/pull/21393 ___ Python tracker <https://bugs.python.org/issue37322> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37322] test_ssl: test_pha_required_nocert() emits a ResourceWarning
Matthew Hughes added the comment: Whoops, I realise the patch I shared contained a combination of two (independent) approaches I tried: 1. Add sleep and perform cleanup 2. Naively patch catch_threading_exception to accept a cleanup routine to be run upon exiting but before removing the thread. -- ___ Python tracker <https://bugs.python.org/issue37322> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
