[issue31853] Use super().method instead of socket.method in SSLSocket

Christian Heimes added the comment: I agree Also this ticket was closed a couple of months ago and is about the SSL module. Your PR is about a different module. Although I think that recycling is generally a good idea, it doesn't apply to ticket numbers. --

[issue31853] Use super().method instead of socket.method in SSLSocket

Nathaniel Smith added the comment: The only time this should matter semantically is if someone is trying to subclass SSLSocket and use multiple inheritance. This is something that people *really* shouldn't do. It also potentially makes it harder to backport ssl changes to

Re: please test the new PyPI (now in beta)

On Tue, Mar 27, 2018 at 9:49 PM, Steven D'Aprano wrote: > As an extra bonus, even when searching is not reliant on Javascript, > mangling the text in the search box often is, so unless I'm extra > careful, whenever I want to search for (say) "aardvarks", I

[issue33156] Use super().method instead in email classes.

New submission from Mads Jensen : There are lots of legacy calls in the form of ClassName.method, which should be replaced with super().method. -- components: email messages: 314519 nosy: barry, madsjensen, r.david.murray priority: normal pull_requests: 5997 severity:

[issue31853] Use super().method instead of socket.method in SSLSocket

INADA Naoki added the comment: Why *should*? Legacy ParentClass.method() call is faster than super().method() call, because there are no temporary proxy object. I don't think there are enough reason to replace all legacy parent calls. -- nosy: +inada.naoki

[issue33155] Use super().method instead in Logging

New submission from Mads Jensen : There are lots of legacy calls in the form of ClassName.method, which should be replaced with super().method. This is an issue in many modules; I've been asked to create a report for each module that the PR touches. -- components:

[issue31853] Use super().method instead of socket.method in SSLSocket

Mads Jensen added the comment: There are lots of legacy calls in the form of ClassName.method, which should be replaced with super().method. -- components: +email -SSL nosy: +barry, r.david.murray pull_requests: +5996 ___ Python

[issue33111] Merely importing tkinter breaks parallel code (multiprocessing, sharedmem)

Ronald Oussoren added the comment: @ezwelty: The import of multiprocessing and the call to set_start_method should be at the very start of the code, before other imports, to avoid the annoying Apple behavior I mentioned. --

[issue16482] pdb.set_trace() clobbering traceback on error

daniel hahler added the comment: Just for reference: https://github.com/python/cpython/pull/6233 is about fixing this. -- keywords: +patch nosy: +blueyed pull_requests: +5995 stage: needs patch -> patch review ___ Python

[issue33154] subprocess.Popen ResourceWarning should have activation-deactivation flags

Arno-Can Uestuensoez added the comment: See also issue26741 - subprocess.Popen should emit a ResourceWarning in destructor if ... -- ___ Python tracker

[issue33153] interpreter crash when multiplying large tuples

INADA Naoki added the comment: Would you paste traceback? -- nosy: +inada.naoki ___ Python tracker ___

[issue33154] subprocess.Popen ResourceWarning should have activation-deactivation flags

New submission from Arno-Can Uestuensoez : The subprocess call *subprocess.Popen* in Python3.6 was added a number of resource warnings, including subprocess run-state and open files. This is a very good facility for debugging, but causes a lot of trouble for programs

Re: please test the new PyPI (now in beta)

On Tue, 27 Mar 2018 11:03:00 +0100, Paul Moore wrote: > Digging into this further, the design work on the Warehouse site has > been ongoing since late 2015, and there was an extensive user testing > phase, Oh? What did they test the user for? Whatever it was, it was a pity they didn't test them

Re: To super or not to super (Re: Accessing parent objects)

On 27-03-18 08:21, Gregory Ewing wrote: > The idea that super() is *always* the right way to call > inherited methods in a multiple inheritance environment > seems to have been raised by some people to the level > of religous dogma. > > I don't buy it. In order for it to work, the following > two

Re: please test the new PyPI (now in beta)

For me, that's a window width issue. The sidebar with the filters only shows when the window is wide enough. Unfortunately, the text mentioning it doesn't change, so this should be fixed. On 03/27/2018 12:06 PM, Steven D'Aprano wrote: On Tue, 27 Mar 2018 10:48:15 +0100, Paul Moore wrote:

Re: please test the new PyPI (now in beta)

On 27/03/2018 11:06, Steven D'Aprano wrote: On Tue, 27 Mar 2018 10:48:15 +0100, Paul Moore wrote: By the way, on the search page: https://pypi.org/search/ it says "Enter a search query above, or select a filter from the list of classifiers on the left" but there is no such filter or list of

[issue33153] interpreter crash when multiplying large tuples

New submission from Ivan Zakharyaschev : The issue https://bugs.python.org/msg314475 has arisen for tuples (but not for lists, as in the example there) in 2.7.14 for me. How should we fix it in a better way? This bug is not reproducible in python 3.5.4. [builder@localhost

[issue1704621] interpreter crash when multiplying large lists

Ivan Zakharyaschev added the comment: New issue filed: https://bugs.python.org/issue33153 -- ___ Python tracker ___

[issue33153] interpreter crash when multiplying large tuples

Ivan Zakharyaschev added the comment: I meant the old issue https://bugs.python.org/issue1704621 . -- ___ Python tracker ___

Re: please test the new PyPI (now in beta)

