Repository navigation
gzip.GzipFile has no name attribute #44518
Description
| BPO | 1647484 |
|---|---|
| Nosy | @loewis, @gustaebel |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2007-02-13.16:36:56.000>
created_at = <Date 2007-01-29.22:25:21.000>
labels = ['library']
title = 'gzip.GzipFile has no name attribute'
updated_at = <Date 2007-02-13.16:36:56.000>
user = 'https://github.com/gustaebel'bugs.python.org fields:
activity = <Date 2007-02-13.16:36:56.000>
actor = 'lars.gustaebel'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2007-01-29.22:25:21.000>
creator = 'lars.gustaebel'
dependencies = []
files = ['7743']
hgrepos = []
issue_num = 1647484
keywords = ['patch']
message_count = 4.0
messages = ['51811', '51812', '51813', '51814']
nosy_count = 2.0
nosy_names = ['loewis', 'lars.gustaebel']
pr_nums = []
priority = 'normal'
resolution = 'accepted'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1647484'
versions = ['Python 2.6']
Activity
gustaebel commented on Jan 29, 2007
The gzip.GzipFile object uses a filename instead of a name attribute. This deviates from the standard practice and the interface described in "3.9 File Objects" and seems unnecessary.
Attached patch changes this but still leaves the filename attribute as a property that emits a DeprecationWarning.
gustaebel commented on Feb 12, 2007
Seems that nobody is interested. I will check this in in a few days if nobody objects.
loewis commented on Feb 13, 2007
I think the patch is fine. It is debatable whether this should be backported to 2.5; I think it is better to not backport it.
Please also add a test case testing for the presence of the name attribute (feel free to name it test_1647484)
gustaebel commented on Feb 13, 2007
When I wrote the test I saw that in write mode a '.gz' extension is automatically added to the filename if it has none. However this is stripped again when the name is written to the gzip header. I removed this so that the name attribute always reflects the real filesystem name. The filename property imitates the old behaviour.
I don't think that this should necessarily be backported, at least I don't need it ;-)
Applied in rev. 53772.