[issue32989] IDLE: Fix pyparse.find_good_parse_start and its bad editor call

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I agree with limiting the scope to the None bug and the faulty call.  However, 
we should think of the None fix as primary, and the new test thereof as the 
primary test.  Fixing the None check exposes the call bug, which we also fix.  
I change the title here and on PR.

As you noted, the new editor TestCase is not directly relevant to testing the 
double fix except to show that there is no change in indent.  The way to do 
that is to pass None instead of the in-string function.  I did that 
(temporarily!) and the test passes, meaning that the indents are the same.  (I 
do however think some of them are dubious, and I want to mark those cases.)

We could have made editor tests that initially failed by exposing bod as an 
instance attribute (as we have done before), and including a longer test case 
for which bod is a positive int.  However, bod should remain local.

As an alternative, for experimentation, I added print(bod).  The values for the 
patch are 0, None, None, None, None, None, 0, 0, None.  I added '  a\n' to 
'Block opener - indents +1 level.' and changed the mark and the 5th 'None' 
became '4'.

The fact that passing None and _build_char_in_string_func(startatindex) result 
in the same indents raises the question of whether the call has any benefit in 
reducing net time after the followup call to get_continuation_type().  Maybe 
tomorrow I will try to write a good timeit test.

In the meanwhile, to get some idea of how well find_good_parse_start finds good 
parse starts, I restarted IDLE in a console with the print still added, loaded 
editor.py, and hit RETURN followed by UNDO, in various places. The first 
non-zero bod, 812, comes with the cursor at the end of 'def _sphinx_version():' 
 812 is probably the beginning of the line.  After "if __name__ == '__main__':" 
near the end, 1416.  After the final "run(_editor_window)", 1654.  The highest 
value I got in about 10 tries past the middle, 1931.  To me, this is 
pathetically bad.

I tried turning on CodeContext and got the same results where I tested.  bod 
should just be the beginning of the last context line.  I am not optimistic 
about timing results.

--
title: IDLE: Incorrect signature in call from editor to 
pyparse.find_good_parse_start -> IDLE: Fix pyparse.find_good_parse_start and 
its bad editor call

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31500] IDLE: Tiny font on HiDPI display

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I take it you want this reopened.  I have not touched IDLE 2.7 for over a year, 
but since a) there have been no complaints about the patch in released 3.6.3/4, 
b) we recommend the same tk 8.5.18 for both 2.7 and 3.6, and c) this is a 
crippling regression upon equipment upgrade, I will review and manually test on 
Windows a combined backport of both PRs first tested on a Linux or Mac system.  
It should be tested on a HiDPI system before a merge.

--
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open
versions:  -Python 3.6, Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: RFC: Proposal: Deterministic Object Destruction

[Ooomzay]

On Sunday, 4 March 2018 04:23:07 UTC, Steven D'Aprano  wrote:
> 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 (2.8 hours after you finished using it)
> >> 
> >> The answer in C++ is "well don't do that then". The answer is Python
> >> is, "don't be so lazy, just use a with statement".
> > 
> > The answer in C++ would be to say "don't be so lazy just put the x
> > manipulation in a function or sub-block". 
> 
> Right -- so you still have to think about resource management. The 
> premise of this proposal is that RAII means you don't have to think about 
> resource management, it just happens, but that's not really the case.

That is not my main premise: Which is that RAII is a more elegant (no 
specialised syntax at all) and robust way to manage resources.

Please consider the case of a composite resource: You need to implement
__enter__, __exit__ and track the open/closed state at every level in
your component hierarchy - even if some levels hold no resources directly.

This is burdensome, breaks encapsulation, breaks invariance and is error prone
...very unpythonic.

> > The answer with Python + this
> > PEP would be "don't be so lazy just put the x manipulation in a function
> > or explicitly del x" ...no new syntax.
> 
> Sure -- but it doesn't gain you anything we don't already have.

See above.
 
> It imposes enormous burdens on the maintainers of at least five 
> interpreters (CPython, Stackless, Jython, IronPython, PyPy) all of which 
> will need to be re-written to have RAII semantics guaranteed; 

Yes. This is a substantial issue that will almost certainly see it rejected by 
HWCNBN on political, rather than linguistic, grounds.

My PEP is about improving the linguistic integrity and fitness for resource 
management purpose of the language.

> it will 
> probably have significant performance costs; and at the end of the day, 
> the benefit over using a with statement is minor.
> 
> (Actually, I'm not convinced that there is *any* benefit. If anything, I 
> think it will be a reliability regression -- see below.)
> 
> >> If you want deterministic closing of resources, with statements are the
> >> way to do it.
> >> 
> >> def function():
> >> with open_resource() as x:
> >> process(x)
> >> # and x is guaranteed to be closed
> > 
> > What a palava!
> 
> I don't know that word, and neither do any of my dictionaries. I think 
> the word you might mean is "pelaver"?

I don't know that word, and neither do any of my dictionaries. I think 
the word you might mean is "Palaver"? 

Anyway Palava/Pelaver/Palaver/Palavra/Palabra derives from the word 
for "word", but in England it is often used idiomatically to mean a 
surfeit of words, or even more generally, a surfeit of effort.

I intend it in both senses: The unnecessary addition of 
the words "with", "as", "__enter__" & "__exit__" to the language 
and the need implement the latter two methods all 
over the place.

> In any case, you might not like with statements, but I think they're 
> infinitely better than:
> 
> def meaningless_function_that_exists_only_to_manage_resource():
> x = open_resource()
> process(x)

> def function():
> meaningless_function_that_exists_only_to_manage_resource()
> sleep(1)  # simulate a long-running function

Why would you prefer a new construct? Functions _are_ pythons scoping context! 
Giving one a pejorative name does not change that. 
 
> In other words, your solutions are just as much manual resource 
> management as the with statement. The only differences are:
> 
> - instead of explicitly using a dedicated syntax designed for 
>   resource management, you're implicitly using scope behaviour;

Excellent: With the benefit of automatic, exception safe, destruction of 
resources, including composite resources.
 
> - the with block is equivalent to a try...finally, and so it is
>   guaranteed to close the resource even if an exception occurs;
>   your solution isn't.

> If process(x) creates a non-local reference to x, and then raises an 
> exception, and that exception is caught elsewhere, x will not go out of 
> scope and won't be closed. 
> A regression in the reliability of the code.

This PEP does not affect existing code. Peeps who are familiar with RAII
understand that creating a global reference to an RAII resource is 
explicitly saying "I want this kept open at global scope" and that is the
behaviour that they will be guaranteed.

> (I'm moderately confident that this failure of RAII to deliver what it 
> promises is possible in C++ too.)

(Well I bet the entire VOIP stack, AAA and accounting modules in a certain 
9 satellite network's base-stations against you)


-- 

[issue32857] tkinter after_cancel does not behave correctly when called with id=None

[miss-islington]

miss-islington  added the comment:


New changeset 73a43960c7be50e136c5482404980175cb99f611 by Miss Islington (bot) 
in branch '3.6':
bpo-32857: Raise error when tkinter after_cancel() is called with None. 
(GH-5701)
https://github.com/python/cpython/commit/73a43960c7be50e136c5482404980175cb99f611


--
nosy: +miss-islington

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32857] tkinter after_cancel does not behave correctly when called with id=None

[miss-islington]

Change by miss-islington :


--
pull_requests: +5739

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: RFC: Proposal: Deterministic Object Destruction

[Ooomzay]

On Sunday, 4 March 2018 04:23:07 UTC, Steven D'Aprano  wrote:
> [...]
> [This PEP] imposes enormous burdens on the maintainers of at least five 
> interpreters (CPython, Stackless, Jython, IronPython, PyPy) all of which 
> will need to be re-written to have RAII semantics guaranteed; 

Not so:-  CPython, the reference interpreter, already implements the required 
behaviour, as mentioned in the PEP.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue32857] tkinter after_cancel does not behave correctly when called with id=None

