Berker Peksag added the comment:
Here is a new patch. I didn't touched provides, requires and obsoletes fields
since they are not used much in the setuptools era.
Distribution.finalize_options() already converts string types to lists for
platforms and keywords fields. I didn't changed that
Serhiy Storchaka added the comment:
I think it should include other list fields if we don't want to open separate
issues for every list field.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19610
Éric Araujo added the comment:
I think classifiers and keywords are the only commonly used fields. This issue
could be limited to classifiers, or also include other list fields.
--
___
Python tracker rep...@bugs.python.org
Serhiy Storchaka added the comment:
What about other list parameters? platform, keywords, provides, requires,
obsoletes?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19610
___
Serhiy Storchaka added the comment:
I don't know in which cases a value should be a (key, value) tuple.
I think this is for field 'content' only.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19610
Éric Araujo added the comment:
I think the change is acceptable.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19610
___
___
Python-bugs-list
Serhiy Storchaka added the comment:
The patch changes this.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19610
___
___
Python-bugs-list
Serhiy Storchaka added the comment:
Does current code work with None or empty tuple?
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19610
___
Berker Peksag added the comment:
Does current code work with None or empty tuple?
Yes, it works with both None and ().
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19610
___
Berker Peksag added the comment:
Updated patch. I've tweaked tests and documentation a bit. Alternatively, I can
leave Doc/distutils/setupscript.rst untouched and add a whatsnew entry to
Doc/whatsnew/3.5.rst.
--
Added file: http://bugs.python.org/file37097/issue19610_v2.diff
Changes by Berker Peksag berker.pek...@gmail.com:
--
assignee: - berker.peksag
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19610
___
___
Berker Peksag added the comment:
A patch to detect bad type for classifiers in the check command would
also be acceptable for 3.5, or to catch it earlier, a check in the
Distribution class.
Thanks for the idea, Éric. New patch attached.
--
stage: needs patch - patch review
versions:
Éric Araujo added the comment:
You seem to misunderstand me Victor: There is no bug here, classifiers should
be a list and are documented as such. It is possible to make this clearer in
the docs for all versions. In addition, we could make this easier for users
who don’t see that part of
Éric Araujo added the comment:
I’m open to a patch that would make it clear in the docs that classifiers must
be a list.
A patch to detect bad type for classifiers in the check command would also be
acceptable for 3.5, or to catch it earlier, a check in the Distribution class.
--
STINNER Victor added the comment:
A patch to detect bad type for classifiers in the check command would also be
acceptable for 3.5, or to catch it earlier, a check in the Distribution class.
Why only in Python 3.5? Does it make sense to pass something different
than a list in older Python
15 matches
Mail list logo
