Changes by Stepan :
--
files: ident.patch
keywords: patch
nosy: Ma3aXaKa
priority: normal
severity: normal
status: open
title: Identation error
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42832/ident.patch
___
Python
Stepan Wagner added the comment:
Thank you, I wasn't paying attention enough. It works as you describe.
On Tue, Dec 4, 2012 at 9:46 PM, R. David Murray wrote:
>
> R. David Murray added the comment:
>
> The only way I was able to replicate that result was by removing the
&g
Stepan Wagner added the comment:
OK, thanks for explanation.
The behaviour is still strange, because when I delete try...except clause
from wrap, the StopIteration exc from emptygen terminates the program with
traceback.
On Tue, Dec 4, 2012 at 9:14 PM, R. David Murray wrote:
>
> R.
New submission from Stepan Wagner:
def emptygen():
# Or other more meaningful generator
raise StopIteration
yield
def wrap(gen):
next(gen)
print("This should be printed or StopIteration raised.")
while True:
try:
yield next(gen)
Stepan Kasal added the comment:
I'm not sure when I'll get to this, sorry.
Hopefully sometime soon.
--
___
Python tracker
<http://bugs.python.o
Stepan Kasal added the comment:
> but I'm afraid it's impossible to do without performance regression due to
> seek before every read.
I agree that this is key question.
I would hope that the performance hit wouldn't be so bad, unless there are
actually two d
Stepan Kasal added the comment:
Re: children counting
You need to know the number of open children and whether the parent ZipFile
object is still open.
As soon as both all children and the parent ZipFile are closed, the underlying
fp (corresponding to the file name given initially) shall be
Stepan Kasal added the comment:
I agree that reading from a file open for write should be forbidden, no matter
whether ZipFile was called with fp or a name.
Actually, it is not yet forbidden, and two of the tests in the zipfile.py test
suite do actually rely on this misfeature.
The first
Stepan Kasal added the comment:
Attached please find a second iteration of the fix.
This time the signature of ZipExtFile is kept backward compatible, with one new
parameter added.
--
Added file:
http://bugs.python.org/file24624/Proposed-fix-of-issue14099-second.patch
Stepan Kasal added the comment:
Attached please find a patch that fixes this issue by reusing the original fp
from ZipFile object.
Two of the test cases attempted to read a file from a zip as soon as write()
was called. I believe that this is not correct usage: zip file is not even
fully
New submission from Stepan Kasal :
When a file inside a zip is open, the underlying zip file is open again.
(Unless the file name is unknown, because the ZipFile object was created with
fp only.)
This design is incorrect, insecure, and ineffective:
- the reopen uses the same string as file
11 matches
Mail list logo