[miss-islington]

Change by miss-islington :


--
pull_requests: +5738

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32857] tkinter after_cancel does not behave correctly when called with id=None

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 74382a3f175ac285cc924a73fd758e8dc3cc41bb by Serhiy Storchaka 
(Cheryl Sabella) in branch 'master':
bpo-32857: Raise error when tkinter after_cancel() is called with None. 
(GH-5701)
https://github.com/python/cpython/commit/74382a3f175ac285cc924a73fd758e8dc3cc41bb


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28716] Fractions instantiation revisited

[Stefan Behnel]

Stefan Behnel  added the comment:

Just FYI and as further motivation, I reimplemented this dedicated parser for 
quicktions (in Cython, so the timings and speedups are not comparable).

https://github.com/scoder/quicktions/commit/cc034e07325ec492decdb7b1bcca69246cc780fd

I was able to get another quite visible improvement by caching the values of 
"10 ** shift" for 0 <= shift < 58 in a tuple. Higher values are very unlikely 
in practice, and the memory size of a tuple with 58 values gives a nice 
multiple of the usual cache line size. (I originally stored 64 values in my 
commit but then cut it down later.)

https://github.com/scoder/quicktions/commit/c20add53dc4936d70eb0daa370946a600adddca9

I suspect that the difference won't be as big for the Python implementation, 
but it still seems worth a try.

The overall speedup that I got, compared to the initial regex implementation, 
is 50-70%.

[regex]  $ python3.7 -m timeit -s 'from quicktions import Fraction as F' 
'F("153456/789344")'
20 loops, best of 5: 1.19 usec per loop
[native] $ python3.7 -m timeit -s 'from quicktions import Fraction as F' 
'F("153456/789344")'
50 loops, best of 5: 593 nsec per loop

[regex]  $ python3.7 -m timeit -s 'from quicktions import Fraction as F' 
'F("15.3456789E+4")'
10 loops, best of 5: 2.3 usec per loop
[native] $ python3.7 -m timeit -s 'from quicktions import Fraction as F' 
'F("15.3456789E+4")'
50 loops, best of 5: 667 nsec per loop

It could be even higher if I additionally moved the int() integer parsing into 
Cython. Might try that at some point. But that's also not something that 
concerns the implementation in CPython.

--
versions: +Python 3.8 -Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32993] issue30657 Incomplete fix

[yao zhihua]

New submission from yao zhihua :

Due to the incomplete fix for CVE-2011-1521, urllib and urllib2 exist for this 
vulnerability and I tested on the version of Python 3.4.8 (default, Mar 4 2018, 
20:37:04).I am sorry that I do not know how to fix it.

--
components: Library (Lib)
files: poc.py
messages: 313212
nosy: yao zhihua
priority: normal
severity: normal
status: open
title: issue30657 Incomplete fix
type: security
versions: Python 3.4
Added file: https://bugs.python.org/file47469/poc.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: RFC: Proposal: Deterministic Object Destruction

[Chris Angelico]

On Mon, Mar 5, 2018 at 12:26 AM, Ooomzay  wrote:
> Well refcounts are definitely "doable": This is how the reference python 
> implementation, CPython, currently manages to comply with this PEP and can
> therefore be used for RAII.
>
> This PEP is an attempt to _guarantee_ this behaviour and make the elegance
> of RAII available to all pythonistas that want it. Without this guarantee
> python is not attractive to applications that must manage non-trivial
> resources reliably.
>
> Aside: I once read somewhere that must have seemed authoritative at the
> time, that CPython _guarantees_ to continue to behave like this - but now the 
> subject is topical again I can find no trace of this guarantee.

That's because there is no such guarantee. In fact, you can probably
find places in the docs where it is specifically stated that you
cannot depend on __del__ for this.

You still haven't said how you're going to cope with reference cycles
- or are you expecting every single decref to do a full cycle check?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: RFC: Proposal: Deterministic Object Destruction

[Chris Angelico]

On Mon, Mar 5, 2018 at 1:11 AM, Ooomzay  wrote:
> On Sunday, 4 March 2018 03:00:13 UTC, Chris Angelico  wrote:
>> This thread is dead. The OP wants to wave a magic wand and say
>> "__del__ is now guaranteed to be called immediately",
>
> No "magic" required: Just one line change in the language reference will do 
> it.

Go ahead and actually implement it. It's not just one line in the
language reference.

>> without any explanation
>
> The PEP says it all really: To make the very pythonic RAII idiom available in 
> python.
>
>> - and, from the look of things, without any understanding
>> - of what that means for the language
>
> What impact on the _language_ (c.f. interpreter) do you think I have not 
> understood?
>
> It is is 100% backwards compatible with the language. It breaks nothing.
>
> It allows people who want to use the RAII idiom to do so.
>
> It allows people who want to use the "with" idiom to continue do so.
>
>> and the interpreters.
>
> I am well aware of what it will mean for interpreters. For some interpreters 
> it will have zero impact (e.g. CPython) and for some others it would unlikely 
> be economic to make them comply.
>

I don't even understand you now. First off, you just acknowledged that
this WILL impact CPython - you're not simply mandating what CPython
already does, you're tightening up the rules significantly. For others
- what do you even mean, "unlikely be economic to make them comply"?
Are you saying that the Jython project should simply die? Or that it
should become non-compliant with the Python spec? Huh?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: RFC: Proposal: Deterministic Object Destruction

