gzip.GzipFile has no name attribute

[gustaebel]

BPO	1647484
Nosy	@loewis, @gustaebel
Files	gzip-name-attr.diff: patch to Lib/gzip.py

^{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']

[gustaebel]

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]

Seems that nobody is interested. I will check this in in a few days if nobody objects.

[loewis]

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]

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.