[issue43323] UnicodeEncodeError: surrogates not allowed when parsing invalid charset
John Paul Adrian Glaubitz added the comment: > Awesome, thanks! I'll give it a try later today or tomorrow. I have applied the patch and the problem seems to have been fixed. \o/ -- ___ Python tracker <https://bugs.python.org/issue43323> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43323] UnicodeEncodeError: surrogates not allowed when parsing invalid charset
John Paul Adrian Glaubitz added the comment: Awesome, thanks! I'll give it a try later today or tomorrow. -- ___ Python tracker <https://bugs.python.org/issue43323> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43323] UnicodeEncodeError: surrogates not allowed when parsing invalid charset
John Paul Adrian Glaubitz added the comment: Hi Serhiy! > The simple fix is to add UnicodeEncodeError to "except LookupError". But > there may be other places where we can get a similar error. They should be > fixed too. I would be very interested to test this as this issue currently blocks my use of offlineimap. Would you mind creating a proof-of-concept patch for me if it's not too much work? Thanks! -- ___ Python tracker <https://bugs.python.org/issue43323> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44807] typing.Protocol silently overrides __init__ method of delivered class
Adrian Garcia Badaracco added the comment: I am not sure if that solves anything (other than the fact that __new__ is much less common to implement than __init__), but I may just be slow to pick up the implications of moving the check to __new__ -- ___ Python tracker <https://bugs.python.org/issue44807> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44807] typing.Protocol silently overrides __init__ method of delivered class
Adrian Garcia Badaracco added the comment: Guido, it looks like you replied while I was typing my reply out. Yurii can correct me here but I believe PR #27543 was an attempt to disallow defining `__init__` on a Protocol completely. What I proposed above is the opposite behavior, while still fixing the issue of `__init__` getting silently overridden (which is the crux / title of this issue). I'm not sure which approach is right. -- ___ Python tracker <https://bugs.python.org/issue44807> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44807] typing.Protocol silently overrides __init__ method of delivered class
Adrian Garcia Badaracco added the comment: Agreed. What if we allow protocols that implement `__init__` but still disallow instantiating a protocol that does not? It's a 1 line change, all existing tests pass and it would still catch what I think was the original intention (trying to instantiate a Protocol class with no __init__): https://github.com/python/cpython/pull/31628/files#diff-ddb987fca5f5df0c9a2f5521ed687919d70bb3d64eaeb8021f98833a2a716887 -- ___ Python tracker <https://bugs.python.org/issue44807> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44807] typing.Protocol silently overrides __init__ method of delivered class
Change by Adrian Garcia Badaracco : -- pull_requests: +29750 stage: test needed -> patch review pull_request: https://github.com/python/cpython/pull/31628 ___ Python tracker <https://bugs.python.org/issue44807> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44807] typing.Protocol silently overrides __init__ method of delivered class
Adrian Garcia Badaracco added the comment: Apologies if that was noise, I filed an issue on the MyPy issue tracker: https://github.com/python/mypy/issues/12261 -- ___ Python tracker <https://bugs.python.org/issue44807> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44807] typing.Protocol silently overrides __init__ method of delivered class
Adrian Garcia Badaracco added the comment:
While this is figured out, would it be possible to remove the silent
overriding? This seems like something type checkers should be doing, not silent
runtime modification of classes. Pyright already (correctly) checks this, so I
think it would just need to be added to MyPy.
>>> class C(Protocol):
... def __init__(self) -> None:
... print('init!')
...
>>> c = C() # Pyright error, MyPy says it's okay
I came across this while trying to create a class that requires concrete
subclasses to define a specific field, and it seems like Protocol is the only
thing that can pull this off because of how type checkers special case it:
https://gist.github.com/adriangb/6c1a001ee7035bad5bd56df70e0cf5e6
I don't particularly like this use of Protocol, but it works (aside from the
overriding issue).
I don't know if this usage of implementing `__init__` on a protocol class
should be valid or not, but I do think it's interesting that `__init__` is
never called on the protocol class itself, even if the protocol class is the
one defining it. It is only called on `MyAPIKey`, which is a concrete class
that happens to inherit the implementation from a protocol class. So maybe that
should be valid? I'm not sure.
But I do know that making type checkers enforce this instead runtime would
allow this use case to work while still prohibiting the (in my opinion invalid)
use case of calling `__init__` on the protocol class itself.
--
nosy: +adriangb
status: pending -> open
___
Python tracker
<https://bugs.python.org/issue44807>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31242] Add SSLContext.set_verify_callback()
Adrian Freund added the comment: I also need this feature for something I'm working on, so I looked into it a bit and pushed a small proof of concept implementation to GitHub (See PR 31391). I'm not sure if I'll have enough time to finish and clean up this implementation, but at least there is a starting point. I also opened bpo-46779 as a simpler method to solve most of the usecases that would be solved by this api. -- versions: +Python 3.11 -Python 3.8 ___ Python tracker <https://bugs.python.org/issue31242> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46779] Add ssl.CERT_REQUIRED_NO_VERIFY as possible value for ssl.SSLContext.verify_mode
New submission from Adrian Freund : Some networked applications might require connecting to client with invalid certificates but still requiring the client to send a certificate. ssl.SSLContext.verify_mode currently supports the following options: ssl.CERT_NONE: Don't require the client to send a certificate and don't validate it if they send one anyways. ssl.CERT_OPTIONAL: Don't require the client to send a certificate but validate it if they send one. ssl.CERT_REQUIRED: Require the client to send a certificate and validate it. There is currently no option for servers that want to require the client to send a certificate but don't validate it. This would for example be needed it a server should accept clients with self-signed certificates and then store their certificates to recognize them again later. A concrete example is the KDEConnect protocol. An alternative solution would be bpo-31242. That would also solve this problem is a more general, but also more complicated way. I think that the solution proposed here this issue is better for it's simplicity and also solves most usecases for bpo-31242. Note that a ssl.CERT_REQUIRED_NO_VERIFY was already proposed in bpo-18293, but that issue was closed because it was specifically in relation to a deprecated api. The mentioned values are however also used in modern asyncio apis. -- assignee: christian.heimes components: SSL messages: 413416 nosy: christian.heimes, freundTech priority: normal severity: normal status: open title: Add ssl.CERT_REQUIRED_NO_VERIFY as possible value for ssl.SSLContext.verify_mode type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46779> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31242] Add SSLContext.set_verify_callback()
Change by Adrian Freund : -- keywords: +patch pull_requests: +29536 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/31391 ___ Python tracker <https://bugs.python.org/issue31242> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31242] Add SSLContext.set_verify_callback()
Change by Adrian Freund : -- nosy: +freundTech ___ Python tracker <https://bugs.python.org/issue31242> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33017] Special set-cookie setting will bypass Cookielib
Adrian Chaves added the comment: So, PoC shows how an empty domain attribute (Domain=) is erroneously turned into a dot (.). I want to add that a dot (Domain=.) should be turned into an empty string (the specification asks to remove a leading dot if found). -- nosy: +adrian2 ___ Python tracker <https://bugs.python.org/issue33017> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43323] UnicodeEncodeError: surrogates not allowed when parsing invalid charset
John Paul Adrian Glaubitz added the comment: I'm running into exactly this issue when using 'offlineimap' which is written in Python. -- nosy: +glaubitz ___ Python tracker <https://bugs.python.org/issue43323> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17005] Add a topological sort algorithm
Adrian Garcia Badaracco added the comment: As part of working on a tool that deals with dependencies, I was building my own topological sort. I iterated through various APIs (iterable of tasks, iterable of parallelizable groups of tasks, etc.) until I found the (now stdlib) version which ended up being exactly the API I needed to most efficiently execute dependencies. So, kudos on the design! I actually ended up re-writing it in Rust, partly because I wanted a good project to learn Rust, partly because I wanted to be able to modify the API a bit. Namely: 1. I needed the ability to re-execute the same DAG multiple times without re-checking for cycles and re-adding all nodes (so basically copying `npredecessors` before executing). 2. I needed the ability to remove nodes from the graph. The real-world application is removing pruning subgraphs corresponding to cached dependencies. Again, I wanted to do this without rebuilding the entire thing (removing nodes can never lead to a cycle, and it is possible to keep track of new leaf nodes as you remove them instead of iterating over the entire graph again to find leaf nodes). Here's the implementation in case anyone is interested: https://github.com/adriangb/graphlib2 The algorithm is the same, but I had to change the data structures somewhat to cope w/ Rusts' borrowing rules (namely I can't hold a mutable reference to two values in `node2nodeinfo` at the same time, which the current implementation does here https://github.com/python/cpython/blob/32f1491a9770b7f2989507ecf8f13ef35dd95b0b/Lib/graphlib.py#L190, so I split them out into two separate mappings). -- nosy: +adriangb ___ Python tracker <https://bugs.python.org/issue17005> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26175] Fully implement IOBase abstract on SpooledTemporaryFile
Change by Adrian Garcia Badaracco : -- nosy: +adriangb ___ Python tracker <https://bugs.python.org/issue26175> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44834] contextvars.Context.run w/ coroutines gives inconsistent behavior
Change by Adrian Garcia Badaracco : -- nosy: +yselivanov ___ Python tracker <https://bugs.python.org/issue44834> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42815] new thread doesn't copy context of the parent thread
Change by Adrian Garcia Badaracco : -- nosy: +adriangb ___ Python tracker <https://bugs.python.org/issue42815> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44834] contextvars.Context.run w/ coroutines gives inconsistent behavior
New submission from Adrian Garcia Badaracco :
I recently tried to use `contextvars.Context.run` w/ coroutines, expecting the
same behavior as with regular functions, but it seems that
`contextvars.Context.run` does not work w/ coroutines.
I'm sorry if this is something obvious to do with how coroutines work under the
hood, if so I'd appreciate some help in understanding why this is the expected
behavior.
```python
import asyncio
import contextvars
ctxvar = contextvars.ContextVar("ctxvar", default="spam")
def func():
assert ctxvar.get() == "spam"
async def coro():
func()
async def main():
ctx = contextvars.copy_context()
ctxvar.set("ham")
ctx.run(func) # works
await ctx.run(coro) # breaks
asyncio.run(main())
```
Thanks!
--
components: Library (Lib)
messages: 398924
nosy: adriangb
priority: normal
severity: normal
status: open
title: contextvars.Context.run w/ coroutines gives inconsistent behavior
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue44834>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43994] change representation of match as / capture as `Name(..., ctx=Store())`
Adrian Freund added the comment: I already brought this up on the main pattern matching issue some time ago (https://bugs.python.org/issue42128#msg388554), where the consensus was that not using a Name is consistent with other parts of the ast, such as `import ... as identifier`, `except ... as identifier` and others. For mypy having a Name node there would slightly simplify the code (I'm currently inserting a dummy NameExpr at AST-Conversion. +0 from me. -- ___ Python tracker <https://bugs.python.org/issue43994> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43892] Make match patterns explicit in the AST
Change by Adrian Freund : -- nosy: +freundTech ___ Python tracker <https://bugs.python.org/issue43892> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43761] Documenting dataclass and namedtuple changes for structural pattern matching
Adrian Freund added the comment: I think for namedtuple a short mention in the opening paragraph, where it also mentions the generation of a docstring and __repr__ method should be enough. -- ___ Python tracker <https://bugs.python.org/issue43761> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43761] Documenting dataclass and namedtuple changes for structural pattern matching
Adrian Freund added the comment: I agree that __match_args__ shouldn't have to be added to the documentation of any class that supports it, however dataclass and (maybe to a lesser extend) NamedTuple aren't themselves classes, but aid in creating own classes. Their effects on classes generated by them should be documented. The documentation also mentions other fields/methods generated by dataclass and NamedTyple. -- ___ Python tracker <https://bugs.python.org/issue43761> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43764] Turning off generation of __match_args__ for dataclasses
Adrian Freund added the comment: > I assume the OP wants to have a class that doesn't allow positional patterns. > The right way to spell that is indeed to add > >__match_args__ = () > >to the class, there's no need to add another flag to @dataclass. The same however is also true for all the other stuff generated by @dataclass. You can for example disable generation of the init method using def __init__(self): pass and dataclass still has a parameter to disable it. I agree that a new parameter isn't strictly required to achieve functionality, however I would still argue that it should be added for consistency with the rest of the dataclass api. -- ___ Python tracker <https://bugs.python.org/issue43764> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43761] Documenting dataclass and namedtuple changes for structural pattern matching
Adrian Freund added the comment: Ok. I created https://bugs.python.org/issue43764 for that. -- ___ Python tracker <https://bugs.python.org/issue43761> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43764] Turning off generation of __match_args__ for dataclasses
New submission from Adrian Freund : The dataclass decorator can take multiple parameters to enable or disable the generation of certain methods. PEP 634 Structural Pattern Matching extends dataclasses to also generate a __match_args__ attribute. I think adding a parameter to enable and disable generation of __match_args__ should be to dataclass should also be considered for consistency. Note that setting compare=False on a dataclass.field already excludes that field from __match_args__, but there is no way to disable generation of __match_args__ completely. -- components: Library (Lib) messages: 390429 nosy: brandtbucher, eric.smith, freundTech, gvanrossum priority: normal severity: normal status: open title: Turning off generation of __match_args__ for dataclasses versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43764> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43761] Documenting dataclass and namedtuple changes for structural pattern matching
New submission from Adrian Freund : PEP 634 structural pattern matching adds an auto-generated __match_args__ attribute to classes with the dataclass decorator and to namedtuples. This change is currently not documented in the dataclass and namedtuple documentation, nor is it mentioned in PEP 557 Data Classes. I would suggest adding mentions of this behaviour in those three places. Additionally I think adding a new parameter to switch off generating __match_args__ to dataclass should be considered, as everything else generated by dataclass can be switched off using a parameter. -- assignee: docs@python components: Documentation messages: 390413 nosy: brandtbucher, docs@python, freundTech, gvanrossum priority: normal severity: normal status: open title: Documenting dataclass and namedtuple changes for structural pattern matching versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43761> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)
John Paul Adrian Glaubitz added the comment: I think there is one productive result of this discussion which is this patch by Jessica Clark which gets rid of architecture-specific alignment code: > https://github.com/python/cpython/pull/24624 Unfortunately, it has not seen any positive reviews yet. Getting this merged would remove some maintenance burden from the CPython maintainers. -- ___ Python tracker <https://bugs.python.org/issue43179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43531] Turtle module does not work
Adrian LeDeaux added the comment: OK. -- ___ Python tracker <https://bugs.python.org/issue43531> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43531] Turtle module does not work
Adrian LeDeaux added the comment: That fixed it. -- ___ Python tracker <https://bugs.python.org/issue43531> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43531] Turtle module does not work
Adrian LeDeaux added the comment: Oh, OK. I am not an expert on python so I did not understand the error. Thanks for the help, and I will update you if the problems continue. -- ___ Python tracker <https://bugs.python.org/issue43531> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43531] Turtle module does not work
New submission from Adrian LeDeaux : So when I try to do the command "import turtle" all I get back is: Traceback (most recent call last): File "", line 1, in import turtle File "/Users/Virsatech/Documents/turtle.py", line 2, in t = turtle.Pen() AttributeError: partially initialized module 'turtle' has no attribute 'Pen' (most likely due to a circular import) that error exactly. And I have tried many times. Anyone know how to fix? -- assignee: terry.reedy components: IDLE messages: 388931 nosy: aledeaux, terry.reedy priority: normal severity: normal status: open title: Turtle module does not work type: behavior versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43531> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43489] Can't install, nothing to install
Adrian LeDeaux added the comment: Alright! Thanks for the help! I will try that. -- ___ Python tracker <https://bugs.python.org/issue43489> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43489] Can't install, nothing to install
Adrian LeDeaux added the comment: The main reason I am trying to install this is because I want to use pygame. Is pygame compatible with version 2.7.28? -- ___ Python tracker <https://bugs.python.org/issue43489> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43489] Can't install, nothing to install
Adrian LeDeaux added the comment: First, I am not asking for guesses. I am getting the installers from the www.python.org website, and I am running them with the MacOS installer app. The format is .mpkg -- Added file: https://bugs.python.org/file49874/Screen Shot 2021-03-13 at 8.45.18 PM.png ___ Python tracker <https://bugs.python.org/issue43489> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43490] IDLE freezes at random
Adrian LeDeaux added the comment: My processor is Intel core 2 duo. -- ___ Python tracker <https://bugs.python.org/issue43490> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43490] IDLE freezes at random
Adrian LeDeaux added the comment: Only when using the turtle module does it happen. -- type: -> behavior versions: -Python 3.10 ___ Python tracker <https://bugs.python.org/issue43490> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43490] IDLE freezes at random
New submission from Adrian LeDeaux : My IDLE shell keeps freezing when using the turtle module. I am using MacOS High Sierra 13.10.6. It says it is fine, but I can't get the window open. I have to restart the shell entirely. I can't type or do anything. I have to do the [command]+[Q] shortcut and then open the app again. Any ideas? -- messages: 388643 nosy: aledeaux priority: normal severity: normal status: open title: IDLE freezes at random versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43490> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43489] Can't install, nothing to install
New submission from Adrian LeDeaux : Python 2.7 won't install. I get the error "there is nothing to install" or something to that effect. I am using MacOS High Sierra 10.13.6. I tried both installer downloads. None worked. And I got the same error every time. Anyone have any ideas on what is going on? -- messages: 388642 nosy: aledeaux priority: normal severity: normal status: open title: Can't install, nothing to install ___ Python tracker <https://bugs.python.org/issue43489> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42128] Structural Pattern Matching (PEP 634)
Adrian Freund added the comment: Thanks for the response. Looks like I overlooked the imports, global, nonlocal, ... because I only searched for usages of identifier, but they use lists of identifiers. In that case I agree that it isn't inconsistent. -- ___ Python tracker <https://bugs.python.org/issue42128> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42128] Structural Pattern Matching (PEP 634)
Adrian Freund added the comment:
For the last few days I've been working with pattern matching and it's ast for
a bit, while trying to add support for it to mypy.
During this I noticed an inconsistency in the ast:
ast.MatchAs has an attribute name which is of type identifier (in C) and type
str (in python).
This seams really inconsistent with the rest of the ast, where identifiers are
always wrapped in a ast.Name object. The only other exception to this is
ast.Attribute.
Judging from Grammar/python.gram this seems deliberate:
as_pattern[expr_ty]:
| pattern=or_pattern 'as' target=capture_pattern {
_Py_MatchAs(pattern, target->v.Name.id, EXTRA) }
Could someone shed some light on why MatchAs directly references an identifier
instead of an ast.Name?
--
nosy: +freundTech
___
Python tracker
<https://bugs.python.org/issue42128>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43374] Apple refuses apps written in Python
Adrian added the comment: Terry, After opening issues on this and other mailing lists (PyObjc) Apple validated our app without a comment. Adrian > On 5 Mar 2021, at 21:51, Terry J. Reedy wrote: > > > Terry J. Reedy added the comment: > > Adrian, when responding by email, please delete the copy of the email you are > responding to, except maybe a line or two, as it is redundant when posted on > the web page. -- ___ Python tracker <https://bugs.python.org/issue43374> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43374] Apple refuses apps written in Python
New submission from Adrian : My company maintains several Python related projects, one of them being an application published for many years in the Mac App Store. During the submittion of the last update for the app, we were refused by Apple to publish the software with the following reason: Guideline 2.5.1 - Performance Your app links against the following non-public framework(s): • Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_wadd_wchnstr • Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_wins_wch • Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_win_wch • Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_win_wchnstr • Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_win_wchnstr • Contents/Frameworks/libpython3.9.dylib/___sprintf_chk • Contents/Frameworks/libpython3.9.dylib/_posix_spawn • Contents/Frameworks/libpython3.9.dylib/_posix_spawn_file_actions_addclose • Contents/Frameworks/libpython3.9.dylib/_posix_spawn_file_actions_adddup2 • Contents/Frameworks/libpython3.9.dylib/_posix_spawn_file_actions_addopen • Contents/Frameworks/libpython3.9.dylib/_posix_spawn_file_actions_destroy • Contents/Frameworks/libpython3.9.dylib/_posix_spawn_file_actions_init • Contents/Frameworks/libpython3.9.dylib/_posix_spawnattr_destroy • Contents/Frameworks/libpython3.9.dylib/_posix_spawnattr_init • Contents/Frameworks/libpython3.9.dylib/_posix_spawnattr_setflags • Contents/Frameworks/libpython3.9.dylib/_posix_spawnattr_setpgroup • Contents/Frameworks/libpython3.9.dylib/_posix_spawnattr_setsigdefault • Contents/Frameworks/libpython3.9.dylib/_posix_spawnattr_setsigmask • Contents/Frameworks/libpython3.9.dylib/_posix_spawnp • Contents/Frameworks/libcrypto.1.1.dylib/___sprintf_chk • Contents/Frameworks/libp11-kit.0.dylib/___sprintf_chk • Contents/Frameworks/Python.framework/Versions/3.9/lib/libpanelw.5.dylib/_SP • Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_SP • Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/___sprintf_chk • Contents/Frameworks/libmpfr.6.dylib/___sprintf_chk • Contents/Frameworks/libgnutls.30.dylib/___sprintf_chk • Contents/Frameworks/libgnutls.30.dylib/_p11_kit_space_strdup • Contents/Frameworks/libgnutls.30.dylib/_p11_kit_space_strlen • Contents/Frameworks/libidn2.0.dylib/_sprintf • Contents/Frameworks/libx264.157.dylib/___sprintf_chk • Contents/Frameworks/Python.framework/Versions/3.9/lib/libcrypto.1.1.dylib/___sprintf_chk • Contents/Frameworks/libssl.1.1.dylib/___sprintf_chk • Contents/Frameworks/libxml2.2.dylib/___sprintf_chk • Contents/Frameworks/Python.framework/Versions/3.9/Python/___sprintf_chk • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn_file_actions_addclose • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn_file_actions_adddup2 • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn_file_actions_addopen • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn_file_actions_destroy • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn_file_actions_init • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_destroy • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_init • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_setflags • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_setpgroup • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_setsigdefault • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_setsigmask • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnp • Contents/Frameworks/Python.framework/Versions/3.9/lib/libssl.1.1.dylib/___sprintf_chk • Contents/Frameworks/libhogweed.6.dylib/_nettle_buffer_space • Contents/Frameworks/libicui18n.67.dylib/_sprintf • Contents/Frameworks/Python.framework/Versions/3.9/lib/libmenuw.5.dylib/_SP • Contents/Frameworks/libavfilter.7.dylib/_avformat_match_stream_specifier • Contents/Frameworks/libmpc.3.dylib/___sprintf_chk • Contents/Frameworks/libunistring.2.dylib/___sprintf_chk • Contents/Frameworks/libunistring.2.dylib/_sprintf • Contents/Frameworks/Python.framework/Versions/3.9/lib/libpanelw.5.dylib/__nc_panelhook • Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/__nc_wcrtomb Next Steps The use of non-public APIs is not permitted on the App Store as it can lead to a poor user experience should these APIs change. -- components: C API, Interpreter Core, macOS messages: 387947 nosy: adigeo, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: Apple refuses apps written in Python type: security versions: Python 3.9 ___ Python tracker
[issue43374] Apple refuses apps written in Python
Adrian added the comment: Hi Ned, Yes, I have submitted Python apps to Mac App Store since 2009, for 12 years. Each new push opens a new pandoras box with different questions asked than previously. There is no learning curve, is just walls with more walls behind each submission. The official reasoning behind all these controls is more security for end-users at the cost of less and less freedom for developers. The app is a the result of the collaboration effort of many people and years of IETF works related to standards based real-time communications. Two years ago we almost dropped the app because of almost impossible to solve issues raised by Apple. In the last year we spent many efforts to see if and how we can still comply with the more and more authoritarian demands of Apple to keep these works alive. I resigned myself to the thought that at some point we will hit a unsolvable issue, I just hope is not this one and now. Adrian > On 2 Mar 2021, at 18:36, Ned Deily wrote: > > > Ned Deily added the comment: > >> What am I suppose to do? > > I appreciate that it's a nasty problem. Unfortunately, this is unknown > territory for me: I have no experience with the Mac App Store and this is the > first time I've run across a report like this. So the question again is: what > has changed? Were you able to successfully submit Python apps before? If so, > exactly what version worked and what version is failing now/ There are some > differences in how we have and are now building the Mac binaries for the > python.org installers. But I'm working blind here. Perhaps some other > people have experience with this. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue43374> > ___ > -- ___ Python tracker <https://bugs.python.org/issue43374> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43374] Apple refuses apps written in Python
Adrian added the comment: Hi Ned, I have a ticket opened with Apple. They refuse the software as it, they are in a position of absolute power, to reject and drop many years of work on a dime. What am I suppose to do? I can fix my own software, but then there are dependencies like Python itself. Hence my question on this forum. I don’t expect miracles or people doing works for free for me to solve my problem. I think I am not the only one confronted with this problem, Python has a pretty large installed base. I am looking for practical suggestions. Regards, Adrian > On 2 Mar 2021, at 18:20, Ned Deily wrote: > > > Ned Deily added the comment: > > BTW, if you haven't already, I would strongly suggest you ask on one of the > Apple Developer Forums. My first guess is that the App Store validation > process is trying to incorrectly apply rules to your local Python framework > (from the Python.org installed framework). But that's just a guess at this > point. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue43374> > ___ > -- ___ Python tracker <https://bugs.python.org/issue43374> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43374] Apple refuses apps written in Python
Adrian added the comment: My apologies, you may disregard any libraries not downloaded from python.org <http://python.org/> I am strictly speaking about the following items related to this mailing list: • Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_wadd_wchnstr • Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_wins_wch • Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_win_wch • Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_win_wchnstr • Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_win_wchnstr • Contents/Frameworks/Python.framework/Versions/3.9/lib/libpanelw.5.dylib/_SP • Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_SP • Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/___sprintf_chk • Contents/Frameworks/Python.framework/Versions/3.9/lib/libcrypto.1.1.dylib/___sprintf_chk • Contents/Frameworks/Python.framework/Versions/3.9/Python/___sprintf_chk • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn_file_actions_addclose • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn_file_actions_adddup2 • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn_file_actions_addopen • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn_file_actions_destroy • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn_file_actions_init • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_destroy • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_init • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_setflags • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_setpgroup • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_setsigdefault • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_setsigmask • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnp • Contents/Frameworks/Python.framework/Versions/3.9/lib/libssl.1.1.dylib/___sprintf_chk • Contents/Frameworks/Python.framework/Versions/3.9/lib/libmenuw.5.dylib/_SP • Contents/Frameworks/Python.framework/Versions/3.9/lib/libpanelw.5.dylib/__nc_panelhook • Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/__nc_wcrtomb All of them are part of Python 3.9 for Mac downloaded from: https://www.python.org/downloads/ <https://www.python.org/downloads/> -- Adrian > On 2 Mar 2021, at 16:54, Ned Deily wrote: > > > Ned Deily added the comment: > >> From where are you getting the Python that you are using in the app? A >> number of those libraries are not part of the python.org Mac binaries. And >> are you compiling with c++ by any chance? > > -- > > ___ > Python tracker > <https://bugs.python.org/issue43374> > ___ > -- ___ Python tracker <https://bugs.python.org/issue43374> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43374] Apple refuses apps written in Python
Adrian added the comment: My apologies, you may disregard any libraries not downloaded from python.org <http://python.org/> I am strictly speaking about the following items related to this mailing list: • Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_wadd_wchnstr • Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_wins_wch • Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_win_wch • Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_win_wchnstr • Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_win_wchnstr • Contents/Frameworks/Python.framework/Versions/3.9/lib/libpanelw.5.dylib/_SP • Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/_SP • Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/___sprintf_chk • Contents/Frameworks/Python.framework/Versions/3.9/lib/libcrypto.1.1.dylib/___sprintf_chk • Contents/Frameworks/Python.framework/Versions/3.9/Python/___sprintf_chk • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn_file_actions_addclose • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn_file_actions_adddup2 • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn_file_actions_addopen • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn_file_actions_destroy • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawn_file_actions_init • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_destroy • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_init • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_setflags • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_setpgroup • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_setsigdefault • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnattr_setsigmask • Contents/Frameworks/Python.framework/Versions/3.9/Python/_posix_spawnp • Contents/Frameworks/Python.framework/Versions/3.9/lib/libssl.1.1.dylib/___sprintf_chk • Contents/Frameworks/Python.framework/Versions/3.9/lib/libmenuw.5.dylib/_SP • Contents/Frameworks/Python.framework/Versions/3.9/lib/libpanelw.5.dylib/__nc_panelhook • Contents/Frameworks/Python.framework/Versions/3.9/lib/libformw.5.dylib/__nc_wcrtomb All of them are part of Python 3.9 for Mac downloaded from: https://www.python.org/downloads/ <https://www.python.org/downloads/> -- Adrian > On 2 Mar 2021, at 16:54, Ned Deily <mailto:rep...@bugs.python.org>> wrote: > > > Ned Deily mailto:n...@python.org>> added the comment: > >> From where are you getting the Python that you are using in the app? A >> number of those libraries are not part of the python.org >> <http://python.org/> Mac binaries. And are you compiling with c++ by any >> chance? > > -- > > ___ > Python tracker mailto:rep...@bugs.python.org>> > <https://bugs.python.org/issue43374 <https://bugs.python.org/issue43374>> > ___ > -- ___ Python tracker <https://bugs.python.org/issue43374> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)
John Paul Adrian Glaubitz added the comment: Oh, and LLVM is currently gaining support M68k which you consider "legacy": > https://reviews.llvm.org/D95315 It might be a good idea to do some research first before making such statements. -- ___ Python tracker <https://bugs.python.org/issue43179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)
John Paul Adrian Glaubitz added the comment: > "Move support of legacy platforms/architectures outside Python" > https://mail.python.org/archives/list/python-...@python.org/thread/F5BXISYP7RAINXUMYJSEYG7GCFRFAENF/ Motorola 68k isn't a 16-bit architecture, it's a 32-bit architecture. Also, I am starting to get the feeling that you are trying to escalate a conflict here. None of the code that you are complaining about is hurting anyone. Yet, you think it is important to keep this discussion and ruining my day. The fact that you take sides for OpenBSD but consider m68k legacy and unmaintained (which isn't correct at all - look at the kernel), shows that you are biased in this discussion. -- ___ Python tracker <https://bugs.python.org/issue43179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)
John Paul Adrian Glaubitz added the comment: > But I don't see the benefit of annoying and discouraging users who want to > experiment with Python and with Linux on Z in 31 bit mode. Fully agree. > Yes, maintenance theoretically is a burden, but there have been no recent > issues that were specific to Linux on Z in 31 bit mode. As I have mentioned before, the Python interpreter in general has been very very unproblematic on any platform. The only real issue that I am aware of is that the testsuite can get stuck on machines with a large number of CPUs (we're seeing that on our SPARC T5 in Debian). > In fact, most of the original Linux on Z support issues that I opened were > endianness issues, which aren't ameliorated by removing 31 bit support. And there is still MIPS-BE, PPC-BE, M68k, HPPA among other which are all big-endian. > As others have expressed, deprecating 31 bit mode only removes the > configuration option with no other code simplification. Exactly my point. If it removed a considerable amount of code, I would actually see a point. But just removing a few lines of autoconf or preprocessor code makes no differences from a maintainer's point of view. > It seems that it would be better to leave the configuration alone until there > actually was an unresolved issue that motivated removal. Jepp, fully agree. > But I am not aware of any client requirement to continue the support. Sure. But free software shouldn't be solely about commercial customers. If someone wants to play with Python on the s390 emulator Hercules, for example, upstream projects shouldn't be keeping them from doing that. > Leaving the 31 bit configuration unchanged is more about maintaining good > will among the volunteers who are interested in the platform. Absolutely. And about not limiting choices when there is no technical argument for it. -- ___ Python tracker <https://bugs.python.org/issue43179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)
John Paul Adrian Glaubitz added the comment: > To get a platform supported by Python, we also need a volunteer to fix issues > specific to the 31 bit s390 platform: see PEP 11. You do not need to support every platform. Just allow your users to use them. If something breaks downstream on a certain platform, distribution maintainers are usually happy to send patches to fix these issues. I think I can speak for myself here and many of my colleagues at SUSE, my fellow Debian Developers and the guys over at Gentoo who have also lots of talented folk who keep sending fixes for many upstream projects. My colleague Andreas, for example, has contributed multiple fixes in cpython on m68k: > https://github.com/python/cpython/search?q=Andreas+Schwab&type=commits -- ___ Python tracker <https://bugs.python.org/issue43179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)
John Paul Adrian Glaubitz added the comment: > What is the use case or benefit of building Python for 32-bit rather than > 64-bit? That's not really the question. The question is whether an upstream project should prevent downstreams from using unsupported target configurations and I think the answer to that question is no. Python is free software (as opposed to just open source software) and one of the key features of free software is that you don't tell your users how they use your software. Open source licenses that limit use cases of software are considered non-free by most if not all Linux distributions for that very reason. There are valid reasons for preventing your software from being built on certain targets - such as the maintenance burden for architecture-specific code - but none of them apply here. A few lines of autoconf plus some preprocessor macros don't pose any burden and therefore the choice should be in favor of allowing downstreams to build unsupported configurations. As for providing a CI: Setting up a CI machine for individual upstream projects is not a problem for big corporations like IBM or Intel, but it is certainly a hassle for individual open source developers and hobbyists. And while we (Debian Ports) have provided some CI machines for individual upstream projects such as GCC and LLVM, it should be sufficient for most upstream projects to rely on Debian's buildd infrastructure as we simply don't have the resources that big corporations have. As for your original question: We still maintain multiple 32-bit ports in Debian, both as official and unofficial releases, and the same is done in other Linux distributions such as Gentoo, openSUSE, Void and others. Lots of hobbyists are pouring a lot of lifeblood and efforts into these ports such as m68k - which has still a surprisingly large user base thanks to retro-computing fans - which is why I am kindly asking you to not put up any obstacles into our ways. As I said before, the Python interpreter is one of these excellent works of engineering that just work. Other interpreters/compilers such as OpenJDK, Ruby, Go or Rust require much more attention to keep them portable while the Python interpreter has never caused any issues which is something I am very grateful for, in particular given the fact how much other code directly depends on the Python interpreter to work (just think of the many package managers and other system tools written in Python). So I think I can speak for Debian, Gentoo and many other downstream projects that it is important for many that it stays that way. Of course, that shouldn't Python development keep from moving forward and if the dependence on architecture-dependent code should increase at some point, we can still discuss this issue again and we will be more than happy to help with the porting efforts. Thank You! -- ___ Python tracker <https://bugs.python.org/issue43179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43179] Remove 31/32-bit s390 Linux support (s390-linux-gnu triplet)
John Paul Adrian Glaubitz added the comment: > Are you sure about that? It seems SLE-12 support s390x not s390. Maybe it's > multilib support in a similar manner that I've mentioned about RHEL7? I work at SUSE. I looked at the internal build system. Debian also still build s390 multilib libraries, i.e. on zelenka.debian.org, I can still install "libc6-s390". And I still don't understand why you are so keen at keeping people from building Python 3.10 on a certain architecture. You don't gain anything by removing these few lines of codes. But you risk at making someone unhappy who - for whatever reason - builds a 31/32 bit Python 3.10 on an s390x system. -- ___ Python tracker <https://bugs.python.org/issue43179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43179] Remove 32-bit s390 Linux support (s390-linux-gnu triplet)
John Paul Adrian Glaubitz added the comment: > This thread is an excellent example why ignoring platforms comes at a cost. > It will only get worse when are going to introduce platform and architecture > specific code for optimizations and features. Which is purely hypothetical at the moment. You are arguing with something that might happen in the future but currently doesn't exist to justify the removal of 5 lines of preprocessor and autoconf "code". You can still drop these lines in the future _if_ they happen to cause any headache. But that is currently not the case, so there isn't really a burden. >> You can view test results any time by going to https://buildd.debian.org/ >> and searching for "pythonX.Y". So there is actually a CI for release builds. > The site does not list a s390 builder. There is only a s390x builder. s390 is being built for SLE-12, for example, on the internal SUSE build system and SLE-12 is still supported. So if a customer wants to use Python 3.10 in a SLE-12 s390 environment, why keep them from doing so? In my experience some upstream projects make the mistake that they think they always know how users are using their software. But since there is no dedicated feedback channel, you have no means in knowing whether someone is building Python for a given architecture for their custom project. After all, there are source-only distributions like Gentoo, so you don't have to rely on any existing binary builds. -- ___ Python tracker <https://bugs.python.org/issue43179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43179] Remove 32-bit s390 Linux support (s390-linux-gnu triplet)
John Paul Adrian Glaubitz added the comment: > So IMO it's fine to remove the support. You are not removing "support". You're just disallowing users to use the Python interpreter - which works perfectly fine on all architectures we have in current and previous releases - on Debian. A few preprocessor macros plus some lines in a configure.ac aren't something that would qualify as platform support. There is no architecture-specific code and the Python interpreter is highly portable and just works whereever we build it in Debian (and openSUSE). I would unterstand the reasoning of such a change if there was a swath of users filing bug reports about s390 and you just don't want to deal with that any longer. But that's not the case as far as I can see. -- ___ Python tracker <https://bugs.python.org/issue43179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43179] Remove 32-bit s390 Linux support (s390-linux-gnu triplet)
John Paul Adrian Glaubitz added the comment: > The guidelines for platform support are explained in PEP 11 > (https://www.python.org/dev/peps/pep-0011/#supporting-platforms). We don't > support platforms unless we have maintainers and CI (builtbots) in place for > the platform. You don't need to support a platform. Just call it unsupported and ignore issues if people report them unless they provide a patch themselves. FWIW, the Python interpreter has never caused any issues on any platform that we support in Debian. We are regularly building the latest upstream versions of all available Python interpreters thanks to the packaging work of Matthias Klose. You can view test results any time by going to https://buildd.debian.org/ and searching for "pythonX.Y". So there is actually a CI for release builds. -- ___ Python tracker <https://bugs.python.org/issue43179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43179] Remove 32-bit s390 Linux support (s390-linux-gnu triplet)
John Paul Adrian Glaubitz added the comment: > Moving forward, s390 will be unambiguously unsupported as we cannot test > against this platform. Unless we get a buildbot provided for this purpose, > as well as somebody willing to fix broken builds on that buildbot long-term, > it is what it is. There is no s390-specifc code in Python in the first place, is there? -- ___ Python tracker <https://bugs.python.org/issue43179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43179] Remove 32-bit s390 Linux support (s390-linux-gnu triplet)
John Paul Adrian Glaubitz added the comment: > I want to make it obvious that the platform has been dropped half a decade > ago. That's a political statement, not a technical one. The change has zero functional impact on the other targets. It just makes the use of Python in a potential s390 VM harder. s390 packages are still being built for SUSE Linux Enterprise 12 which is still actively supported. I assume the same applies to RHEL LTS releases but I can't verify that as I have no insight into RedHat's internal build system. -- ___ Python tracker <https://bugs.python.org/issue43179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43179] Remove 32-bit s390 Linux support (s390-linux-gnu triplet)
John Paul Adrian Glaubitz added the comment: s390 is a 31-bit platform, not a 32-bit platform. I also don't see what this change achieves other than making the use of Python 3.10 on s390 harder. It's not like the removal of support for non-threaded builds which actually saved quite some code: > https://github.com/python/cpython/commit/a6a4dc816d68df04a7d592e0b6af8c7ecc4d4344 -- ___ Python tracker <https://bugs.python.org/issue43179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43179] Remove s390 support
John Paul Adrian Glaubitz added the comment: > I opened this ticket after a user told me that they grepped the source code > of Python, found the string "s390", and concluded that s390 is still > supported by us. Because one user was surprised by a few lines in configure.ac, the conclusion is to remove support for that architecture? That's a very odd justification. If it really just affects configure.ac, I don't really see a point in removing them. Even in OpenJDK we keep such unofficial architectures in configure.ac (with my OpenJDK upstream maintainer hat on). -- ___ Python tracker <https://bugs.python.org/issue43179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43179] Remove s390 support
John Paul Adrian Glaubitz added the comment: That's an argument I have personally never heard before and I have been dealing with a lot of architecture support in many packages. FWIW, lots of upstream projects have targets which are officially supported and others which are there but not supported and that was never really a problem. As long as the architectures are being maintained in the Linux kernel, GCC, binutils and glibc, they can be considered usable and maintained. The m68k architecture for example has a very active and large community due to the popularity of retro computing. This has lead to efforts which will soon bring Rust support to M68k and the Amiga. I therefore don't really understand what you gain when you make it harder for downstreams to use Python. -- ___ Python tracker <https://bugs.python.org/issue43179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43179] Remove s390 support
John Paul Adrian Glaubitz added the comment: And, FWIW, I generally don't quite understand what the problem with old triplet definitions in configure.ac are. I assume they don't hurt anyone, do they? You never know what usecases your users have and as long as a code snippet doesn't interfere with other code, I don't see little point in removing it. -- ___ Python tracker <https://bugs.python.org/issue43179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43179] Remove s390 support
John Paul Adrian Glaubitz added the comment: I'm a Debian Developer and maintainer for multiple Debian Ports architectures. Please don't remove support for Alpha, HPPA, m68k, ia64, PowerPC, SuperH, SPARC as we're still maintaining these in Debian. Here are the latest build results for Python3.9 in Debian with build logs for all these architectures: > https://buildd.debian.org/status/package.php?p=python3.9&suite=sid There are no issues reported and we heavily rely on Python. -- nosy: +glaubitz ___ Python tracker <https://bugs.python.org/issue43179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43127] Unable to install Python 3.9.1 - Windows 10
New submission from Adrian Lloyd : I get the following error when I try to install Python 3.9.1 on windows 10 0x80070659 The installation is forbidden by system policy. The log gives more information: [13A0:0FC0][2021-02-04T16:41:04]e000: Error 0x80070659: Failed to install MSI package. [13A0:0FC0][2021-02-04T16:41:04]e000: Error 0x80070659: Failed to configure per-user MSI package. [13A0:0FC0][2021-02-04T16:41:04]i319: Applied execute package: core_JustForMe, result: 0x80070659, restart: None [13A0:0FC0][2021-02-04T16:41:04]e000: Error 0x80070659: Failed to execute MSI package. I have looked on earlier posts and stack overflow and all suggest a registry fix to set DisableMSI = 0 in the registry, but according to windows documentation this doesn't apply to windows 10. Also the Installer folder which would contain this parameter doesn't exist. Can you help? -- messages: 386485 nosy: adrian.e.d.lloyd priority: normal severity: normal status: open title: Unable to install Python 3.9.1 - Windows 10 versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue43127> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42405] Add distutils mvsccompiler support for Windows ARM64 build
Adrian Vladu added the comment: Thank you for the suggestion, I will update the PR accordingly to change the __msvccompiler.py. I just need to find a good candidate that uses that implementation to check if the compilation gets fixed. -- ___ Python tracker <https://bugs.python.org/issue42405> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42405] Add distutils mvsccompiler support for Windows ARM64 build
Adrian Vladu added the comment: This fix is __required__ to build a lot of important packages in the python ecosystem, like numpy, pandas, pywin32 and probably a lot more, as most of these important packages have not migrated to setuptools and usually maintain support for multiple python versions. I know that there is a way to change all the packages to use the canonical approach to compile things, but most of them have a tweaked compiler on top of the msvc9compiler.py compiler. I do not see a change in all the python packages to happen as fast as a small backwards compatible commit in the main cpython code. I see this commit as a fix for the win-arm64 package build and not an "extra" feature. As I can see it, not adding this fix here will require a split of trees that are going to be used just for this reason. I will add the fix to setuptools too, but that will not change the above (maintaining separate branches for people who want to use those packages). -- ___ Python tracker <https://bugs.python.org/issue42405> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42405] Add distutils mvsccompiler support for Windows ARM64 build
Change by Adrian Vladu : -- keywords: +patch pull_requests: +22291 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23399 ___ Python tracker <https://bugs.python.org/issue42405> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42405] Add distutils mvsccompiler support for Windows ARM64 build
New submission from Adrian Vladu : To add support for building packages that have C extensions on Windows ARM64, some fixes are required in the integrated distutils wrapper for Visual Studio compiler (Lib/distutils/msvc9compiler.py) This is a hardcoded fix that needs to be improved so that it applies only on windows arm64: https://github.com/ader1990/cpython/commit/b8c59c9b96a7ad11094224b5631aae3b89323f7a Any suggestions are welcome. -- components: Windows messages: 381407 nosy: avladu, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Add distutils mvsccompiler support for Windows ARM64 build type: compile error versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42405> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39875] urllib.request.urlopen sends POST data as query string
Adrian Petrescu added the comment: (Oops, that was a bad paste! I meant this link: https://docs.python.org/2/library/urllib.html#urllib.urlopen) -- ___ Python tracker <https://bugs.python.org/issue39875> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39875] urllib.request.urlopen sends POST data as query string
Adrian Petrescu added the comment: This is not a bug, you've just misunderstood the urllib API. If you want to pass POST data as a payload, it's the second `data` parameter to `urlopen`: https://bugs.python.org/?@action=confrego&otk=KX9AqsI0JnOLkplIY1AGKXAmDKa38COy -- nosy: +apetresc ___ Python tracker <https://bugs.python.org/issue39875> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35448] ConfigParser .read() - handling of nonexistent files
Adrian Wielgosik added the comment: Yeah, I lost steam on this issue, sorry. Go ahead :) -- ___ Python tracker <https://bugs.python.org/issue35448> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35448] ConfigParser .read() - handling of nonexistent files
New submission from Adrian Wielgosik :
Documentation of ConfigParser says:
> If a file named in filenames cannot be opened, that file will be ignored.
> This is designed so that you can specify an iterable of potential
> configuration file locations (for example, the current directory, the user’s
> home directory, and some system-wide directory), and all existing
> configuration files in the iterable will be read.
While this is a useful property, it can also be a footgun. The first read()
example in the Quick Start section contains just a single file read:
>>> config.read('example.ini')
I would expect that this basic usage is very popular. If the file doesn't
exist, the normal usage pattern fails in a confusing way:
from configparser import ConfigParser
config = ConfigParser()
config.read('config.txt')
value = config.getint('section', 'option')
---> configparser.NoSectionError: No section: 'section'
In my opinion, this error isn't very obvious to understand and debug, unless
you have read that piece of .read() documentation.
This behavior did also bite me even more, with another usage pattern I've found
in a project I maintain:
> config.read('global.txt')
> config.read('local.txt')
Here, both files are expected to exist, with the latter one extending or
updating configuration from the first file. If one of the files doesn't exist
(eg mistake during deployment), there's no obvious error, but the program will
be configured in different way than intended.
Now, I'm aware that all of this can be avoided by simply using `read_file()`:
> with open('file.txt') as f:
>config.read_file(f)
But again, `.read()` is the one usually mentioned first in both the official
documentation, and most independent guides, so it's easy to get wrong.
Due to this, I propose adding an extra parameter to .read():
read(filenames, encoding=None, check_exist=False)
that, when manually set to True, will throw exception if any of input files
doesn't exist; and to use this parameter by default in Quick Start section of
ConfigParser documentation.
If this is a reasonable idea, I could try and make a PR.
For comparison, the `toml` Python library has the following behavior:
- if argument is a single filename and file doesn't exist, it throws
- if argument is a list of filenames and none exist, it throws
- if argument is a list of filenames and at least one exists, it works, but
prints a warning for each nonexistent file.
For the record, seems like this issue was also mentioned in
https://bugs.python.org/issue490399
--
components: Library (Lib)
messages: 331439
nosy: Adrian Wielgosik
priority: normal
severity: normal
status: open
title: ConfigParser .read() - handling of nonexistent files
type: behavior
___
Python tracker
<https://bugs.python.org/issue35448>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34918] Python 3 tkinter measurement problem
New submission from Adrian Keister : tkinter.Tk().winfo_screenmmwidth() and tkinter.Tk().winfo_screenmmheight() give manifestly incorrect values in Windows. This does not appear to be an issue in Linux. I have not tested a Mac. The values reported in Windows are too large by as much as 58%. Searching online seems to indicate that the issue is some applications in Windows are "dpi aware"; unfortunately, none of the so-called work-arounds I've found actually fix the problem. The tkinter.Tk().winfo_screenwidth() and tkinter.Tk().winfo_screenheight() functions, reporting their results in pixels, appear to be correct. A MWE is simply import tkinter tkinter.Tk().winfo_screenmmwidth() This reports a 508 mm on my 15.6" screen, when the true value is closer to 343 mm. This is a 48% error, and hence an unusable result. Thank you for your time! -- components: Tkinter messages: 327265 nosy: Ackbach priority: normal severity: normal status: open title: Python 3 tkinter measurement problem type: behavior versions: Python 3.6 ___ Python tracker <https://bugs.python.org/issue34918> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34334] QueueHandler logs exc_info twice
New submission from Adrian Dries :
Since Python 3.7 logging.handlers.QueueHandler logs tracebacks twice::
>>> import logging
>>> from logging.handlers import QueueHandler, QueueListener
>>> from queue import Queue
>>> q = Queue()
>>> logging.getLogger().addHandler(QueueHandler(q))
>>> listener = QueueListener(q, logging.StreamHandler())
>>> listener.start()
>>> try: 1/0
... except: logging.exception('Look out!')
...
Look out!
Traceback (most recent call last):
File "", line 1, in
ZeroDivisionError: division by zero
Traceback (most recent call last):
File "", line 1, in
ZeroDivisionError: division by zero
Patching QueueHandler.prepare() to set exc_text to None seems to fix this.
--
components: Library (Lib)
messages: 323100
nosy: avdd
priority: normal
severity: normal
status: open
title: QueueHandler logs exc_info twice
type: behavior
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue34334>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33094] dataclasses: ClassVar attributes are not working properly
Adrian Stachlewski added the comment: There's nothing to do, thanks for help one more again. -- status: pending -> open ___ Python tracker <https://bugs.python.org/issue33094> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33100] dataclasses and __slots__ - non-default argument (member_descriptor)
Adrian Stachlewski added the comment:
There's also another major problem. Because Base.x has value, __init__ is not
prepared correctly (member_descriptor is passed as default).
@dataclass
class Base:
__slots__ = ('x',)
x: Any
Base() # No TypeError exception
Fixing this should be quite easy, if you want I can prepare PR.
--
___
Python tracker
<https://bugs.python.org/issue33100>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33100] dataclasses and __slots__ - non-default argument (member_descriptor)
Adrian Stachlewski added the comment:
I don't really get your point.
@dataclass
class Base:
__slots__ = ('x',)
x: Any
This case is described in PEP 557 as correct, so I don't understand why you
want to generate error. Also inheritance without defining slots is correct as
stated in data model.
In my opinion, member_descriptor should be treated same as MISSING and
everything should work correctly.
--
___
Python tracker
<https://bugs.python.org/issue33100>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33094] dataclasses: ClassVar attributes are not working properly
Adrian Stachlewski added the comment: Once more same mistake. 'x' should be declared as: - x: ClassVar[set] = set() - x: ClassVar[Set[Any]] = set() -- ___ Python tracker <https://bugs.python.org/issue33094> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33100] dataclasses and __slots__ - non-default argument (member_descriptor)
New submission from Adrian Stachlewski :
I've tried to declare two classes
@dataclass
class Base:
__slots__ = ('x',)
x: Any
@dataclass
class Derived(Base):
x: int
y: int
As long as I correctly understood PEP 557 (inheritance part), changing type of
variable is possible. This code produce error:
TypeError: non-default argument 'y' follows default argument
'x' variable in Derived class has changed default from MISSING to
member_descriptor and that's the reason of the exception.
--
components: Library (Lib)
messages: 314077
nosy: stachel
priority: normal
severity: normal
status: open
title: dataclasses and __slots__ - non-default argument (member_descriptor)
type: behavior
versions: Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue33100>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33094] dataclasses: ClassVar attributes are not working properly
Adrian Stachlewski added the comment: Thanks for explaining. I was trying to do something like @dataclass class A: x: ClassVar = set() and thanks to you I know it should be @dataclass class A: x: ClassVar[Set] = set() If you are looking for improved error message, it's probably should be somehow connected to not proper usage of annotation. I've ended with default_factory because x: ClassVar = set() wasn't working and there was no error with default_factory and without slots. -- ___ Python tracker <https://bugs.python.org/issue33094> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33094] dataclasses: ClassVar attributes are not working properly
New submission from Adrian Stachlewski : Class variables should behave in the same way whether with or without ClassVar annotation. Unfortunately there are not. class A: __slots__ = () x: ClassVar = set() A() # it's ok @dataclass class B: __slots__ = () x = set() B() # ok too @dataclass class C: __slots__ = () # cannot use set() because of error x: ClassVar = field(default_factory=set) C() # AttributeError: 'C' object has no attribute 'x' Exception is raised from __init__ method, with flag init=False nothing changes. Python version: 3.7.0b2 -- components: Library (Lib) messages: 314017 nosy: stachel priority: normal severity: normal status: open title: dataclasses: ClassVar attributes are not working properly type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue33094> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31453] Debian Sid/Buster: Cannot enable TLS 1.0/1.1 with PROTOCOL_TLS
Adrian Vollmer added the comment: I have a workaround for now: versions = [ssl.PROTOCOL_TLSv1, ssl.PROTOCOL_TLSv1_1, ssl.PROTOCOL_TLSv1_2, ] firstbytes = s.recv(16, socket.MSG_PEEK) ss = ssl.wrap_socket( s, server_side=True, certfile="server.pem", keyfile="server.pem", # ssl_version=versions[ord(firstbytes[10])-1] # python2 ssl_version=versions[firstbytes[10]-1] ) How much of an ugly hack is this? :) -- versions: -Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue31453> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31453] ssl.PROTOCOL_TLS only select TLSv1.2
Adrian Vollmer added the comment: Okay, thanks for your time! -- ___ Python tracker <https://bugs.python.org/issue31453> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31453] ssl.PROTOCOL_TLS only select TLSv1.2
Adrian Vollmer added the comment: Doesn't seem to do anything: >>> ctx.options 2181170175L >>> ctx.options & ~(ssl.OP_NO_TLSv1 | ssl.OP_NO_TLSv1_1) 2181170175L -- ___ Python tracker <https://bugs.python.org/issue31453> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31453] ssl.PROTOCOL_TLS only select TLSv1.2
Adrian Vollmer added the comment: I read about that, but I don't understand. If I use openssl s_server -port , I can connect using either one of the three protocols. Even if that's the new default, is there no way now to get python on Buster/Sid to use OpenSSL in a non-default mode and have it offer all three versions? -- ___ Python tracker <https://bugs.python.org/issue31453> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31453] ssl.PROTOCOL_TLS only select TLSv1.2
Adrian Vollmer added the comment: Debian buster/sid -- ___ Python tracker <https://bugs.python.org/issue31453> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31453] ssl.PROTOCOL_TLS only select TLSv1.2
New submission from Adrian Vollmer:
According to the documentation
(https://docs.python.org/2/library/ssl.html#ssl.PROTOCOL_TLS), using
ssl_version = ssl.PROTOCOL_TLS in a server socket should offer all TLS/SSL
versions. However, it only offers TLSv1_2.
I attached a proof of concept.
$ python3 poc.py
3.5.4 (default, Aug 12 2017, 14:08:14)
[GCC 7.1.0]
OpenSSL 1.1.0f 25 May 2017
[SSL: UNSUPPORTED_PROTOCOL] unsupported protocol (_ssl.c:719)
[SSL: UNSUPPORTED_PROTOCOL] unsupported protocol (_ssl.c:719)
b'test\n'
$ python2 poc.py
2.7.13 (default, Jan 19 2017, 14:48:08)
[GCC 6.3.0 20170118]
OpenSSL 1.1.0f 25 May 2017
[SSL: UNSUPPORTED_PROTOCOL] unsupported protocol (_ssl.c:661)
[SSL: UNSUPPORTED_PROTOCOL] unsupported protocol (_ssl.c:661)
test
To connect with s_client:
$ for i in {tls1,tls1_1,tls1_2} ; do echo test | openssl s_client -connect
localhost: -CAfile server.pem -quiet -$i ; done
140164347663616:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert
protocol version:../ssl/record/rec_layer_s3.c:1399:SSL alert number 70
139926441944320:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert
protocol version:../ssl/record/rec_layer_s3.c:1399:SSL alert number 70
depth=0 C = AU, ST = Some-State, O = Internet Widgits Pty Ltd
verify return:1
read:errno=0
--
assignee: christian.heimes
components: SSL
files: poc.py
messages: 302081
nosy: adrianv, christian.heimes
priority: normal
severity: normal
status: open
title: ssl.PROTOCOL_TLS only select TLSv1.2
type: behavior
versions: Python 2.7, Python 3.5
Added file: https://bugs.python.org/file47139/poc.py
___
Python tracker
<https://bugs.python.org/issue31453>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24700] array compare is hideously slow
Adrian Wielgosik added the comment:
Added a PR with a fast path that triggers when compared arrays store values of
the same type. In this fast path, no Python objects are created. For big arrays
the runtime reduction can reach 50-100x.
It's possible to optimize the comparison loop a bit more - for example
array('B') comparison could use memcmp and become extra 10x faster, and other
types could receive similar treatment - but I wanted to keep the code
relatively simple.
Code duplication with macros is a bit ugly, but that's the best I could come up
with so far.
Benchmark results:
TestBefore After % of old time
Equal, same stored type (new fast path)
array('i', range(0))20.4ns 22.07ns 108.15%
array('i', range(1))33.39ns 22.32ns 66.86%
array('i', range(10)) 152.0ns 31.21ns 20.54%
array('i', range(1))447.7us 6.571us 1.47%
array('i', range(10)) 4.626ms 67.24us 1.45%
array('i', [1<<30]*10)) 5.234ms 65.8us 1.26%
array('B', range(10)) 151.8ns 28.53ns 18.79%
array('B', range(250)) 3.14us 194.5ns 6.19%
array('B', [1,2,3]*1000)37.76us 2.088us 5.53%
array('d', range(10)) 311.9ns 31.22ns 10.01%
array('d', range(10)) 2.889ms 99.3us 3.44%
Equal, different types (slow path)
array('X', range(0))20.37ns 19.45ns 95.48%
array('X', range(1))34.87ns 34.42ns 98.72%
array('X', range(10)) 169.1ns 169.0ns 99.97%
array('X', range(1))462.2us 444.8us 96.23%
array('X', range(10)) 4.752ms 4.571ms 96.20%
Not equal: first element (X) different
array('i', [X] + [1,2,3]*1) 42.77ns 21.84ns 51.06%
Not equal: last element (X) different
array('i', [1,2,3]*1 + [X]) 375.4us 19.8us 5.27%
--
nosy: +Adrian Wielgosik
___
Python tracker
<http://bugs.python.org/issue24700>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24700] array compare is hideously slow
Changes by Adrian Wielgosik : -- pull_requests: +3042 ___ Python tracker <http://bugs.python.org/issue24700> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30545] Enum equality across modules: comparing objects instead of values
Changes by Adrian Wan : -- nosy: +adrianwan2 status: pending -> open ___ Python tracker <http://bugs.python.org/issue30545> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29586] Cannot run pip in fresh install of py 3.5.3
Adrian Chan added the comment: Ah, I'd forgotten about that. When I first tried to run python I got an error complaining about a missing api-ms-win-crt-runtime-l1-1.0.dll I installed the necessary VC redistributable and it solved that problem. So that's why I could successfully ensurepip later on. I'm surprised the manual runtime installation was necessary. Between windows updates and installers for other programs I should already have it installed. Perhaps it got corrupted? That's out of scope for this issue anyway. -- ___ Python tracker <http://bugs.python.org/issue29586> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29586] Cannot run pip in fresh install of py 3.5.3
Adrian Chan added the comment: Install logs attached. First set from initial install, second set from repair. -- Added file: http://bugs.python.org/file46645/py_install_logs.tar.gz ___ Python tracker <http://bugs.python.org/issue29586> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29586] Cannot run pip in fresh install of py 3.5.3
Adrian Chan added the comment: It's all working fine now, thanks. If one of the installer/windows guys wants to dig more into why this didn't install properly I'm happy to run things in my environment as necessary. -- ___ Python tracker <http://bugs.python.org/issue29586> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29586] Cannot run pip in fresh install of py 3.5.3
Adrian Chan added the comment: Thanks, but I know how to drive a terminal ;) Your hunch was basically correct though. I ran again with `python -v -m pip` (see with_pip_dir.txt), and see that python is attempting to import pip from my user directory (C:\Users\amc2\pip). This is an empty directory, except for an old pip log file from 2.7. If I rename the directory to something unrelated, `python -m pip` just fails with: C:\Python\Python35-32\python.exe: No module named pip. So mystery 1 is solved. I've definitely selected the pip option in the python installer. I also repaired the installation, with the pip option selected, and the error still remains. Where is pip supposed to be located on a win7 install? -- Added file: http://bugs.python.org/file46642/import_logs.tar.gz ___ Python tracker <http://bugs.python.org/issue29586> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29586] Cannot run pip in fresh install of py 3.5.3
Adrian Chan added the comment: There is no traceback, that is the entirety of the output of the command. Python bin is C:\Python\Python35-32\python.exe PYTHONHOME is not set. PYTHONPATH is C:\python27\lib\site-packages\ I don't know why PYTHONPATH was set. I cleared it but it made no difference -- same error. -- ___ Python tracker <http://bugs.python.org/issue29586> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29586] Cannot run pip in fresh install of py 3.5.3
New submission from Adrian Chan: I uninstalled python 2.7 and 3.4, then performed a fresh install of 3.5.3. Running pip with `python -m pip` as per https://docs.python.org/3.5/installing gives the following error: C:\Python\Python35-32\python.exe: No module named pip.__main__; 'pip' is a package and cannot be directly executed Installation details: * win 7 64 bit. * python 3.5.3 32 bit. * chose options for pip, tcl/tk/idle, test suite, py launcher, shortcuts, add to env, precompile std lib. * installed to non-standard directory. -- assignee: docs@python components: Documentation, Installation, Windows messages: 287986 nosy: Adrian Chan, docs@python, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Cannot run pip in fresh install of py 3.5.3 type: behavior versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue29586> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28813] Remove unneeded folded consts after peephole
Adrian Wielgosik added the comment: Attached squashed patch. > But moving constant folding from the peephole optimizer to the AST level > (...) would totally eliminate the need in your patch. I'm aware of that and I'm okay with it. I chose an unfortunate moment for implementing this :) -- Added file: http://bugs.python.org/file45664/clean_co_consts_squashed.patch ___ Python tracker <http://bugs.python.org/issue28813> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28813] Remove unneeded folded consts after peephole
Changes by Adrian Wielgosik : Added file: http://bugs.python.org/file45662/clean_co_consts.patch ___ Python tracker <http://bugs.python.org/issue28813> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28813] Remove unneeded folded consts after peephole
Changes by Adrian Wielgosik : -- keywords: +patch Added file: http://bugs.python.org/file45661/indices_tweak.patch ___ Python tracker <http://bugs.python.org/issue28813> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