[Steven D'Aprano]

On Sun, 04 Mar 2018 03:37:38 -0800, Ooomzay wrote:

> Please consider the case of a composite resource: You need to implement
> __enter__, __exit__ and track the open/closed state at every level in
> your component hierarchy - even if some levels hold no resources
> directly.

I'm sorry, that description is too abstract for me to understand. Can you 
give a simple example?


> This is burdensome, breaks encapsulation, breaks invariance and is error
> prone ...very unpythonic.

Without a more concrete example, I cannot comment on these claims.


[...]
> My PEP is about improving the linguistic integrity and fitness for
> resource management purpose of the language.

So you claim, but *requiring* reference counting semantics does not 
improve the integrity or fitness of the language. And the required 
changes to programming styles and practices (no cycles, no globals, put 
all resources inside their own scope) demonstrate that this is a step 
backwards.

Right now I can write reliable code that uses external resources (such as 
a database connection or file) and put it in my application's module 
scope, and still easily manage the resource lifetime. I cannot do that by 
relying only on RAII. That's a step backwards as far as language fitness.


>> In any case, you might not like with statements, but I think they're
>> infinitely better than:
>> 
>> def meaningless_function_that_exists_only_to_manage_resource():
>> x = open_resource()
>> process(x)
> 
>> def function():
>> meaningless_function_that_exists_only_to_manage_resource()
>> sleep(1)  # simulate a long-running function
> 
> Why would you prefer a new construct?

I don't prefer a new construct. The "with" statement isn't "new". It goes 
back to Python 2.5 (`from __future__ import with_statement`) which is 
more than eleven years old now. That's about half the lifetime of the 
language!

I prefer the with statement because it is *explicit*, simple to use, and 
clear to read. I can read some code and instantly see that when the with 
block ends, the resource will be closed, regardless of how many 
references to the object still exist.

I don't have to try to predict (guess!) when the last reference will go 
out of scope, because that's irrelevant.

RAII conflates the lifetime of the object with the lifetime of the 
resource held by the object. They are not the same, and the object can 
outlive the resource.

Your position is:

"RAII makes it really elegant to close the file! All you need to do is 
make sure that when you want to close the file, you delete all the 
references to the file, so that it goes out of scope, and the file will 
be closed."

My position is:

"If I want to close the file, I'll just close the file. Why should I care 
that there are zero or one or a million references to it?"


>> - the with block is equivalent to a try...finally, and so it is
>>   guaranteed to close the resource even if an exception occurs; your
>>   solution isn't.
> 
>> If process(x) creates a non-local reference to x, and then raises an
>> exception, and that exception is caught elsewhere, x will not go out of
>> scope and won't be closed.
>> A regression in the reliability of the code.
> 
> This PEP does not affect existing code. Peeps who are familiar with RAII
> understand that creating a global reference to an RAII resource is
> explicitly saying "I want this kept open at global scope" and that is
> the behaviour that they will be guaranteed.

I'm not talking about global scope. Any persistent reference to the 
object will prevent the resource from being closed. 

Here's a proof of concept which demonstrates the problem with conflating 
object scope and resource lifetime. Notice that there are no globals used.


def main():
from time import sleep
values = []
def process():
f = open('/tmp/foo', 'w')
values.append(f)
f.write("Hello world!")
f.read()  # oops!
del values[-1]
try:
process()
except IOError:
pass
# The file should be closed now. But it isn't.
sleep(10)  # simulate doing a lot of work
g = open('/tmp/foo', 'r')
assert g.read() == "Hello world!"


The assertion fails, because the file hasn't be closed in a timely 
manner. On the other hand:

def main2():
from time import sleep
values = []
def process():
with open('/tmp/bar', 'w') as f:
values.append(f)
f.write("Hello world!")
f.read()  # oops!
del values[-1]
try:
process()
except IOError:
pass
sleep(10)  # simulate doing a lot of work
g = open('/tmp/foo', 'r')
assert g.read() == "Hello world!"


The assertion here passes.

Now, these are fairly contrived examples, but in real code the resource 
owner might be passed into an iterator, or bound to a class attribute, or 
anything else that holds onto a reference to it. As soon as that happens, 
and there's another reference to the object 

Re: RFC: Proposal: Deterministic Object Destruction

[Ooomzay]

On Sunday, 4 March 2018 03:16:31 UTC, Paul Rubin  wrote:
> Chris Angelico  writes:
> > Yep, cool. Now do that with all of your smart pointers being on the
> > heap too. You are not allowed to use ANY stack objects.  ANY. Got it?
> 
> That's both overconstraining and not even that big a problem the way you
> phrase it.
> 
> 1) Python has both the "with" statement and try/finally.  Both of these
> run code at the exit from a syntactically defined scope.  So they are
> like stack allocation in C++, where a deallocator can run when the scope
> exits.
> 
> 2) Even with no scope-based de-allocation, it's common to put smart
> pointers into containers like lists and vectors.  So you could have a
> unique_ptr to a filestream object, and stash the unique_ptr someplace as
> a vector element, where the vector itself could be part of some even
> more deeply nested structure.  At some point, the big structure gets
> deleted (maybe through a manually-executed delete statement).  When that
> happens, if the nested structures are all standard containers full of
> unique_ptrs, the top-level finalizer will end up traversing the entire
> tree and freeing up the file handles and whatever else might be in
> there.
> 
> It occurs to me, maybe #2 above is closer to what the OP is really after
> in Python.  

Yep. C++ smart pointers are a good analogue to python references for 
purposes of this PEP.

> I guess it's doable, but refcounts don't seem like the right
> way. 

Well refcounts are definitely "doable": This is how the reference python 
implementation, CPython, currently manages to comply with this PEP and can 
therefore be used for RAII.

This PEP is an attempt to _guarantee_ this behaviour and make the elegance 
of RAII available to all pythonistas that want it. Without this guarantee 
python is not attractive to applications that must manage non-trivial 
resources reliably.

Aside: I once read somewhere that must have seemed authoritative at the
time, that CPython _guarantees_ to continue to behave like this - but now the 
subject is topical again I can find no trace of this guarantee.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: RFC: Proposal: Deterministic Object Destruction

[Steven D'Aprano]

On Sun, 04 Mar 2018 04:37:46 -0800, Ooomzay wrote:

> On Sunday, 4 March 2018 04:23:07 UTC, Steven D'Aprano  wrote:
>> [...]
>> [This PEP] imposes enormous burdens on the maintainers of at least five
>> interpreters (CPython, Stackless, Jython, IronPython, PyPy) all of
>> which will need to be re-written to have RAII semantics guaranteed;
> 
> Not so:-  CPython, the reference interpreter, already implements the
> required behaviour, as mentioned in the PEP.

Except that it doesn't. From the docs:

"It is not guaranteed that __del__() methods are called for objects that 
still exist when the interpreter exits."

https://docs.python.org/3/reference/datamodel.html#object.__del__


That limitation of CPython is much reduced now compared to older 
versions, but there are still circumstances where the __del__ method 
cannot be called.


-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: RFC: Proposal: Deterministic Object Destruction

[Ooomzay]

On Sunday, 4 March 2018 03:00:13 UTC, Chris Angelico  wrote:
> This thread is dead. The OP wants to wave a magic wand and say
> "__del__ is now guaranteed to be called immediately", 

No "magic" required: Just one line change in the language reference will do it.

> without any explanation

The PEP says it all really: To make the very pythonic RAII idiom available in 
python.

> - and, from the look of things, without any understanding
> - of what that means for the language 

What impact on the _language_ (c.f. interpreter) do you think I have not 
understood?

It is is 100% backwards compatible with the language. It breaks nothing.

It allows people who want to use the RAII idiom to do so.

It allows people who want to use the "with" idiom to continue do so.

> and the interpreters. 

I am well aware of what it will mean for interpreters. For some interpreters it 
will have zero impact (e.g. CPython) and for some others it would unlikely be 
economic to make them comply.

The decision here is does python want to be more pythonic, and make itself 
attractive for resource management applications or does it want to be 
compromised by some implementations?

> Everyone else is saying "your magic wand is broken". This is not going to go
> anywhere.

Well I see a lot of posts that indicate peeps here are more comfortable with 
the "with" idiom than the RAII idiom but I have not yet seen a single 
linguistic problem or breakage.

As it happens I have used RAII extensively with CPython to manage a debugging 
environment with complex external resources that need managing very 
efficiently. 

(I would use C++ if starting from scratch because it _guarantees_ the required 
deterministic destruction whereas python does not)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: RFC: Proposal: Deterministic Object Destruction

[Ned Batchelder]

On 3/4/18 7:37 AM, Ooomzay wrote:

On Sunday, 4 March 2018 04:23:07 UTC, Steven D'Aprano  wrote:

[...]
[This PEP] imposes enormous burdens on the maintainers of at least five
interpreters (CPython, Stackless, Jython, IronPython, PyPy) all of which
will need to be re-written to have RAII semantics guaranteed;

Not so:-  CPython, the reference interpreter, already implements the required 
behaviour, as mentioned in the PEP.


Except for cycles.

--Ned.
--
https://mail.python.org/mailman/listinfo/python-list

Re: RFC: Proposal: Deterministic Object Destruction

[Ned Batchelder]

On 3/4/18 8:26 AM, Ooomzay wrote:

On Sunday, 4 March 2018 03:16:31 UTC, Paul Rubin  wrote:

Chris Angelico  writes:

Yep, cool. Now do that with all of your smart pointers being on the
heap too. You are not allowed to use ANY stack objects.  ANY. Got it?

That's both overconstraining and not even that big a problem the way you
phrase it.

1) Python has both the "with" statement and try/finally.  Both of these
run code at the exit from a syntactically defined scope.  So they are
like stack allocation in C++, where a deallocator can run when the scope
exits.

2) Even with no scope-based de-allocation, it's common to put smart
pointers into containers like lists and vectors.  So you could have a
unique_ptr to a filestream object, and stash the unique_ptr someplace as
a vector element, where the vector itself could be part of some even
more deeply nested structure.  At some point, the big structure gets
deleted (maybe through a manually-executed delete statement).  When that
happens, if the nested structures are all standard containers full of
unique_ptrs, the top-level finalizer will end up traversing the entire
tree and freeing up the file handles and whatever else might be in
there.

It occurs to me, maybe #2 above is closer to what the OP is really after
in Python.

Yep. C++ smart pointers are a good analogue to python references for
purposes of this PEP.


I guess it's doable, but refcounts don't seem like the right
way.