On Tue, 27 Mar 2018 10:48:15 +0100, Paul Moore wrote: >> By the way, on the search page: >> >> https://pypi.org/search/ >> >> >> it says "Enter a search query above, or select a filter from the list >> of classifiers on the left" but there is no such filter or list of >> classifiers. > > Do you

Re: please test the new PyPI (now in beta)

On 27 March 2018 at 10:48, Paul Moore wrote: > Same is true of your comment about the site design, > although I suspect it's a bit late for that to be changed in the > immediate future - the site design has been basically unchanged since > very early in the redesign.

Re: please test the new PyPI (now in beta)

On 27 March 2018 at 09:35, Steven D'Aprano wrote: > On Mon, 26 Mar 2018 18:16:26 -0400, Sumana Harihareswara wrote: > >> The new Python Package Index at https://pypi.org is now in beta. >> >> This means the site is robust, but we anticipate needing more user

[issue33014] Clarify str.isidentifier docstring; fix keyword.iskeyword docstring

Serhiy Storchaka added the comment: I concur with David about the docstring. But I think that no changes are needed in the module documentation. David's wording would contain two links (for iskeyword() and for keyword), and many links distract the attention. We

[issue31550] Inconsistent error message for TypeError with subscripting

Serhiy Storchaka added the comment: If the reason of this change was making the error message more consistent with other error messages in classic classes (at the cost of larger dereference with Python 3), it LGTM. --

[issue33124] Lazy execution of module bytecode

Serhiy Storchaka added the comment: Function definitions usually are cheap, as well as global constants definitions (unless they use complex comprehensions or call heavy functions for initialization). Creating a class is an order or more slower than creating a

Re: Entering a very large number

On Mon, 26 Mar 2018 23:49:07 -0400, Richard Damon wrote: > The bigger issue is that these sort of micro-measurements aren't > actually that good at measuring real quantitative performance costs. > They can often give qualitative indications, but the way modern > computers work, processing

Re: please test the new PyPI (now in beta)

On Mon, 26 Mar 2018 18:16:26 -0400, Sumana Harihareswara wrote: > The new Python Package Index at https://pypi.org is now in beta. > > This means the site is robust, but we anticipate needing more user > testing and changes before it is "production-ready" and can fully > replace

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

On Mon, 26 Mar 2018 11:37:35 -0700, Rick Johnson wrote: > On Monday, March 26, 2018 at 5:46:03 AM UTC-5, Steven D'Aprano wrote: >> Rick, you're supposedly familiar with Ruby. And yet, you didn't notice >> that your supposed "fix" didn't touch any executable code, all it did >> was modify the

[issue33152] clean code

Change by Roundup Robot : -- keywords: +patch pull_requests: +5994 stage: -> patch review ___ Python tracker ___

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

On Mon, Mar 26, 2018, at 2:19 PM, Rick Johnson wrote: >Sure, the behavior that Steven > uncovered is odd, but it could be that Maz harbors a strong > disliking for undisciplined pupils, and thus, he designed > and placed this little trap in the hopes the pain it induced > might encourage the

[issue33152] clean code

New submission from Windson Yang : https://github.com/python/cpython/blob/master/Lib/timeit.py#L202 use a list comprehension instead -- components: Distutils messages: 314504 nosy: Windson Yang, dstufft, eric.araujo priority: normal severity: normal status: open

[issue33146] contextlib.suppress should capture exception for inspection and filter on substrings

Serhiy Storchaka added the comment: I'm not sure that contextlib.suppress() should be added at first place. try: os.remove(somefile) except FileNotFoundError: pass is a tiny bit longer, but is more explicit, doesn't depend on the other

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

On Tue, Mar 27, 2018 at 5:54 PM, Gregory Ewing wrote: > Chris Angelico wrote: >> >> Question: How do you get a reference to a Ruby function? Or are they >> not first-class objects? > > > They're not first-class. So, you can't. > Ahh, that explains it. Great. So how

[issue33150] Signature error for methods of class configparser.Interpolation

Change by Serhiy Storchaka : -- nosy: +lukasz.langa ___ Python tracker ___ ___

[issue33144] random._randbelow optimization

Serhiy Storchaka added the comment: I think this is excellent application of __init_subclass__. It is common to patch an instance method in __init__, but this can create a reference loop if patch it by other instance method. In this case the choice doesn't depend

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

Chris Angelico wrote: Question: How do you get a reference to a Ruby function? Or are they not first-class objects? They're not first-class. So, you can't. -- Greg -- https://mail.python.org/mailman/listinfo/python-list

Re: A question related to the PYTHONPATH

Le mardi 27 mars 2018 07:42:57 UTC+2, dieter a écrit : > oyono writes: > > ... > > I was thinking, maybe it could have been done this way to enforce not > > running module files that are supposed to be bundled into packages as > > "independant" python scripts...Therefore,

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

Ned Batchelder wrote: "Ranting Rick" isn't trying to enlighten, educate, or learn. He's trying to rile people up, and he is good at it. I don't think he's even trying, it just come naturally to him. Rick rants the way wind blows and water wets. -- Greg --

To super or not to super (Re: Accessing parent objects)

The idea that super() is *always* the right way to call inherited methods in a multiple inheritance environment seems to have been raised by some people to the level of religous dogma. I don't buy it. In order for it to work, the following two conditions must hold: 1) All the methods involved

<    1   2