[issue31500] IDLE: Tiny font on HiDPI display

Serhiy Storchaka added the comment: What about 2.7? -- ___ Python tracker ___

[issue32981] Catastrophic backtracking in poplib and difflib

Benjamin Peterson added the comment: New changeset c9516754067d71fd7429a25ccfcb2141fc583523 by Benjamin Peterson in branch '3.6': [3.6] bpo-32981: Fix catastrophic backtracking vulns (GH-5955)

[issue32981] Catastrophic backtracking in poplib and difflib

Benjamin Peterson added the comment: New changeset e052d40cea15f582b50947f7d906b39744dc62a2 by Benjamin Peterson in branch '2.7': [2.7] bpo-32981: Fix catastrophic backtracking vulns (GH-5955)

[issue32980] Remove functions that do nothing in _Py_InitializeCore()

Benjamin Peterson added the comment: New changeset 7023644e0c310a3006c984318c2c111c468735b4 by Benjamin Peterson (Thomas Nyberg) in branch 'master': closes bpo-32980 Remove _PyFrame_Init (GH-5965)

[issue32981] Catastrophic backtracking in poplib and difflib

Benjamin Peterson added the comment: New changeset 0902a2d6b2d1d9dbde36aeaaccf1788ceaa97143 by Benjamin Peterson (Miss Islington (bot)) in branch '3.7': bpo-32981: Fix catastrophic backtracking vulns (GH-5955)

[issue32981] Catastrophic backtracking in poplib and difflib

Change by Benjamin Peterson : -- pull_requests: +5737 ___ Python tracker ___ ___

[issue32981] Catastrophic backtracking in poplib and difflib

Change by Benjamin Peterson : -- pull_requests: +5736 ___ Python tracker ___ ___

[issue31500] IDLE: Tiny font on HiDPI display

Terry J. Reedy added the comment: I assume that the 2nd patch, by Serhiy, fixed the issue. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue32874] IDLE: Add tests for pyparse

Change by Terry J. Reedy : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue32981] Catastrophic backtracking in poplib and difflib