Well refcounts are definitely "doable": This is how the reference python 
implementation, CPython, currently manages to comply with this PEP and can
therefore be used for RAII.




Are you including cyclic references in your assertion that CPython 
behaves as you want?


--Ned.
--
https://mail.python.org/mailman/listinfo/python-list

[issue32839] Add after_info as a function to tkinter

[Cheryl Sabella]

Cheryl Sabella  added the comment:

A few questions about returning the Python function name (specifically, how to 
derive it).  This doesn't address the open issue with what to do about a Tcl 
command not tied to a Python function.

1.  Serhiy wrote "and the API for restoring the original Python callable is 
private."  What is that API?

2.  In the _register method, the Tcl command name is the callback ID + the 
function name:
f = CallWrapper(callback, None, self._root).__call__
cbname = repr(id(f))
try:
callback = callback.__func__
except AttributeError:
pass
try:
cbname = cbname + callback.__name__
except AttributeError:
pass 
So, with the values returned from tk.call('after', 'info', id) as (script, 
type), the Python function should be the same as script.lstrip('0123456789').  
I'm not sure if that would be the best way to get the name back.

3.  In tkinter, there is a list created/added to during _register:
self._tclCommands.append(cbname)
where cbname is the Tcl command name (as defined by the code in q2 above).  
Would it be possible to change _tclCommands to a dict mapping Tcl command name 
to Python function name?  _tclCommands already has some logic around it, 
including .remove functions, so I think a dictionary would be more efficient 
for the exisitng purposes.  Since it's semi-private, is there a fear with 
backward compatibility if it changes from a list to a dict?  Is it better to 
add a new dict variable?

Thanks!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32820] Add __format__ method to ipaddress

[Eric Osborne]

Eric Osborne  added the comment:

I have pushed out new diffs.

* moved __format__ to _BaseAddress, where it should have been in the first
place
* redid format parser as regexp, as it was getting awfully complicated
* added support for 'X'
* added support for 's' by falling through to regular format()
* added IPv6 to the test suite

This was a decent-sized change, but all the tests pass so it looks OK to me.
As per request, I defer importing re and compiling the necessary regexp
until it's absolutely necessary. This is significantly slower than
importing re and compiling the regexp when ipaddress is imported.

localized compile and import
In [4]: %timeit f'{a:#_b}'
7.05 µs ± 34.2 ns per loop (mean ± std. dev. of 7 runs, 10 loops each)

toplevel compile and import
In [2]: %timeit f'{a:#_b}'
5.34 µs ± 17 ns per loop (mean ± std. dev. of 7 runs, 10 loops each)

Is this worth trying to get clever about? It doesn't matter in my use case,
and I could make a reasonable argument either way. I'm tempted to leave it
localized, as I can't imagine a case where formatting eleventy billion IP
addresses as padded binary is all that time-sensitive.  On the other hand,
I'm also not sure how Pythonic it is to stick an import statement 20 lines
deep in a dunder method, so I'm open to suggestions.

eric

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32933] mock_open does not support iteration around text files.

[Anthony Flury]

Change by Anthony Flury :


--
pull_requests: +5742

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32857] tkinter after_cancel does not behave correctly when called with id=None

[miss-islington]

miss-islington  added the comment:


New changeset a5303dd9c263b337f02dda0038f2f5a10208140c by Miss Islington (bot) 
in branch '3.7':
bpo-32857: Raise error when tkinter after_cancel() is called with None. 
(GH-5701)
https://github.com/python/cpython/commit/a5303dd9c263b337f02dda0038f2f5a10208140c


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32992] unittest: Automatically run coroutines in a loop

[Petter Strandmark]

New submission from Petter Strandmark :

I am wondering whether it would be useful for unittest.TestCase to 
automatically run test methods that are coroutines within the default asyncio 
loop.

Example:

class TestAsync(unittest.TestCase):

async def test_foo(self):
result = await foo()
self.assertEqual(result, 42)

the test runner would then run test_foo within the default loop. If needed, we 
could also add functionality for providing a loop other than the default to the 
test class.

It seems to me that this functionality would be pretty easy to add to 
Lib/unittest/case.py:615 .

Personally, I think it would be useful. Right now I have to append every test 
case with a personal @run_in_loop decorator and I think unittest.TestCase could 
do this for me without breaking anything.

--
components: Library (Lib)
messages: 313211
nosy: Petter Strandmark
priority: normal
severity: normal
status: open
title: unittest: Automatically run coroutines in a loop
type: enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: RFC: Proposal: Deterministic Object Destruction

[Ned Batchelder]

On 3/4/18 9:11 AM, Ooomzay wrote:

I am well aware of what it will mean for interpreters. For some interpreters it 
will have zero impact (e.g. CPython) ...


There's no point continuing this if you are just going to insist on 
falsehoods like this.  CPython doesn't currently do what you want, but 
you are choosing to ignore the cases where it doesn't.  You have to deal 
with cycles.


--Ned.
--
https://mail.python.org/mailman/listinfo/python-list

Re: RFC: Proposal: Deterministic Object Destruction

[bartc]

On 04/03/2018 14:11, Ooomzay wrote:


Well I see a lot of posts that indicate peeps here are more comfortable with
the "with" idiom than the RAII idiom but I have not yet seen a single
linguistic problem or breakage.

As it happens I have used RAII extensively with CPython to manage a debugging 
environment with complex external resources that need managing very efficiently.


I have bit of problem with features normally used for the housekeeping 
of a language's data structures being roped in to control external 
resources that it knows nothing about.


Which also means that if X is a variable with the sole reference to some 
external resource, then a mere:


   X = 0

will close, destroy, or discard that resource. If the resource is 
non-trivial, then it perhaps deserves a non-trivial piece of code to 
deal with it when it's no longer needed.


It further means that when you did want to discard an expensive 
resource, then X going out of scope, calling del X or whatever, will not 
work if a copy of X still exists somewhere.


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

[issue32933] mock_open does not support iteration around text files.

[bbayles]

Change by bbayles :


--
nosy: +bbayles

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: RFC: Proposal: Deterministic Object Destruction

[Steven D'Aprano]

On Sun, 04 Mar 2018 09:37:34 -0500, Ned Batchelder wrote:

> On 3/4/18 7:37 AM, Ooomzay wrote:
>> On Sunday, 4 March 2018 04:23:07 UTC, Steven D'Aprano  wrote:
>>> [...]
>>> [This PEP] imposes enormous burdens on the maintainers of at least
>>> five interpreters (CPython, Stackless, Jython, IronPython, PyPy) all
>>> of which will need to be re-written to have RAII semantics guaranteed;
>> Not so:-  CPython, the reference interpreter, already implements the
>> required behaviour, as mentioned in the PEP.
> 
> Except for cycles.

And during interpreter shutdown.

-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

[issue32991] AttributeError in doctest.DocTestFinder.find

[Jason R. Coombs]

Jason R. Coombs  added the comment:

I tried creating a test, but I'm struggling. I added [this 
patch](https://gist.github.com/e795a9a34594d202711aedf22c484af9), and tried to 
run it, but it's not being run.

```
$ ./python.exe Tools/scripts/run_tests.py 'test_doctest'
/Users/jaraco/Dropbox/code/public/cpython/python.exe -u -W default -bb -E -m 
test -r -w -j 0 -u all,-largefile,-audio,-gui test_doctest
Using random seed 3885464
Run tests in parallel using 6 child processes
0:00:00 load avg: 2.02 [1/1] test_doctest passed
1 test OK.

Total duration: 828 ms
Tests result: SUCCESS
```

I'm pretty sure doctest doesn't have any unit tests, but only functional tests 
exercising actual doctests.

I don't understand Python test framework enough to know how to create a 
discoverable unit test. I could use some help with how one could wire up the 
test_doctest module to run a unit test.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32993] issue30657 Incomplete fix

[Senthil Kumaran]

Senthil Kumaran  added the comment:

@Yao, sorry, I don't understand it.
What is POC trying to demonstrate? How is it related to 
https://bugs.python.org/issue30657 

And CVE is this: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1521

--
nosy: +orsenthil

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32991] AttributeError in doctest.DocTestFinder.find

[Jason R. Coombs]

Jason R. Coombs  added the comment:

The main questions I have before proceeding with creating tests relate to what 
interfaces Python wishes to support. Here's the decision tree I have in my head.

- Retain the change of adding a __file__ attribute to namespace packages for 
Python 3.7?
  yes:
  - Should inspect.getfile still raise a TypeError on a namespace package?
no:
- The NEWS file should reflect this change also.
- doctest.DocTestFinder.find should account for this change.
yes:
- Capture with a test and and restore that expectation.
  no:
  - The change should be reverted.
- Regardless, the test suite should capture and assert that 
doctest.DocTestFinder.find should succeed on a namespace package.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32933] mock_open does not support iteration around text files.

[Anthony Flury]

Change by Anthony Flury :


--
pull_requests: +5743

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28955] Not matched behavior of numeric comparison with the documentation

[Cheryl Sabella]

Change by Cheryl Sabella :


--
keywords: +easy
stage:  -> needs patch
type: behavior -> enhancement
versions: +Python 3.7, Python 3.8 -Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32839] Add after_info as a function to tkinter

[Cheryl Sabella]

Change by Cheryl Sabella :


--
dependencies: +tkinter after_cancel does not behave correctly when called with 
id=None

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32933] mock_open does not support iteration around text files.

[Anthony Flury]

Change by Anthony Flury :


--
keywords: +patch
pull_requests: +5740
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32933] mock_open does not support iteration around text files.

[Anthony Flury]

Change by Anthony Flury :


--
pull_requests: +5741

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32854] Add ** Map Unpacking Support for namedtuple

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28626] Tutorial: rearrange discussion of output formatting to encourage f-strings

[Cheryl Sabella]

Cheryl Sabella  added the comment:

@akuchling

Would you be able to make a PR for this patch?  Thanks.

--
nosy: +csabella
versions: +Python 3.8 -Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32994] Building the html documentation is broken

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

$ make html BLURB="python3 -m blurb"
mkdir -p build
Building NEWS from Misc/NEWS.d with blurb
PATH=./venv/bin:$PATH sphinx-build -b html -d build/doctrees -D 
latex_elements.papersize=  . build/html 
Running Sphinx v1.5.6
loading pickled environment... not yet created

Theme error:
no theme named 'python_docs_theme' found (missing theme.conf?)
Makefile:43: recipe for target 'build' failed
make: *** [build] Error 1

--
components: Build
messages: 313219
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Building the html documentation is broken
type: behavior
versions: Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32994] Building the html documentation is broken

[Ned Deily]

Ned Deily  added the comment:

You need to install that component.  The easiest way is:

cd Doc
make venv
make html

--
nosy: +ned.deily
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32994] Building the html documentation is broken

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Thank you! All works now.

I tried `make clean` before, but not `make venv`.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30974] Update os.samefile docstring to match documentation

[Cheryl Sabella]

Change by Cheryl Sabella :


--
keywords: +easy
stage:  -> needs patch
versions: +Python 3.8 -Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: RFC: Proposal: Deterministic Object Destruction

[Richard Damon]

On 3/4/18 8:46 AM, Chris Angelico wrote:

On Mon, Mar 5, 2018 at 12:26 AM, Ooomzay  wrote:

Well refcounts are definitely "doable": This is how the reference python 
implementation, CPython, currently manages to comply with this PEP and can
therefore be used for RAII.

This PEP is an attempt to _guarantee_ this behaviour and make the elegance
of RAII available to all pythonistas that want it. Without this guarantee
python is not attractive to applications that must manage non-trivial
resources reliably.

Aside: I once read somewhere that must have seemed authoritative at the
time, that CPython _guarantees_ to continue to behave like this - but now the 
subject is topical again I can find no trace of this guarantee.

That's because there is no such guarantee. In fact, you can probably
find places in the docs where it is specifically stated that you
cannot depend on __del__ for this.

You still haven't said how you're going to cope with reference cycles
- or are you expecting every single decref to do a full cycle check?

ChrisA


My presumption of the proposal is the it does NOT expect that __del__ be 
called just because an object is no longer reachable but is in a cycle 
of isolated objects, those would still need to wait for the garbage 
collector to get them. The request is that when the direct reference 
count goes to 0, that __del__ gets called.


I think that is what CPython promises (but not other versions).

I am not positive if __del__ gets called for sure when the object is 
garbage collected (I thought it did, but I am not positive).


I am pretty sure it does NOT get called on object that are still in 
existence when things terminate (which would be the major difference 
from a language like C++)


What the language does not promise is that in general, __del__ be called 
'immediately' on the last reference going away in the general case, 
because CPythons reference counting is an implementation detail.


My understanding of this proposal is to ask that, I would say at least 
for selected objects, that all implementations perform this reference 
counting, allowing objects that track 'critical resources' to get 
disposed of in a timely manner and not wait for garbage collection. And 
that this is triggered only by the reference count going to zero, and 
not if the object happens to be in an isolated reference cycle. This 
does limit what you can do with this sort of object, but that normally 
isn't a problem.


--
Richard Damon

--
https://mail.python.org/mailman/listinfo/python-list

Re: RFC: Proposal: Deterministic Object Destruction

[Chris Angelico]

On Mon, Mar 5, 2018 at 9:09 AM, Richard Damon  wrote:
> My presumption of the proposal is the it does NOT expect that __del__ be
> called just because an object is no longer reachable but is in a cycle of
> isolated objects, those would still need to wait for the garbage collector
> to get them. The request is that when the direct reference count goes to 0,
> that __del__ gets called.
>
> I think that is what CPython promises (but not other versions).
>
> I am not positive if __del__ gets called for sure when the object is garbage
> collected (I thought it did, but I am not positive).
>
> I am pretty sure it does NOT get called on object that are still in
> existence when things terminate (which would be the major difference from a
> language like C++)
>
> What the language does not promise is that in general, __del__ be called
> 'immediately' on the last reference going away in the general case, because
> CPythons reference counting is an implementation detail.
>
> My understanding of this proposal is to ask that, I would say at least for
> selected objects, that all implementations perform this reference counting,
> allowing objects that track 'critical resources' to get disposed of in a
> timely manner and not wait for garbage collection. And that this is
> triggered only by the reference count going to zero, and not if the object
> happens to be in an isolated reference cycle. This does limit what you can
> do with this sort of object, but that normally isn't a problem.

Okay, that sounds reasonable. Let's help things out by creating a
special syntax for reference-counted object usage, to allow other
implementations to use different forms of garbage collection. When you
acquire these kinds of objects, you "mark" them with this special
syntax, and Python will call a special method on that object to say
"hey, you're now in use". Then when that special syntax is done,
Python calls another special method to say "hey, you're not in use any
more". Something like this:

using some_object:
...
...
...
# at the unindent, we're automatically not using it

That would call a special method some_object.__now_using__() at the
top of the block, and some_object.__not_using__() at the bottom. Or,
if the block exits because of an exception, we could call
some_object.__not_using(exc) with the exception details. I think this
could be a really good feature - it'd allow non-refcounted Python
implementations to have a strong guarantee of immediate disposal of a
managed resource, and it'd also strengthen the guarantee for
refcounted Pythons too.

Feel free to bikeshed the exact keywords and function names, of course.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue14266] pyunit script as shorthand for python -m unittest

[Cheryl Sabella]

Cheryl Sabella  added the comment:

Is there still interest in this?  Should it be converted to a PR for 3.8?

--
nosy: +csabella

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14266] pyunit script as shorthand for python -m unittest

[Ned Deily]

Ned Deily  added the comment:

-0.5.  I have mixed feelings about this.  While I can see the utility of it, I 
think more recently we have been moving away from the concept of installed 
scripts for standard library features primarily because they are difficult to 
manage when there are multiple versions of Python installed and with virtual 
environments.  Speaking of which, how would this work in practice within venvs? 
And how would it work with the Windows launcher, py?

--
nosy: +ned.deily

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: RFC: Proposal: Deterministic Object Destruction

[Ooomzay]

On Sunday, 4 March 2018 14:37:30 UTC, Ned Batchelder  wrote:
> Are you including cyclic references in your assertion that CPython 
> behaves as you want?

Yes. Because the only behaviour required for RAII is to detect and debug such 
cycles in order to eliminate them. It is a design error/resource leak to create 
an orphan cycle containing RAII objects.

def main():
gc,disable



-- 
https://mail.python.org/mailman/listinfo/python-list

[issue30147] Change in re.escape output is not documented in whatsnew

[Cheryl Sabella]

Change by Cheryl Sabella :


--
keywords: +patch
pull_requests: +5744
stage: needs patch -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32991] AttributeError in doctest.DocTestFinder.find

[Jason R. Coombs]

Jason R. Coombs  added the comment:

Okay. I've wired up some unittests in test_doctest, and with [this 
patch](https://gist.github.com/jaraco/ea992719ac931fa761a6e9ef7a354542), it now 
captures the failed expectation of this ticket.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30147] Change in re.escape output is not documented in whatsnew

[miss-islington]

Change by miss-islington :


--
pull_requests: +5745

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32991] AttributeError in doctest.DocTestFinder.find

[Jason R. Coombs]

Jason R. Coombs  added the comment:

And [this patch](https://gist.github.com/7184fa32670f2c6377ddeb710676) 
corrects the failure such that the test passes. It does so by restoring the 
expectation that inspect.getfile will once again raise a TypeError for these 
namespace packages (the yes/yes path in the decision tree). That's my 
recommendation going forward.

Feel free to review the work and apply the patches. As time permits, I may 
revisit the Developers Guide and learn the new process for submitting pull 
requests.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30147] Change in re.escape output is not documented in whatsnew

[Ned Deily]

Ned Deily  added the comment:


New changeset 18fd89246333bfa1b76c1623df689214f3ce2bf3 by Ned Deily (Cheryl 
Sabella) in branch 'master':
bpo-30147: Add re.escape changes to 3.7 What's New (GH-5978)
https://github.com/python/cpython/commit/18fd89246333bfa1b76c1623df689214f3ce2bf3


--
nosy: +ned.deily

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30147] Change in re.escape output is not documented in whatsnew

[Ned Deily]

Ned Deily  added the comment:


New changeset f92478d57a6b4014dcc0882d43b534fae1e7b929 by Ned Deily (Miss 
Islington (bot)) in branch '3.7':
[3.7] bpo-30147: Add re.escape changes to 3.7 What's New (GH-5978) (GH-5979)
https://github.com/python/cpython/commit/f92478d57a6b4014dcc0882d43b534fae1e7b929


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30147] Change in re.escape output is not documented in 3.7 whatsnew

[Ned Deily]

Ned Deily  added the comment:

Thanks, @csabella, for the PR!

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
title: Change in re.escape output is not documented in whatsnew -> Change in 
re.escape output is not documented in 3.7 whatsnew
versions: +Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32056] Improve exceptions in aifc, sunau and wave

[Ned Deily]

Ned Deily  added the comment:

> For any program which receive external file, to check the input file is 
> necessary to do, isn't it?

Yes and no.  wave.py is doing checking and can raise various exceptions.  So a 
well-designed program has to be prepared to handle exceptions when calling 
wave.py.  The suggested fix would provide a more specific error message and 
exception, rather than a division by zero one, but the net effect to the caller 
of wave.py is the same.

> And program error lead to security bug, that's not right?

No. Just because a program can terminate due to an uncaught exception is not by 
itself considered a security error.  See https://www.python.org/news/security/ 
for a discussion. In particular, "The general rule is any attack worth 
reporting via the security address must allow an attacker to affect the 
confidentiality, integrity and availability of the Python application or its 
system for which the attacker does not already have the capability."  As things 
stand now, if an application is vulnerable to a denial-of-service attack due to 
a faulty wav file, it is a failure in that application to be handling possible 
exceptions from wave.py, not a security issue in Python itself.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25197] Allow documentation switcher to change url to /3/ and /dev/

[Cheryl Sabella]

Cheryl Sabella  added the comment:

With the current dropdown for the documentation switcher (it has dev, 
prerelease, and stable options) and the addition of the language switcher, I 
believe this issue may be out of date.  Can it be closed?  Thanks!

--
nosy: +csabella

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: RFC: Proposal: Deterministic Object Destruction

[Steven D'Aprano]

On Mon, 05 Mar 2018 09:20:24 +1100, Chris Angelico wrote:

> Okay, that sounds reasonable. Let's help things out by creating a
> special syntax for reference-counted object usage
[...]
> Feel free to bikeshed the exact keywords and function names, of course.


I see what you did there.

:-)


-- 
Steve

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: RFC: Proposal: Deterministic Object Destruction

[Chris Angelico]

On Mon, Mar 5, 2018 at 10:42 AM, Steven D'Aprano
 wrote:
> On Mon, 05 Mar 2018 09:20:24 +1100, Chris Angelico wrote:
>
>> Okay, that sounds reasonable. Let's help things out by creating a
>> special syntax for reference-counted object usage
> [...]
>> Feel free to bikeshed the exact keywords and function names, of course.
>
>
> I see what you did there.
>
> :-)
>

Yeah I'm not sure if the OP will see what I did, though...

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: RFC: Proposal: Deterministic Object Destruction

[Ned Batchelder]

On 3/4/18 5:25 PM, Ooomzay wrote:

On Sunday, 4 March 2018 14:37:30 UTC, Ned Batchelder  wrote:

Are you including cyclic references in your assertion that CPython
behaves as you want?

Yes. Because the only behaviour required for RAII is to detect and debug such 
cycles in order to eliminate them. It is a design error/resource leak to create 
an orphan cycle containing RAII objects.

def main():
gc,disable





This isn't a reasonable position.  Cycles exist, and the gc exists for a 
reason.  Your proposal isn't going to go anywhere if you just naively 
ignore cycles.


--Ned.
--
https://mail.python.org/mailman/listinfo/python-list

Re: RFC: Proposal: Deterministic Object Destruction

[Dietmar Schwertberger]

On 3/4/2018 1:37 PM, Ooomzay wrote:
Not so:- CPython, the reference interpreter, already implements the 
required behaviour, as mentioned in the PEP. 


It does most of the time, but it's not guaranteed. See my previous post.

Regards,

Dietmar


--
https://mail.python.org/mailman/listinfo/python-list

Re: RFC: Proposal: Deterministic Object Destruction

[Chris Angelico]

On Sun, Mar 4, 2018 at 10:37 PM, Ooomzay  wrote:
> Please consider the case of a composite resource: You need to implement
> __enter__, __exit__ and track the open/closed state at every level in
> your component hierarchy - even if some levels hold no resources directly.
>
> This is burdensome, breaks encapsulation, breaks invariance and is error prone
> ...very unpythonic.

Why do you need to? I don't understand your complaint here - can you
give an example of a composite resource that needs this kind of
special management?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: RFC: Proposal: Deterministic Object Destruction

[Mark Lawrence]

On 04/03/18 02:28, Ooomzay wrote:

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 open until the end of the function?
  
 def fn():

 for i in range(1):
 f = RAIIFile(f"file{i}.txt", "w")
 f.write("Some text")



Over my dead body.  Not that it matters as I can't see this happening in 
a month of Sundays.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

[issue32130] xml.sax parser validation sometimes fails when obtaining DTDs from https sites

[Matej Cepl]

Change by Matej Cepl :


--
nosy: +mcepl

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: RFC: Proposal: Deterministic Object Destruction

[Ooomzay]