Benjamin Peterson added the comment: New changeset 0e6c8ee2358a2e23117501826c008842acb835ac by Benjamin Peterson (Jamie Davis) in branch 'master': bpo-32981: Fix catastrophic backtracking vulns (#5955)

[issue32981] Catastrophic backtracking in poplib and difflib

Change by miss-islington : -- keywords: +patch pull_requests: +5735 stage: -> patch review ___ Python tracker

[issue32991] AttributeError in doctest.DocTestFinder.find

New submission from Jason R. Coombs : In Python 3.6, one could find doctests on a namespace package: ``` $ mkdir foo $ python3.6 Python 3.6.4 (v3.6.4:d48ecebad5, Dec 18 2017, 21:07:28) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits"

Re: RFC: Proposal: Deterministic Object Destruction

On Sat, 03 Mar 2018 18:19:37 -0800, Ooomzay wrote: >> def function(): >> x = open_resource() >> process(x) >> # and we're done with x now, but too lazy to explicitly close it >> sleep(1) # Simulate some more work. Lots of work. >> return >> # and finally x is closed

Re: RFC: Proposal: Deterministic Object Destruction

On Sat, 03 Mar 2018 08:02:35 -0800, ooomzay wrote: [...] >> > But I am not! On the contrary RAII frees the programmer from even >> > having to remember to close the file. The poster asked what would >> > happen if the resource was deliberately kept open by storing a >> > reference at global

Re: RFC: Proposal: Deterministic Object Destruction

On Sun, Mar 4, 2018 at 1:45 PM, Ooomzay wrote: > On Sunday, 4 March 2018 01:58:02 UTC, Gregory Ewing wrote: >> ooomzay wrote: >> > Well he was not telling you the whole story: RAII works just as well with >> > heap objects using smart pointers (unique_ptr and friends) which

Re: RFC: Proposal: Deterministic Object Destruction

On Sunday, 4 March 2018 01:58:02 UTC, Gregory Ewing wrote: > ooomzay wrote: > > Well he was not telling you the whole story: RAII works just as well with > > heap objects using smart pointers (unique_ptr and friends) which are a > > closer > > analogy to python object references. > > By that

Re: RFC: Proposal: Deterministic Object Destruction

On 3/3/18 9:10 PM, Chris Angelico wrote: On Sun, Mar 4, 2018 at 1:01 PM, Ooomzay wrote: On Saturday, 3 March 2018 17:44:08 UTC, Chris Angelico wrote: On Sun, Mar 4, 2018 at 4:37 AM, Richard Damon Yes, stack allocated object in C++ have a nice

Re: RFC: Proposal: Deterministic Object Destruction (Posting On Python-List Prohibited)

Richard Damon wrote: The idea was to have a way to mark that certain classes/objects request that they are reference counted so they get the __del__ called as soon as the last reference goes away, without needing to require that overhead for all objects in all implementations. That could be

Re: RFC: Proposal: Deterministic Object Destruction

On Friday, 2 March 2018 15:37:25 UTC, Paul Moore wrote: [snip] > def fn(): > for i in range(1): > with open(f"file{i}.txt", "w") as f: > f.write("Some text") > > How would you write this in your RAII style - without leaving 10,000 > file descriptors

Re: RFC: Proposal: Deterministic Object Destruction (Posting On Python-List Prohibited)

Steven D'Aprano wrote: Not just the class __dict__. You would have to do a full search of the MRO looking for any superclass which defines such methods. That could be reduced a lot by making it a type slot. But it would still increase the overhead of every refcount change by at least a factor

Re: RFC: Proposal: Deterministic Object Destruction

On Saturday, 3 March 2018 23:52:34 UTC, Steven D'Aprano wrote: > I know that laziness and hubris are programmer virtues, but there is > still such a thing as *too much laziness*. RAII works in C++ where > instances are allocated in the stack, but even there, if you have an > especially

Re: RFC: Proposal: Deterministic Object Destruction (Posting On Python-List Prohibited)

Paul Rubin wrote: Richard Damon writes: a class to define member functions like __ref__ and __unref__ (or perhaps some other name) that if defined, would be called every time a name was bound or unbound to an object? That sounds horrendous and wouldn't handle the

Re: RFC: Proposal: Deterministic Object Destruction

On Sun, Mar 4, 2018 at 1:01 PM, Ooomzay wrote: > On Saturday, 3 March 2018 17:44:08 UTC, Chris Angelico wrote: >> On Sun, Mar 4, 2018 at 4:37 AM, Richard Damon >> > Yes, stack allocated object in C++ have a nice lifetime to allow RAII to >> > work,

Re: RFC: Proposal: Deterministic Object Destruction

On Saturday, 3 March 2018 17:44:08 UTC, Chris Angelico wrote: > On Sun, Mar 4, 2018 at 4:37 AM, Richard Damon > > Yes, stack allocated object in C++ have a nice lifetime to allow RAII to > > work, but it doesn't just work with stack allocated objects. A lot of RAII > >

Re: RFC: Proposal: Deterministic Object Destruction

On Saturday, 3 March 2018 17:16:14 UTC, Ned Batchelder wrote: > On 3/2/18 10:36 AM, Paul Moore wrote: > > Or (real Python): > > > > def fn(): > > for i in range(1): > > with open(f"file{i}.txt", "w") as f: > > f.write("Some text") > > > > How would

Re: RFC: Proposal: Deterministic Object Destruction

ooom...@gmail.com wrote: Well he was not telling you the whole story: RAII works just as well with heap objects using smart pointers (unique_ptr and friends) which are a closer analogy to python object references. By that definition, *all* resource management in Python is based on RAII[1]. The

Re: RFC: Proposal: Deterministic Object Destruction

On Friday, March 2, 2018 at 5:29:54 AM UTC, Rustom Mody wrote: > Please excuse if this has been addressed above and/or its too basic: > What's the difference between RAII and python's with/context-managers? They address the same problem but I am claiming that RAII achieves this in a

Re: RFC: Proposal: Deterministic Object Destruction

On Friday, March 2, 2018 at 3:37:25 PM UTC, Paul Moore wrote: > [...] > RAII works in C++ (where it was initially invented) because it's used > with stack-allocated variables that have clearly-defined and limited > scope. RAII also works with smart pointers, which are a closer analogue to

Re: RFC: Proposal: Deterministic Object Destruction (Posting On Python-List Prohibited)

On 3/3/18 6:57 PM, Steven D'Aprano wrote: On Sat, 03 Mar 2018 10:01:43 -0700, Ian Kelly wrote: On Sat, Mar 3, 2018 at 9:19 AM, Richard Damon wrote: One idea does come to mind though, would it be reasonable, and somewhat Pythonic, for a class to define member

Re: RFC: Proposal: Deterministic Object Destruction

On 3/3/18 6:49 PM, Steven D'Aprano wrote: On Sat, 03 Mar 2018 12:37:08 -0500, Richard Damon wrote: With RAII and immediate destruction on end of scope, we can automate the release, without it and you need a lot of explicit code to manage these resources. Not so much. with

[issue21998] asyncio: support fork

Zac Medico added the comment: I'm not sure about possible use cases that might conflict with this approach, but using a separate event loop for each pid seems very reasonable to me, as follows: _default_policy = asyncio.get_event_loop_policy() _pid_loop = {} class

[issue32989] IDLE: Incorrect signature in call from editor to pyparse.find_good_parse_start

Cheryl Sabella added the comment: I didn't incorporate all the suggestions into the first PR for this so that it could focus on the parameter change and the tests. `newline_and_indent_event` does a lot, so I want to make sure the tests look good. I was also going to add

Re: RFC: Proposal: Deterministic Object Destruction (Posting On Python-List Prohibited)

On Sat, 03 Mar 2018 10:01:43 -0700, Ian Kelly wrote: > On Sat, Mar 3, 2018 at 9:19 AM, Richard Damon > wrote: >> One idea does come to mind though, would it be reasonable, and somewhat >> Pythonic, for a class to define member functions like __ref__ and >> __unref__ (or

Re: RFC: Proposal: Deterministic Object Destruction

On Sat, 03 Mar 2018 12:37:08 -0500, Richard Damon wrote: > With RAII and immediate destruction on end of scope, we can automate the > release, without it and you need a lot of explicit code to manage these > resources. Not so much. with resource_i_care_about() as rsrc: process(rsrc) is

Re: cute interview problem

On Sat, Mar 3, 2018 at 3:26 PM, Richard Damon wrote: > On 2/28/18 3:51 PM, Ian Kelly wrote: >> >> On Wed, Feb 28, 2018 at 12:55 PM, wrote: >>> >>> On Tuesday, 27 February 2018 00:42:02 UTC+1, Paul Rubin wrote: Ron Aaron posted the below

[issue32989] IDLE: Incorrect signature in call from editor to pyparse.find_good_parse_start

Change by Cheryl Sabella : -- keywords: +patch pull_requests: +5734 stage: test needed -> patch review ___ Python tracker ___

Re: RFC: Proposal: Deterministic Object Destruction

On Saturday, March 3, 2018 at 4:33:59 PM UTC, Michael Torrie wrote: > On 03/03/2018 09:02 AM, ooomzay wrote: > > I can assure you that RAII does what it says on the tin and is relied on in > > many critical systems to release resources robustly ... given the > > pre-requisite deterministic

Re: cute interview problem

On 2/28/18 3:51 PM, Ian Kelly wrote: On Wed, Feb 28, 2018 at 12:55 PM, wrote: On Tuesday, 27 February 2018 00:42:02 UTC+1, Paul Rubin wrote: Ron Aaron posted the below url on comp.lang.forth. It points to what I thought was a cute problem, along with his solution in his

[issue32919] csv.reader() to support QUOTE_ALL

R. David Murray added the comment: QUOTE_ALL only makes sense as an output control parameter, IMO. It is an output discipline but doesn't say anything about semantics. In csv format, an empty field and a field containing the empty quoted string are completely

Re: RFC: Proposal: Deterministic Object Destruction

On 3/3/18 1:28 PM, Chris Angelico wrote: On Sun, Mar 4, 2018 at 5:22 AM, Richard Damon wrote: On 3/3/18 12:43 PM, Chris Angelico wrote: On Sun, Mar 4, 2018 at 4:37 AM, Richard Damon wrote: On 3/3/18 11:33 AM, Michael Torrie wrote: On

[issue32758] Stack overflow when parse long expression to AST

Brett Cannon added the comment: You're probably right and it's worth propagating the warning a bit wider. -- assignee: docs@python -> brett.cannon ___ Python tracker

Cheetah 3.1.0

Hello! I'm pleased to announce version 3.1.0, the first stable release of branch 3.1 of CheetahTemplate3. What's new in CheetahTemplate3 == Contributors for this release is Mathias Stearn. Features: - Fix Cheetah to work with PyPy. Pull request by Mathias

[issue32963] Python 2.7 tutorial claims source code is UTF-8 encoded

Brett Cannon added the comment: No need to apologize! We all only have so much free time. -- ___ Python tracker ___

Re: RFC: Proposal: Deterministic Object Destruction

On Sun, Mar 4, 2018 at 5:22 AM, Richard Damon wrote: > On 3/3/18 12:43 PM, Chris Angelico wrote: >> >> On Sun, Mar 4, 2018 at 4:37 AM, Richard Damon >> wrote: >>> >>> On 3/3/18 11:33 AM, Michael Torrie wrote: On 03/03/2018 09:02 AM,

Re: RFC: Proposal: Deterministic Object Destruction

On 3/3/18 12:43 PM, Chris Angelico wrote: On Sun, Mar 4, 2018 at 4:37 AM, Richard Damon wrote: On 3/3/18 11:33 AM, Michael Torrie wrote: On 03/03/2018 09:02 AM, ooom...@gmail.com wrote: I can assure you that RAII does what it says on the tin and is relied on in many

[issue32990] Supporting extensible format(PCM) for wave.open(read-mode)

Ned Deily added the comment: Thanks for working on this. Please follow the process in our Developers Guide and submit a PR against the master branch (for 3.8). After a core developer reviews it and if it is accepted, we can then decide about backports to other release

[issue32990] Supporting extensible format(PCM) for wave.open(read-mode)

Andrea Celletti added the comment: I am currently working on a patch for this. When done can I try pushing this in 3.7 rather than 3.8? It is not much of an enhancement but rather fixing the code that raises an error for a perfectly valid PCM wave file (bugfix).

[issue26707] plistlib fails to parse bplist with 0x80 UID values

Jon Janzen added the comment: Hello, I have attached a file extracted from the database of the 2Do App for iOS and macOS. The file contains information about tags used in the app. plistlib cannot currently parse this file because it lacks the ability to read byte 0x80

[issue32730] Allow py launcher to launch other registered Pythons

Steve Dower added the comment: Since I took the time to do a brain dump of my thinking here, feel free to review/contribute to https://github.com/zooba/PyLauncher/wiki Note that the code in that repo doesn't match the wiki page, and while I think it's good code I do

Re: RFC: Proposal: Deterministic Object Destruction

On Sun, Mar 4, 2018 at 4:37 AM, Richard Damon wrote: > On 3/3/18 11:33 AM, Michael Torrie wrote: >> >> On 03/03/2018 09:02 AM, ooom...@gmail.com wrote: >>> >>> I can assure you that RAII does what it says on the tin and is relied on >>> in >>> many critical systems to

Re: RFC: Proposal: Deterministic Object Destruction

On 3/3/18 11:33 AM, Michael Torrie wrote: On 03/03/2018 09:02 AM, ooom...@gmail.com wrote: I can assure you that RAII does what it says on the tin and is relied on in many critical systems to release resources robustly ... given the pre-requisite deterministic destruction. Sure but did you

Re: RFC: Proposal: Deterministic Object Destruction (Posting On Python-List Prohibited)

On Sun, Mar 4, 2018 at 3:19 AM, Richard Damon wrote: > One idea does come to mind though, would it be reasonable, and somewhat > Pythonic, for a class to define member functions like __ref__ and __unref__ > (or perhaps some other name) that if defined, would be called

Re: RFC: Proposal: Deterministic Object Destruction

On 2/28/18 6:53 PM, ooom...@gmail.com wrote: On Wednesday, February 28, 2018 at 11:45:24 PM UTC, ooo...@gmail.com wrote: On Wednesday, February 28, 2018 at 11:02:17 PM UTC, Chris Angelico wrote: On Thu, Mar 1, 2018 at 9:51 AM, ooomzay wrote: [snip] Taking a really simple situation: class

Re: RFC: Proposal: Deterministic Object Destruction

On 3/2/18 10:36 AM, Paul Moore wrote: Or (real Python): def fn(): for i in range(1): with open(f"file{i}.txt", "w") as f: f.write("Some text") How would you write this in your RAII style - without leaving 10,000 file descriptors open until the

Re: RFC: Proposal: Deterministic Object Destruction

On 2/28/2018 11:51 PM, ooom...@gmail.com wrote: This PEP proposes that valid python interpreters *must* synchronously destroy objects when the last reference to an object goes out of scope. This interpreter behaviour is currently permitted and exhibited by the reference implementation

Re: RFC: Proposal: Deterministic Object Destruction (Posting On Python-List Prohibited)

On Sun, Mar 4, 2018 at 3:19 AM, Richard Damon wrote: > On 3/3/18 9:03 AM, Ian Kelly wrote: >> >> On Fri, Mar 2, 2018 at 9:57 PM, Gregory Ewing >> wrote: >>> >>> Paul Rubin wrote: So you want the programmer to put more head

Re: RFC: Proposal: Deterministic Object Destruction (Posting On Python-List Prohibited)

On Sat, Mar 3, 2018 at 9:19 AM, Richard Damon wrote: > One idea does come to mind though, would it be reasonable, and somewhat > Pythonic, for a class to define member functions like __ref__ and __unref__ > (or perhaps some other name) that if defined, would be called

Re: RFC: Proposal: Deterministic Object Destruction

On 03/03/2018 09:02 AM, ooom...@gmail.com wrote: > I can assure you that RAII does what it says on the tin and is relied on in > many critical systems to release resources robustly ... given the > pre-requisite deterministic destruction. Sure but did you read what Paul Moore wrote? He said

Re: RFC: Proposal: Deterministic Object Destruction (Posting On Python-List Prohibited)

On 3/3/18 9:03 AM, Ian Kelly wrote: On Fri, Mar 2, 2018 at 9:57 PM, Gregory Ewing wrote: Paul Rubin wrote: So you want the programmer to put more head scratching into figuring out which reference should be strong and which should be weak? Also, sometimes weak

[issue32980] Remove functions that do nothing in _Py_InitializeCore()

Thomas Nyberg added the comment: ince I originated this issue and I think I understand the concerns, I figured I could speed up the back and forth in this thread by opening this new PR which removes the `_PyFrame_Init()` function. I couldn't find any `_PyFrame_Fini()`

Re: RFC: Proposal: Deterministic Object Destruction

On Friday, March 2, 2018 at 10:43:57 PM UTC, Steven D'Aprano wrote: > On Fri, 02 Mar 2018 07:09:19 -0800, ooomzay wrote: > [...] > >> If you're going to *require* the programmer to explicitly del the > >> reference: > >> > >> f = open("file") > >> text = f.read() > >> del f > > > >

[issue32980] Remove functions that do nothing in _Py_InitializeCore()

Change by Thomas Nyberg : -- pull_requests: +5732 ___ Python tracker ___ ___

"except" and "subclasscheck" changed between CPython2 and 3

Hello, I found a difference of behavior about `except` statement between CPython 2.7 and 3.x . `except EXC_CLASS:` calls `__subclasscheck__` in 2.7, but does not in 3.x . Let me show you an example. Now, define a class "ExceptionLike" (with metaclass "ExceptionLikeMeta") below. class

Re: RFC: Proposal: Deterministic Object Destruction (Posting On Python-List Prohibited)

On Fri, Mar 2, 2018 at 9:57 PM, Gregory Ewing wrote: > Paul Rubin wrote: >> >> So you want the programmer to put more head scratching into figuring out >> which reference should be strong and which should be weak? > > > Also, sometimes weak references don't really

Re: read function of fuse

after a few tests, it appears that the file is read in pieces: read[0] 131072 bytes from 0 flags: 0x8000 read[0] 131072 bytes from 131072 flags: 0x8000 read[0] 131072 bytes from 262144 flags: 0x8000 ... read[0] 8192 bytes from 917504 flags: 0x8000 read[0] 4096 bytes from 925696 flags: 0x8000 so

[issue32964] Reuse a testing implementation of the path protocol in tests

Change by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue32964] Reuse a testing implementation of the path protocol in tests

Serhiy Storchaka added the comment: New changeset fbdd075c64a5229dfa26632cf1b2cf2361dc5003 by Serhiy Storchaka in branch '3.6': [3.6] bpo-32964: Reuse a testing implementation of the path protocol in tests. (GH-5930). (GH-5958)

[issue32758] Stack overflow when parse long expression to AST

Serhiy Storchaka added the comment: Thank you Brett! The comment LGTM. Is it worth to add warnings to other functions? * compile(), exec() and eval(). They are crashed due to recursion in the AST optimizer. This is a regression of 3.7. compile(..., PyCF_ONLY_AST)

[issue32963] Python 2.7 tutorial claims source code is UTF-8 encoded

Martijn Pieters added the comment: Thanks for the quick fix, sorry I didn't have a PR for this one! -- ___ Python tracker ___

read function of fuse

hello, my xb360hd module allows me to browse a xtaf partition (xbox360) and extract files. a file can be large (and discontinuous), so the readFile function of the module returns a generator. from a console, I can "easily" copy a file with this piece of code: partition =

[issue32990] Supporting extensible format(PCM) for wave.open(read-mode)

Change by Serhiy Storchaka : -- nosy: +serhiy.storchaka stage: -> needs patch versions: +Python 3.8 ___ Python tracker ___

[issue32990] Supporting extensible format(PCM) for wave.open(read-mode)

New submission from Andrea Celletti : The wave.Wave_read class currently supports 8, 16, 24, and 32 bit PCM files. Wave files are only supported if the wFormatTag in the format chunk matches the flag WAVE_FORMAT_PCM, which is correct but incomplete for 24 bit files.

[issue32388] Remove cross-version binary compatibility

Stefan Behnel added the comment: I'm ok with "removing" this "guarantee" (although it seems too late to apply this specific change to 3.7 now). While Cython users do ask for a way to build cross-version binaries from time to time, it's neither supported nor planned, and