On Sunday, 4 March 2018 15:24:08 UTC, Steven D'Aprano  wrote:
> On Sun, 04 Mar 2018 03:37:38 -0800, Ooomzay wrote:
> 
> > Please consider the case of a composite resource: You need to implement
> > __enter__, __exit__ and track the open/closed state at every level in
> > your component hierarchy - even if some levels hold no resources
> > directly.
> > This is burdensome, breaks encapsulation, breaks invariance and is error
> > prone ...very unpythonic.
> 
> Without a more concrete example, I cannot comment on these claims.

Here is an example of a composite resource using RAII:-

class RAIIFileAccess():
def __init__(self, fname):
print("%s Opened" % fname)
def __del__(self):
print("%s Closed" % fname)

class A():
def __init__(self):
self.res = RAIIFileAccess("a") 

class B():
def __init__(self):
self.res = RAIIFileAccess("b")

class C():
def __init__(self):
self.a = A()
self.b = B()
 
def main():
c = C()

Under this PEP this is all that is needed to guarantee that the files "a" 
and "b" are closed on exit from main or after any exception has been handled.

Also note that if you have a reference to these objects then they are 
guaranteed to be in a valid/useable/open state (invariant) - no danger
or need to worry/check about enter/exit state.

Now repeat this example with "with".

> [...]
> > My PEP is about improving the linguistic integrity and fitness for
> > resource management purpose of the language.
> 
> So you claim, but *requiring* reference counting semantics does not 
> improve the integrity or fitness of the language. 

We will just have to disagree on that for now.

> And the required 
> changes to programming styles and practices (no cycles, 

No change required. But if you _choose_ to benefit from RAII you had better 
not create orphan cycles with RAII objects in them, as that 
is clearly a resource leak.

> no globals, 

No change required. But if you _choose_ to benefit from RAII you had better 
take care to delete any RAII resources you choose to hold at global scope in 
a robust way. (These are exceptional in my experience).

> put all resources inside their own scope) 

No change required. But if you _choose_ to benefit from RAII you can make use
of python's existing scopes (functions) or del to restrict resource lifetimes.

> >> In any case, you might not like with statements, but I think they're
> >> infinitely better than:
> >> 
> >> def meaningless_function_that_exists_only_to_manage_resource():
> >> x = open_resource()
> >> process(x)
> > 
> >> def function():
> >> meaningless_function_that_exists_only_to_manage_resource()
> >> sleep(1)  # simulate a long-running function
> > 
> > Why would you prefer a new construct?
> 
> I don't prefer a new construct. The "with" statement isn't "new". It goes 
> back to Python 2.5 (`from __future__ import with_statement`) which is 
> more than eleven years old now. That's about half the lifetime of the 
> language!
> 
> I prefer the with statement because it is *explicit*, simple to use, and 
> clear to read. I can read some code and instantly see that when the with 
> block ends, the resource will be closed, regardless of how many 
> references to the object still exist.
> 
> I don't have to try to predict (guess!) when the last reference will go 
> out of scope, because that's irrelevant.

If you don't care about what the other references might be then 
RAII is not for you. Fine.
 
> RAII conflates the lifetime of the object with the lifetime of the 
> resource held by the object. 

This "conflation" is called "invariance" and is usually considered a 
"very good thing" as you cant have references floating around to
half-baked resources.

> They are not the same, and the object can 
> outlive the resource.

Not with RAII it can't. Simple. Good. 

> Your position is:
> 
> "RAII makes it really elegant to close the file! All you need to do is 
> make sure that when you want to close the file, you delete all the 
> references to the file, so that it goes out of scope, and the file will 
> be closed."
> 
> My position is:
> 
> "If I want to close the file, I'll just close the file. Why should I care 
> that there are zero or one or a million references to it?"

Because if you have no idea what references there are you can not assume it 
is OK to close the file! That would be a truly terrible program design.

> >> - the with block is equivalent to a try...finally, and so it is
> >>   guaranteed to close the resource even if an exception occurs; your
> >>   solution isn't.

It is: RAII will release all resources held, transitively. Try the example
above using CPython and put an exception in one of the constructors. 

> >> If process(x) creates a non-local reference to x, and then raises an
> >> exception, and that exception is caught elsewhere, x will not go out of
> >> scope and won't be closed.
> >> A regression in the reliability of the 

[issue32991] AttributeError in doctest.DocTestFinder.find

[Jason R. Coombs]

Change by Jason R. Coombs :


--
keywords: +patch
pull_requests: +5746
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32984] IDLE: set and unset __file__ for startup files

[Terry J. Reedy]

Terry J. Reedy  added the comment:

With the PR, IDLE behaves the same as Python on Windows.
   .../3x> python -m idlelib -r f:/python/a/tem2.py
(see original post for content of tem2.py)
prints __file__ instead of raising NameError, while
  >>> __file__ continues to raise NameError

Cheryl, I really expect the PR to work on linux, but can you manually test it 
anyway?  If you think the blurb needs rst markup and feel like adding some, go 
ahead.

--
nosy: +csabella
stage: patch review -> needs patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32993] issue30657 Incomplete fix

[yao zhihua]

yao zhihua  added the comment:

Okay my falut.I made the wrong issue.The issue is issue11662.Urlopen function 
can use the file protocol, when an attacker input file:///etc/passwd, it can 
leak the contents of the passwd file.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32993] issue11662 Incomplete fix

[yao zhihua]

Change by yao zhihua :


--
title: issue30657 Incomplete fix -> issue11662 Incomplete fix

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17239] XML vulnerabilities in Python

[Matej Cepl]

Change by Matej Cepl :


--
nosy: +mcepl

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17318] xml.sax and xml.dom fetch DTDs by default

[Matej Cepl]

Change by Matej Cepl :


--
nosy: +mcepl

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: RFC: Proposal: Deterministic Object Destruction

[Ooomzay]

On Monday, 5 March 2018 01:11:43 UTC, Richard Damon  wrote:
> On 3/4/18 6:55 PM, Ned Batchelder wrote:
> > On 3/4/18 5:25 PM, Ooomzay wrote:
> >> On Sunday, 4 March 2018 14:37:30 UTC, Ned Batchelder  wrote:
> >>> Are you including cyclic references in your assertion that CPython
> >>> behaves as you want?
> >> Yes. Because the only behaviour required for RAII is to detect and 
> >> debug such cycles in order to eliminate them. It is a design 
> >> error/resource leak to create an orphan cycle containing RAII objects.
> >>
> >> def main():
> >> gc,disable
> >>
> >>
> >>
> >
> > This isn't a reasonable position.  Cycles exist, and the gc exists for 
> > a reason.  Your proposal isn't going to go anywhere if you just 
> > naively ignore cycles.
> >
> > --Ned.
> 
> While Ooomzay seems to want to say that all cycles are bad, 

I only want to say that orphan cycles with RAII objects in them are bad. 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: RFC: Proposal: Deterministic Object Destruction

[Ben Finney]

Richard Damon  writes:

> […] I can't see any good way to create the equivalent of a 'weak
> reference' (names aren't objects so don't have properties). The  best
> I can think of is to create some sort of magical object that can refer
> to another object, but that reference 'doesn't count'. This seems very
> unPythonic.

Do you mean something like the standard library ‘weakref’ module
?

The weakref module allows the Python programmer to create weak
references to objects.

[…]
A weak reference to an object is not enough to keep the object
alive: when the only remaining references to a referent are weak
references, garbage collection is free to destroy the referent and
reuse its memory for something else. However, until the object is
actually destroyed the weak reference may return the object even if
there are no strong references to it.

-- 
 \   “The cost of education is trivial compared to the cost of |
  `\ ignorance.” —Thomas Jefferson |
_o__)  |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

[issue32871] Interrupt .communicate() on SIGTERM/INT

[Alexey Izbyshev]

Alexey Izbyshev  added the comment:

@ajk225 It may be useful to look at #25942 before working on this.

--
nosy: +izbyshev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32921] .pth files cannot contain folders with utf-8 names

[R. David Murray]

Change by R. David Murray :


--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32973] Importing the same extension module under multiple names breaks non-reinitialisable extension modules

[Thomas Wouters]

Thomas Wouters  added the comment:

Re: Petr: we can't expect extension module authors to retroactively fix 
released modules. We can't even expect everyone to fix this for future 
releases; moving away from globals (which may not be specific to the Python 
extension module) may be a lot of effort. Just look at how much work it's 
taking to move CPython itself to stop using globals in so many places. And 
while it may be necessary for sub-interpreters (which is only the case for 
global state that's Python objects), many people just don't care about 
sub-interpreters.

Re: Stefan: the init function pointer isn't known until much later in the 
current process, and calculated from the module name. There is not currently a 
way to import a module with a different init function pointer. I don't think 
this warrants that much of a rewrite.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32871] Interrupt .communicate() on SIGTERM/INT

[ajk225]

ajk225  added the comment:

Is this still open?  If so, can I take this on as my first issue?

--
nosy: +ajk225

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32984] IDLE: set and unset __file__ for startup files

[Terry J. Reedy]

Change by Terry J. Reedy :


--
keywords: +patch
pull_requests: +5747
stage: needs patch -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: RFC: Proposal: Deterministic Object Destruction

[Ooomzay]

On Saturday, 3 March 2018 17:10:53 UTC, Dietmar Schwertberger  wrote:
> CPython does *not* guarantee destruction when the object reference goes 
> out of scope, even if there are no other references.
> I would very much appreciate such a deterministic behaviour, at least 
> with CPython.
> 
> I recently had to debug an issue in the matplotlib wx backend (*). Under 
> certain conditions, the wx device context was not destroyed when the 
> reference went out of scope. Adding a del to the end of the method or 
> calling the Destroy method of the context did fix the issue. (There was 
> also a hidden reference, but avoiding this was not sufficient. The del 
> was still required.)

You say the reference was out of scope but that a del was still required. What 
were you delling if the reference was out of scope? Could you sketch the code.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: RFC: Proposal: Deterministic Object Destruction

[Mark Lawrence]

On 05/03/18 01:01, Ooomzay wrote:

On Sunday, 4 March 2018 23:57:24 UTC, Mark Lawrence  wrote:

On 04/03/18 02:28, Ooomzay wrote:

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 open until the end of the function?
   
  def fn():

  for i in range(1):
  f = RAIIFile(f"file{i}.txt", "w")
  f.write("Some text")




Over my dead body.


Care to expand on that?



Sure, when you state what you intend doing about reference cycles, which 
you've been asked about countless times.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: RFC: Proposal: Deterministic Object Destruction

[Ooomzay]

On Sunday, 4 March 2018 23:55:33 UTC, Ned Batchelder  wrote:
> On 3/4/18 5:25 PM, Ooomzay wrote:
> > On Sunday, 4 March 2018 14:37:30 UTC, Ned Batchelder  wrote:
> >> Are you including cyclic references in your assertion that CPython
> >> behaves as you want?
> > Yes. Because the only behaviour required for RAII is to detect and debug 
> > such cycles in order to eliminate them. It is a design error/resource leak 
> > to create an orphan cycle containing RAII objects.
> >
> This isn't a reasonable position.  Cycles exist, and the gc exists for a 
> reason.  Your proposal isn't going to go anywhere if you just naively 
> ignore cycles.

I am not naively ignoring them. But _if_ you want to use RAII then do not leak 
them in cycles. Put anything else in there you like and gc them as before.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: RFC: Proposal: Deterministic Object Destruction

[Richard Damon]

On 3/4/18 6:55 PM, Ned Batchelder wrote:

On 3/4/18 5:25 PM, Ooomzay wrote:

On Sunday, 4 March 2018 14:37:30 UTC, Ned Batchelder  wrote:

Are you including cyclic references in your assertion that CPython
behaves as you want?
Yes. Because the only behaviour required for RAII is to detect and 
debug such cycles in order to eliminate them. It is a design 
error/resource leak to create an orphan cycle containing RAII objects.


def main():
gc,disable





This isn't a reasonable position.  Cycles exist, and the gc exists for 
a reason.  Your proposal isn't going to go anywhere if you just 
naively ignore cycles.


--Ned.


While Ooomzay seems to want to say that all cycles are bad, I think it 
is fair to say that in general in Python they are unavoidable, in part 
because I can't see any good way to create the equivalent of a 'weak 
reference' (names aren't objects so don't have properties). The  best I 
can think of is to create some sort of magical object that can refer to 
another object, but that reference 'doesn't count'. This seems very 
unPythonic.


What I think can be said is that it should be possible (enforced by the 
programmer, not the language) to use these RAII objects in ways that 
don't create cycles (or maybe that the program knows of the cycles and 
makes the effort to break them when it is important). So perhaps it can 
be said that cycle that involve major resource RAII objects should exist.


--
Richard Damon

--
https://mail.python.org/mailman/listinfo/python-list

[issue32993] issue11662 Incomplete fix

[yao zhihua]

yao zhihua  added the comment:

I tried again, webbrowser module can only open file:///etc/passwd.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15631] Python 3.3/3.4 installation issue on OpenSUSE lib/lib64 folders

[Matej Cepl]

Change by Matej Cepl :


--
nosy: +mcepl

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31658] xml.sax.parse won't accept path objects

[Matej Cepl]

Change by Matej Cepl :


--
nosy: +mcepl

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32993] issue11662 Incomplete fix

[yao zhihua]

yao zhihua  added the comment:

I also found a function without filtering file protocol.

poc:

import webbrowser
webbrowser.open('file:///etc/passwd')

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32989] IDLE: Fix pyparse.find_good_parse_start and its bad editor call

[Cheryl Sabella]

Cheryl Sabella  added the comment:

> In the meanwhile, to get some idea of how well find_good_parse_start finds 
> good parse starts, I restarted IDLE in a console with the print still added, 
> loaded editor.py, and hit RETURN followed by UNDO, in various places. The 
> first non-zero bod, 812, comes with the cursor at the end of 'def 
> _sphinx_version():'  812 is probably the beginning of the line.  After "if 
> __name__ == '__main__':" near the end, 1416.  After the final 
> "run(_editor_window)", 1654.  The highest value I got in about 10 tries past 
> the middle, 1931.  To me, this is pathetically bad.

Print `startat` too.  `num_context_lines` isn't CodeContext (although I thought 
it was too); that's just unfortunate naming.  `num_context_lines` is just a 
list = [50, 500, 5000]. First it looks at the code going back 50 lines from the 
current line and it only sends the text to `find_good_parse_start()` from this 
line onward.  `bod` is calculated from that point, not from the beginning of 
the file.  Because the start point is always 50 lines back, `bod` seems to 
always be in a similar range once you get to line 50 or higher in the code.

It seems that the purpose of the parsing is to apply the translate, etc to as 
few lines as possible.  So, it tries to make sure it includes the openers (':' 
ending lines) and closers (return, pass, etc) and the beginning of the brackets 
and continuation lines.  The big thing is that it wants to make sure it's not 
in a string or comment.  So, I think the program almost overcompensates for the 
idea of a 'large string'.  It is very complex and very hard to figure out 
exactly what it is trying to accomplish, even with the comments.  Maybe modern 
computing power (compared to 2000) has made it such that translating a whole 
source file is quick enough to not need fancy parsing.  :-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: RFC: Proposal: Deterministic Object Destruction

[Ooomzay]

On Sunday, 4 March 2018 23:57:24 UTC, Mark Lawrence  wrote:
> On 04/03/18 02:28, Ooomzay wrote:
> > 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 open until the end of the function?
> >   
> >  def fn():
> >  for i in range(1):
> >  f = RAIIFile(f"file{i}.txt", "w")
> >  f.write("Some text")
> > 

> Over my dead body.  

Care to expand on that?
-- 
https://mail.python.org/mailman/listinfo/python-list