[Python-Dev] Distutils ML wrap-up: setup.cfg new format
Hello
Here's a wrapup of the Distutils-SIG discussion
we had on the "static metadata" topic.
I realize that it's a good thing to send in.
python-dev such wrapup on distutils design
decisions, to keep everyone informed and get
more feedback when required.
I will try to do it for every upcoming changes
that are not going in a PEP process (when it's not
a 'big' change). The rate of such mails should
not be very high. (around 1 mail in python-dev
for +150 mails in distutils-SIG)
If you feel that what we are about to change in distutils
is wrong, you can go ahead and help us by participating
in Distutils-ML, so we keep one and only one media
for these discussions.
The four sentences summary for people in a hurry:
Getting metadata of a distribution that is not.
installed means running its setup.py. This means.
downloading the whole archive, and running.
third party code on your system.
To avoid it, we are adding a [setup] section in.
setup.cfg where you can express the package metadata
statically.
Conditional sections, specific to some system.
can be added to add some specific fields in [setup].
At the end, you will be able to get metadata fields
without running any third-party code, and possibly
get only the distribution setup.cfg for this.
Now the long version.
Rational
Today, if you want to list all the metadata (PEP 314) of a.
distribution that is not installed, you need to use it's.
setup.py CLI.
So, basically, you download it, and run::
$ python setup.py --name
Foo
$ python setup.py --version
1.2
Where `name` and `version` are metadata fields. That's OK but as.
soon as the developers add more code in setup.py, this feature
might break or (worse) might do unwanted things on the target.
system.
Why should we run third-party code just to get its metadata ?
So we worked on a way to express those metadata statically,
by pushing them in `setup.cfg`. That's not hard, since all.
the metadata fields are static values.
Adding a setup section in setup.cfg
===
So the first thing we want to introduce is a [setup] section,
that may contain any field from the metadata::
[setup]
name: Foo
version: 1.2
Distutils will look for them, and will use them. Of course
setup.py is still required, and in case an option that is.
a metadata field is passed to setup(), it will override one.
located in setup.cfg.
PEP 341 is coming up
Remember the last Pycon Summit ? We said that we would
introduce a new metadata field to describe requirements..
That's basically what PEP 341 is about, and we are still.
working on it.
Basically, we will be able to write things like::
requires: Twisted == 8.2.0
What takes us so long is that adding requirements like
this in the metadata requires more things:
- the ability to compare versions (this was described in.
PEP 386 but not finished yet)
- the ability to make these requirements vary depending on.
the target system
And the later makes our "setup.cfg" new [setup] section.
obsolete as soon as this new metadata field is added in.
Python.
So we need more that what I've shown in the previous section
Context-dependant sections
==
The second change we are going to introduce is context-dependant
sections in setup.cfg.
A context dependant section is a section with a condition that is.
used only if the execution environment meets its condition.
Here's an example::
[setup]
name: Foo
version: 1.3
[setup:sys_platform == 'win32']
requires: pywin32
requires: bar > 1.0
[setup:os_machine == '64bits']
requires: some_package
[setup:python_version == '2.4' or python_version == '2.5']
requires: some_package
Every [setup:condition] section will be added in [setup]
only if the condition is met.
The micro-language behind this is the simplest possible:
it compares only strings, with usual string operators,
and with the ability to combine expressions. It makes it also
easy to understand to non-pythoneers (os packagers).
The pseudo-grammar is (I don't know how to write those but you'll
get it hopefully)::
comp: '<'|'>'|'=='|'>='|'<='|'<>'|'!='|'in'|'not' 'in'
comparison: expr (comp_op expr)*
expr: STRING
test: or_test
or_test: and_test ('or' and_test)*
and_test: not_test ('and' not_test)*
not_test: 'not' not_test | comparison
where STRING belongs to any of those:
- python_version = '%s.%s' % (sys.version_info[0], sys.version_info[1])
- os_name = os.name
- sys_platform = sys.platform
- os_sysname = os.uname()[0].
- os_nodename = os.uname()[1]
- os_release = os.uname()[2].
- os_version = os.uname()[3]..
- os_machine = os.uname()[4].
- a free string, like '2.4', or 'win32'
Distutils will provide a function that is able to read the metadata
of a distribution, given a setup.cfg file, for the target environment::
>>> from distutils.util import loca
Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format
On Tue, Sep 22, 2009 at 03:21:06PM +0200, Tarek Ziad? wrote: > I realize that it's a good thing to send in. > python-dev such wrapup on distutils design > decisions, to keep everyone informed and get > more feedback when required. Sure it is. > I will try to do it for every upcoming changes > that are not going in a PEP process (when it's not > a 'big' change). Thank you! Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[email protected] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format
At 03:21 PM 9/22/2009 +0200, Tarek Ziadé wrote: Hello Here's a wrapup of the Distutils-SIG discussion we had on the "static metadata" topic. I realize that it's a good thing to send in. python-dev such wrapup on distutils design decisions, to keep everyone informed and get more feedback when required The above implies that a consensus was reached on this topic; you should perhaps at least note that in this case it actually means that you just terminated the discussion and pronounced your choice, just as a simpler solution for dynamic dependencies (proposed by Sridhar) was beginning to gain some support. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format
Tarek Ziadé gmail.com> writes: > > [setup] > name: Foo > version: 1.2 I am probably missing something, but why doesn't it use the more common ini-style: [setup] name = Foo version = 1.2 Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format
Antoine Pitrou wrote: Tarek Ziadé gmail.com> writes: [setup] name: Foo version: 1.2 I am probably missing something, but why doesn't it use the more common ini-style: [setup] name = Foo version = 1.2 ConfigParser recognises both, but other tools (*coff* ConfigObj) only recognises the latter (=). Michael Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format
Tarek Ziadé wrote: The four sentences summary for people in a hurry: If you're going to promise sentences, please deliver sentences... Getting metadata of a distribution that is not. installed means running its setup.py. This means. downloading the whole archive, and running. third party code on your system. This is not a sentence, and I have no idea what you're trying to convey... A context dependant section is a section with a condition that is. used only if the execution environment meets its condition. Here's an example:: [setup] name: Foo version: 1.3 [setup:sys_platform == 'win32'] requires: pywin32 requires: bar > 1.0 [setup:os_machine == '64bits'] requires: some_package [setup:python_version == '2.4' or python_version == '2.5'] requires: some_package As was brought up on the distutils list, this seems unnecessarily complicated. Other, simpler, solutions were proposed: http://mail.python.org/pipermail/distutils-sig/2009-September/013173.html http://mail.python.org/pipermail/distutils-sig/2009-September/013289.html However, you pronounced yourself bdfl(!): http://mail.python.org/pipermail/distutils-sig/2009-September/013318.html ...and decided to ignore them. Please don't do this over such an important matter. cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] operator precedence of __eq__, __ne__, etc, if both object have implementations
Hi All, I didn't see any docs on this: http://docs.python.org/reference/datamodel.html?highlight=__eq__#object.__eq__ Where are the specifications on what happens if two objects are compared and both have implementations of __eq__? Which __eq__ is called? What happens if the first one called returns False? Is the second one called? What is one implements __eq__ and the other __ne__? If I've missed something, please point me in the right direction. To all those about to tell me to go read the source: that's not good enough here. I'm hoping there *are* "official" rules for how these interact and they just need better linking in, otherwise, I worry that IronPython could do one thing, Jython another and CPython a third... cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] operator precedence of __eq__, __ne__, etc, if both object have implementations
This might help: http://mail.python.org/pipermail/python-dev/2008-June/080111.html Here is the most relevant part (quoting Guido): > Does it help if I tell you that for "x y" we always try > x.__binop__(y) before trying y.__reverse_binop__(x), *except* in the > case where y is an instance of a subclass of the class of x? jared On Sep 22, 2009, at 7:06 AM, Chris Withers wrote: Hi All, I didn't see any docs on this: http://docs.python.org/reference/datamodel.html?highlight=__eq__#object.__eq__ Where are the specifications on what happens if two objects are compared and both have implementations of __eq__? Which __eq__ is called? What happens if the first one called returns False? Is the second one called? What is one implements __eq__ and the other __ne__? If I've missed something, please point me in the right direction. To all those about to tell me to go read the source: that's not good enough here. I'm hoping there *are* "official" rules for how these interact and they just need better linking in, otherwise, I worry that IronPython could do one thing, Jython another and CPython a third... cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/jflatow%40gmail.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] operator precedence of __eq__, __ne__, etc, if both object have implementations
Jared Flatow wrote: This might help: http://mail.python.org/pipermail/python-dev/2008-June/080111.html Here is the most relevant part (quoting Guido): > Does it help if I tell you that for "x y" we always try > x.__binop__(y) before trying y.__reverse_binop__(x), *except* in the > case where y is an instance of a subclass of the class of x? Okay, but does that count as a pronouncement that should go across all versions and platforms? I believe there are differences between when __eq__ and __ne__ are called between Python 2 and 3, and I don't see any docs on the expected behaviour for python 2, dunno about 3. I'm willing to write these docs, http://docs.python.org/reference/datamodel.html#object.__eq__ feels like the right place, is there anywhere else they should go or be linked to from? Mark Dickinson gave some useful insights into this, and Milko Krachounov provided these useful comparisons on #python: Python 2 http://pastebin.com/f8f19ab3 Python 3 http://pastebin.com/f55e44630 Do they cover it all or has anything been missed? cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] operator precedence of __eq__, __ne__, etc, if both object have implementations
On Tue, Sep 22, 2009 at 3:37 PM, Chris Withers wrote: > Where are the specifications on what happens if two objects are compared and > both have implementations of __eq__? Which __eq__ is called? > What happens if the first one called returns False? Is the second one called? > What is one implements __eq__ and the other __ne__? I (still :-) think this is covered, for Python 2.x at least, by: http://docs.python.org/reference/datamodel.html#coercion-rules Specifically, the bits that say: - For objects x and y, first x.__op__(y) is tried. If this is not implemented or returns NotImplemented, y.__rop__(x) is tried. If this is also not implemented or returns NotImplemented, a TypeError exception is raised. But see the following exception: - Exception to the previous item: if the left operand is an instance of a built-in type or a new-style class, and the right operand is an instance of a proper subclass of that type or class and overrides the base’s __rop__() method, the right operand’s __rop__() method is tried before the left operand’s __op__() method. I agree that having these rules in a section called 'Coercion rules' is a bit confusing. > Python 2 > http://pastebin.com/f8f19ab3 > > Python 3 > http://pastebin.com/f55e44630 The duplicate __eq__ calls in these pastes are disturbing: in short, if A() and B() are new-style classes defining __eq__, it seems that A() == B() ends up calling A.__eq__ twice *and* B.__eq__ twice, in the order A.__eq__, B.__eq__, B.__eq__, A.__eq__. In 3.x, slot_tp_richcompare (in typeobject.c) makes two calls to half_richcompare; I think the second is redundant. The coercion rules are already taken care of in do_richcompare (in object.c). I tried removing the second call to half_richcompare, and the entire test-suite still runs without errors. In 2.x, it's possible that this call is necessary for some bizarre combinations of __cmp__ and __eq__; I haven't tried to get my head around this yet. I'll open an issue for the duplicate __eq__ calls. Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format
On Tue, Sep 22, 2009 at 15:55, Michael Foord wrote: > ConfigParser recognises both, but other tools (*coff* ConfigObj) only > recognises the latter (=). So does Mercurial, BTW, because this aspect of ConfigParser was pretty annoying for some of the stuff we try to do (and not at all obvious to most users, who have never seen anything but = used in config-style files). Cheers, Dirkjan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] operator precedence of __eq__, __ne__, etc, if both object have implementations
On Tue, Sep 22, 2009 at 5:12 PM, Mark Dickinson wrote: > - Exception to the previous item: if the left operand is an instance > of a built-in type or a new-style class, and the right operand is an > instance of a proper subclass of that type or class AND overrides the > base’s __rop__() method, the right operand’s __rop__() method is tried > before the left operand’s __op__() method. The AND above (which I uppercased) is subtle but important. In the "x op y" case with y being of a subclass of the class of x, if there is no class in between x and y (excluding x, including y) that overrides the __rop__ method, then y,__rop__(x) is *not* tried before x.__op__(y). It's easy for other implementations to get this wrong. :) - Willem ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] operator precedence of __eq__, __ne__, etc, if both object have implementations
On Tue, Sep 22, 2009 at 4:12 PM, Mark Dickinson wrote: > I'll open an issue for the duplicate __eq__ calls. http://bugs.python.org/issue6970 Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format
On Tue, Sep 22, 2009 at 4:02 PM, Chris Withers wrote: >> [setup:python_version == '2.4' or python_version == '2.5'] >> requires: some_package > > As was brought up on the distutils list, this seems unnecessarily > complicated. > > Other, simpler, solutions were proposed: > > http://mail.python.org/pipermail/distutils-sig/2009-September/013173.html > > http://mail.python.org/pipermail/distutils-sig/2009-September/013289.html > > However, you pronounced yourself bdfl(!): > > http://mail.python.org/pipermail/distutils-sig/2009-September/013318.html > > ...and decided to ignore them. Please don't do this over such an important > matter. Yes, for the syntax bikeshedding on how conditions should be expressed, I have decided I'll be some kind of distutils dictator to end up the endless discussions on how they should be expressed so we can move on. Tarek ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format
Tarek Ziadé wrote: On Tue, Sep 22, 2009 at 4:02 PM, Chris Withers wrote: [setup:python_version == '2.4' or python_version == '2.5'] requires: some_package As was brought up on the distutils list, this seems unnecessarily complicated. Other, simpler, solutions were proposed: http://mail.python.org/pipermail/distutils-sig/2009-September/013173.html http://mail.python.org/pipermail/distutils-sig/2009-September/013289.html However, you pronounced yourself bdfl(!): http://mail.python.org/pipermail/distutils-sig/2009-September/013318.html ...and decided to ignore them. Please don't do this over such an important matter. Yes, for the syntax bikeshedding on how conditions should be expressed, I have decided I'll be some kind of distutils dictator to end up the endless discussions on how they should be expressed so we can move on. +1 Michael Tarek ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format
2009/9/22 P.J. Eby : > At 03:21 PM 9/22/2009 +0200, Tarek Ziadé wrote: >> >> Hello Here's a wrapup of the Distutils-SIG discussion we had on the >> "static metadata" topic. I realize that it's a good thing to send in. >> python-dev such wrapup on distutils design decisions, to keep everyone >> informed and get more feedback when required > > The above implies that a consensus was reached on this topic; you should > perhaps at least note that in this case it actually means that you just > terminated the discussion and pronounced your choice, just as a simpler > solution for dynamic dependencies (proposed by Sridhar) was beginning to > gain some support. I pronounced my choice on the syntax of the conditions in the setup.cfg file, and the setuptools-like syntax to express them Sridhar presented looked more complex. If you are talking about another solution than using setup.cfg with conditional expressions, please start a new thread that demonstrates how it will work, we all want the best solution of course. Tarek ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format
On Tue, Sep 22, 2009 at 4:02 PM, Dirkjan Ochtman wrote: > On Tue, Sep 22, 2009 at 15:55, Michael Foord > wrote: >> ConfigParser recognises both, but other tools (*coff* ConfigObj) only >> recognises the latter (=). > > So does Mercurial, BTW, because this aspect of ConfigParser was pretty > annoying for some of the stuff we try to do (and not at all obvious to > most users, who have never seen anything but = used in config-style > files). yes, I've just used ConfigParser syntax because that's what Distutils uses. If ':' is deprecated in favor of '=' only, Distutils will be fine with that change. I would be +1 for its deprecation Tarek -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format
On Tue, Sep 22, 2009 at 8:12 PM, Tarek Ziadé wrote: > If you are talking about another solution than using setup.cfg with > conditional > expressions, please start a new thread (in Distutils SIG) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format
-- http://www.ironpythoninaction.com On 22 Sep 2009, at 19:15, Tarek Ziadé wrote: On Tue, Sep 22, 2009 at 4:02 PM, Dirkjan Ochtman wrote: On Tue, Sep 22, 2009 at 15:55, Michael Foord > wrote: ConfigParser recognises both, but other tools (*coff* ConfigObj) only recognises the latter (=). So does Mercurial, BTW, because this aspect of ConfigParser was pretty annoying for some of the stuff we try to do (and not at all obvious to most users, who have never seen anything but = used in config-style files). yes, I've just used ConfigParser syntax because that's what Distutils uses. If ':' is deprecated in favor of '=' only, Distutils will be fine with that change. I would be +1 for its deprecation I don't think : is formally deprecated but = is more common and it would be great if distutils could default to (and document) this syntax. Michael Tarek -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format
At 08:12 PM 9/22/2009 +0200, Tarek Ziadé wrote: If you are talking about another solution than using setup.cfg with conditional expressions, please start a new thread that demonstrates how it will work, we all want the best solution of course. I already did that, on the distutils-sig. Or more precisely, someone else did. I only elaborated on the idea they proposed. (I believe it was Sridhar who first proposed it, but my memory may be incorrect.) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format
Tarek Ziadé wrote: Yes, for the syntax bikeshedding on how conditions should be expressed, I have decided I'll be some kind of distutils dictator to end up the endless discussions on how they should be expressed so we can move on. ...except in this case, spelling is important and I'm far from the only person who would prefer you not to foist an unpalatable mess on the entire python community just because the ideas that other people prefer are not yours. cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format
On Tue, Sep 22, 2009 at 12:51, Chris Withers wrote: > Tarek Ziadé wrote: >> >> Yes, for the syntax bikeshedding on how conditions should be expressed, >> I have decided I'll be some kind of distutils dictator to end up the >> endless discussions >> on how they should be expressed so we can move on. > > ...except in this case, spelling is important and I'm far from the only > person who would prefer you not to foist an unpalatable mess on the entire > python community just because the ideas that other people prefer are not > yours. OK, stop before it gets any nastier as your email already sounds rude, Chris. Since the language summit at PyCon 2009 various committers, including me, have been encouraging Tarek to act as distutils dictator to get things finished as we all know people are prone to bikeshedding that would kill any forward momentum we have towards improving the packaging situation. Since Tarek has been doing the legwork on all of this and continues to be the main contributor/pusher of distutils improvements I see no reason why he should not be able to short-circuit discussions when he sees them as having gone on long enough when he is the one that is going to ultimately end up doing all the coding. I honestly think Tarek listens better than most when it comes to input and tends to be extremely cordial about things. Every decision Tarek makes, just like any decision involving Python made by anyone, is going to upset/alienate/piss off some subset of the Python community. That's just life. If it came down to distutils just sitting there with no improvement or Tarek choosing some syntax for config files that I didn't love, I personally would choose the latter as it's better than nothing and syntax is definitely one place where you can't please everyone. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] operator precedence of __eq__, __ne__, etc, if both object have implementations
Willem wrote: > > It's easy for other implementations to get this wrong. :) For IronPython we wrote a set of tests which go through and define the various operator methods in all sorts of combinations on both new-style and old-style classes as well as subclasses of those classes and then do the comparisons w/ logging. We've got this for both comparisons and the normal binary operators. We've also done it in other areas such as throwing exceptions and other complicated areas. But having the the coercion rules documented still helped a lot (although my recollection is they were only about 95% right). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format
Brett Cannon wrote: OK, stop before it gets any nastier as your email already sounds rude, Chris. Yes, apologies. Since the language summit at PyCon 2009 various committers, including me, have been encouraging Tarek to act as distutils dictator to get things finished as we all know people are prone to bikeshedding that would kill any forward momentum we have towards improving the packaging situation. ...except that this isn't bikeshedding. Use of that term just to stifle productive discussion is also rude. Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format
On Tue, 22 Sep 2009 15:48:08 -0700, Chris Withers wrote: Since the language summit at PyCon 2009 various committers, including me, have been encouraging Tarek to act as distutils dictator to get things finished as we all know people are prone to bikeshedding that would kill any forward momentum we have towards improving the packaging situation. ...except that this isn't bikeshedding. Use of that term just to stifle productive discussion is also rude. As I see it, the choice of syntax *as such* is an issue of bikeshedding except that the choice of one syntax over the another could make it supportive to add an useful feature in setuptools to distutils. For instance, this syntax which I proposed - http://mail.python.org/pipermail/distutils-sig/2009-September/013289.html - will make us think about adding install_requires/extra_requires to distutils *in addition to* the conditional metadata .. rather than inventing a new syntax to support only conditional metadata. -srid ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] how to properly object to something (was: Distutils ML wrap-up: setup.cfg new format)
2009/9/22 Chris Withers : > Brett Cannon wrote: >> >> OK, stop before it gets any nastier as your email already sounds rude, >> Chris. > > Yes, apologies. Thanks. > >> Since the language summit at PyCon 2009 various committers, including >> me, have been encouraging Tarek to act as distutils dictator to get >> things finished as we all know people are prone to bikeshedding that >> would kill any forward momentum we have towards improving the >> packaging situation. > > ...except that this isn't bikeshedding. Use of that term just to stifle > productive discussion is also rude. This sounds like a differing of opinion; Tarek doesn't think it's critical, you do. Obviously that changes what the two of you view as bikeshedding on this topic. I also just checked the thread based on the link you and Sridhar sent and I didn't see anyone publicly say they preferred Sridhar's version. If people preferred Sridhar's version they should have spoken up. While Sridhar's email came in Friday and Tarek pronounced Saturday (as a reply to one of Sridhar's emails to his idea), that doesn't mean no one could have spoken up over the the past three days in support of Sridhar's idea if they preferred it regardless of what Tarek decided; no code has been committed so decisions can be changed (gods know plenty of people have said after Guido has pronounced "I disagree" and no one has ever taken offense). So I don't think it's fair to claim that Tarek is not listening considering his pronouncement was in reply to one of the proposals you said he was ignoring. In other words, Chris, you brought up objections to Tarek's decision claiming he was ignoring two full days after he made it, and used as support at least one email which no one publicly showed support for and for which Tarek indirectly replied to when he made his decision. So I see no evidence that Tarek is ignoring people's input from where I stand. If you didn't like Tarek's final decision or preferred Sridhar's idea then you should have replied to one of those emails with at least a vote of +1/+0/-0/-1 over on the distutils-SIG, not here. As of right now this feels like an end-run around Tarek using extremely weak evidence which, in my opinion, is bikeshedding. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] unsubscriptable vs object does not support indexing
Is there a reason or a rule by which CPython reports different error message for different failures to subscript? For example: >>> set()[2] Traceback (most recent call last): File "", line 1, in TypeError: 'set' object does not support indexing >>> class c(object): pass ... >>> c()[2] Traceback (most recent call last): File "", line 1, in TypeError: 'c' object does not support indexing But compare this to: >>> [].append[42] Traceback (most recent call last): File "", line 1, in TypeError: 'builtin_function_or_method' object is unsubscriptable >>> (lambda: 42)[42] Traceback (most recent call last): File "", line 1, in TypeError: 'function' object is unsubscriptable >>> property()[42] Traceback (most recent call last): File "", line 1, in TypeError: 'property' object is unsubscriptable IronPython had a bug report that we were getting this wrong for set objects and that "does not support indexing" was also a clearer error message. I'm wondering if there's some reason why the different error messages occur which I'm missing. Otherwise I could switch to using the more clear message or start marking types which should report the unsubscriptable error. Does anyone have any insights into this? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format
Tarek,
Are you claiming this as your own work and ideas?
Given:
http://mail.python.org/pipermail/distutils-sig/2009-August/012998.html
Regards
David
On Tue, 22 Sep 2009 15:21:06 +0200, Tarek Ziadé
wrote:
> Hello
>
> Here's a wrapup of the Distutils-SIG discussion
> we had on the "static metadata" topic.
>
> I realize that it's a good thing to send in.
> python-dev such wrapup on distutils design
> decisions, to keep everyone informed and get
> more feedback when required.
>
> I will try to do it for every upcoming changes
> that are not going in a PEP process (when it's not
> a 'big' change). The rate of such mails should
> not be very high. (around 1 mail in python-dev
> for +150 mails in distutils-SIG)
>
> If you feel that what we are about to change in distutils
> is wrong, you can go ahead and help us by participating
> in Distutils-ML, so we keep one and only one media
> for these discussions.
>
> The four sentences summary for people in a hurry:
>
> Getting metadata of a distribution that is not.
> installed means running its setup.py. This means.
> downloading the whole archive, and running.
> third party code on your system.
>
> To avoid it, we are adding a [setup] section in.
> setup.cfg where you can express the package metadata
> statically.
>
> Conditional sections, specific to some system.
> can be added to add some specific fields in [setup].
>
> At the end, you will be able to get metadata fields
> without running any third-party code, and possibly
> get only the distribution setup.cfg for this.
>
> Now the long version.
>
>
> Rational
>
>
> Today, if you want to list all the metadata (PEP 314) of a.
> distribution that is not installed, you need to use it's.
> setup.py CLI.
>
> So, basically, you download it, and run::
>
> $ python setup.py --name
> Foo
>
> $ python setup.py --version
> 1.2
>
> Where `name` and `version` are metadata fields. That's OK but as.
> soon as the developers add more code in setup.py, this feature
> might break or (worse) might do unwanted things on the target.
> system.
>
> Why should we run third-party code just to get its metadata ?
>
> So we worked on a way to express those metadata statically,
> by pushing them in `setup.cfg`. That's not hard, since all.
> the metadata fields are static values.
>
> Adding a setup section in setup.cfg
> ===
>
> So the first thing we want to introduce is a [setup] section,
> that may contain any field from the metadata::
>
> [setup]
> name: Foo
> version: 1.2
>
> Distutils will look for them, and will use them. Of course
> setup.py is still required, and in case an option that is.
> a metadata field is passed to setup(), it will override one.
> located in setup.cfg.
>
> PEP 341 is coming up
>
>
> Remember the last Pycon Summit ? We said that we would
> introduce a new metadata field to describe requirements..
> That's basically what PEP 341 is about, and we are still.
> working on it.
>
> Basically, we will be able to write things like::
>
> requires: Twisted == 8.2.0
>
> What takes us so long is that adding requirements like
> this in the metadata requires more things:
>
> - the ability to compare versions (this was described in.
> PEP 386 but not finished yet)
>
> - the ability to make these requirements vary depending on.
> the target system
>
> And the later makes our "setup.cfg" new [setup] section.
> obsolete as soon as this new metadata field is added in.
> Python.
>
> So we need more that what I've shown in the previous section
>
> Context-dependant sections
> ==
>
> The second change we are going to introduce is context-dependant
> sections in setup.cfg.
>
> A context dependant section is a section with a condition that is.
> used only if the execution environment meets its condition.
>
> Here's an example::
>
> [setup]
> name: Foo
> version: 1.3
>
> [setup:sys_platform == 'win32']
> requires: pywin32
> requires: bar > 1.0
>
> [setup:os_machine == '64bits']
> requires: some_package
>
> [setup:python_version == '2.4' or python_version == '2.5']
> requires: some_package
>
>
> Every [setup:condition] section will be added in [setup]
> only if the condition is met.
>
> The micro-language behind this is the simplest possible:
> it compares only strings, with usual string operators,
> and with the ability to combine expressions. It makes it also
> easy to understand to non-pythoneers (os packagers).
>
> The pseudo-grammar is (I don't know how to write those but you'll
> get it hopefully)::
>
> comp: '<'|'>'|'=='|'>='|'<='|'<>'|'!='|'in'|'not' 'in'
> comparison: expr (comp_op expr)*
> expr: STRING
> test: or_test
> or_test: and_test ('or' and_test)*
> and_test: not_test ('and' not_test)*
> not_test: 'not' not_test | comparison
>
> where ST
Re: [Python-Dev] operator precedence of __eq__, __ne__, etc, if both object have implementations
On Tue, Sep 22, 2009 at 5:55 PM, Dino Viehland wrote: > For IronPython we wrote a set of tests which go through and define > the various operator methods in all sorts of combinations on both > new-style and old-style classes as well as subclasses of those classes > and then do the comparisons w/ logging. We've talked about this before, but now I'm reminded again -- do you happen to have a pointer to these tests just in case someone might want to grab them :) ? -Frank ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unsubscriptable vs object does not support indexing
Dino Viehland wrote: Is there a reason or a rule by which CPython reports different error message for different failures to subscript? For example: >>> set()[2] Traceback (most recent call last): File "", line 1, in TypeError: 'set' object does not support indexing >>> class c(object): pass ... >>> c()[2] Traceback (most recent call last): File "", line 1, in TypeError: 'c' object does not support indexing But compare this to: >>> [].append[42] Traceback (most recent call last): File "", line 1, in TypeError: 'builtin_function_or_method' object is unsubscriptable >>> (lambda: 42)[42] Traceback (most recent call last): File "", line 1, in TypeError: 'function' object is unsubscriptable >>> property()[42] Traceback (most recent call last): File "", line 1, in TypeError: 'property' object is unsubscriptable IronPython had a bug report that we were getting this wrong for set objects and that “does not support indexing” was also a clearer error message. I’m wondering if there’s some reason why the different error messages occur which I’m missing. Otherwise I could switch to using the more clear message or start marking types which should report the unsubscriptable error. Does anyone have any insights into this? I thought that the difference might be between iterable and non-iterable objects, but then I'd expect the class 'c' to behave like the other non-iterables. In fact, the result is different again if it's an old-style class: >>> class c: pass >>> c()[2] Traceback (most recent call last): File "", line 1, in c()[2] AttributeError: c instance has no attribute '__getitem__' ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] operator precedence of __eq__, __ne__, etc, if both object have implementations
Frank wrote: > > For IronPython we wrote a set of tests which go through and define > > the various operator methods in all sorts of combinations on both > > new-style and old-style classes as well as subclasses of those > classes > > and then do the comparisons w/ logging. > We've talked about this before, but now I'm reminded again -- do you > happen to have a pointer to these tests just in case someone might > want to grab them :) ? > We include them in the source distribution which you can download the 2.6RC1 release which just came out today here: http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=30315#DownloadId=84669 All of the side-by-side tests are in: IronPython-2.6\Src\Tests\compat Or you can view the source via the web at: http://ironpython.codeplex.com/SourceControl/ListDownloadableCommits.aspx (this page also has instructions for Subversion and other source control clients) And the latest version there is in: IronPython_Main\Src\Tests\compat Hopefully the infrastructure will just work on Jython because it also runs on CPython but there may be some Windows specific code in there (e.g. import nt, a general problem w/ our tests from the days before we always ran tests w/ the CPython std lib present). If you run into any problems let me know and I'd be happy to fix it to make them more compatible. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format
David, Isn't it clear from Tarek's email that he is summarizing distutils-sig? Isn't it odd that you ask this question pointing to your own message? Are you worried that you won't get credit for the idea (assuming it's yours)? Should you perhaps just ask for credit instead of asking a rhetorical question? --Guido On Tue, Sep 22, 2009 at 5:07 PM, David Lyon wrote: > > Tarek, > > Are you claiming this as your own work and ideas? > > Given: > > http://mail.python.org/pipermail/distutils-sig/2009-August/012998.html > > Regards > > David > > > On Tue, 22 Sep 2009 15:21:06 +0200, Tarek Ziadé > wrote: >> Hello >> >> Here's a wrapup of the Distutils-SIG discussion >> we had on the "static metadata" topic. >> >> I realize that it's a good thing to send in. >> python-dev such wrapup on distutils design >> decisions, to keep everyone informed and get >> more feedback when required. >> >> I will try to do it for every upcoming changes >> that are not going in a PEP process (when it's not >> a 'big' change). The rate of such mails should >> not be very high. (around 1 mail in python-dev >> for +150 mails in distutils-SIG) >> >> If you feel that what we are about to change in distutils >> is wrong, you can go ahead and help us by participating >> in Distutils-ML, so we keep one and only one media >> for these discussions. >> >> The four sentences summary for people in a hurry: >> >> Getting metadata of a distribution that is not. >> installed means running its setup.py. This means. >> downloading the whole archive, and running. >> third party code on your system. >> >> To avoid it, we are adding a [setup] section in. >> setup.cfg where you can express the package metadata >> statically. >> >> Conditional sections, specific to some system. >> can be added to add some specific fields in [setup]. >> >> At the end, you will be able to get metadata fields >> without running any third-party code, and possibly >> get only the distribution setup.cfg for this. >> >> Now the long version. >> >> >> Rational >> >> >> Today, if you want to list all the metadata (PEP 314) of a. >> distribution that is not installed, you need to use it's. >> setup.py CLI. >> >> So, basically, you download it, and run:: >> >> $ python setup.py --name >> Foo >> >> $ python setup.py --version >> 1.2 >> >> Where `name` and `version` are metadata fields. That's OK but as. >> soon as the developers add more code in setup.py, this feature >> might break or (worse) might do unwanted things on the target. >> system. >> >> Why should we run third-party code just to get its metadata ? >> >> So we worked on a way to express those metadata statically, >> by pushing them in `setup.cfg`. That's not hard, since all. >> the metadata fields are static values. >> >> Adding a setup section in setup.cfg >> === >> >> So the first thing we want to introduce is a [setup] section, >> that may contain any field from the metadata:: >> >> [setup] >> name: Foo >> version: 1.2 >> >> Distutils will look for them, and will use them. Of course >> setup.py is still required, and in case an option that is. >> a metadata field is passed to setup(), it will override one. >> located in setup.cfg. >> >> PEP 341 is coming up >> >> >> Remember the last Pycon Summit ? We said that we would >> introduce a new metadata field to describe requirements.. >> That's basically what PEP 341 is about, and we are still. >> working on it. >> >> Basically, we will be able to write things like:: >> >> requires: Twisted == 8.2.0 >> >> What takes us so long is that adding requirements like >> this in the metadata requires more things: >> >> - the ability to compare versions (this was described in. >> PEP 386 but not finished yet) >> >> - the ability to make these requirements vary depending on. >> the target system >> >> And the later makes our "setup.cfg" new [setup] section. >> obsolete as soon as this new metadata field is added in. >> Python. >> >> So we need more that what I've shown in the previous section >> >> Context-dependant sections >> == >> >> The second change we are going to introduce is context-dependant >> sections in setup.cfg. >> >> A context dependant section is a section with a condition that is. >> used only if the execution environment meets its condition. >> >> Here's an example:: >> >> [setup] >> name: Foo >> version: 1.3 >> >> [setup:sys_platform == 'win32'] >> requires: pywin32 >> requires: bar > 1.0 >> >> [setup:os_machine == '64bits'] >> requires: some_package >> >> [setup:python_version == '2.4' or python_version == '2.5'] >> requires: some_package >> >> >> Every [setup:condition] section will be added in [setup] >> only if the condition is met. >> >> The micro-language behind this is the simplest possible: >> it compares only strings, with usual string operators, >>
Re: [Python-Dev] unsubscriptable vs object does not support indexing
On Wed, 23 Sep 2009 at 02:01, MRAB wrote: Dino Viehland wrote: Is there a reason or a rule by which CPython reports different error message for different failures to subscript? For example: > > > set()[2] Traceback (most recent call last): File "", line 1, in TypeError: 'set' object does not support indexing > > > class c(object): pass ... [] > > > [].append[42] Traceback (most recent call last): File "", line 1, in TypeError: 'builtin_function_or_method' object is unsubscriptable [...] IronPython had a bug report that we were getting this wrong for set objects and that ?does not support indexing? was also a clearer error message. I?m wondering if there?s some reason why the different error messages occur which I?m missing. Otherwise I could switch to using the more clear message or start marking types which should report the unsubscriptable error. Does anyone have any insights into this? I thought that the difference might be between iterable and non-iterable objects, but then I'd expect the class 'c' to behave like the other non-iterables. In fact, the result is different again if it's an old-style class: > > class c: pass > > c()[2] Traceback (most recent call last): File "", line 1, in c()[2] AttributeError: c instance has no attribute '__getitem__' Looking at the source, these messages are generated from abstract.c, and the difference appears to be whether or not the tp_as_sequence slot is filled in or not. If it is, but there is no sq_item method, then PySequence_GetItem gives the "does not support indexing" message. If it isn't filled in, you get the 'not subscriptable"(*) message from PyObject_GetItem. The logic appears to be, roughly, if an object does not have mapping methods, or has them but does not have mp_subscript, and does have sequence methods but does not have sq_item, then you get a 'does not support indexing'. Otherwise you get 'not subscriptable'. The question is, is this a useful distinction, or is it an implementation artifact? --David (*) The error message changed format slightly in 2.7 due to http://bugs.python.org/issue5760, and the discussion there is worth reading in this context.___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format
Hello Guido, > Isn't it clear from Tarek's email that he is summarizing > distutils-sig? Well, I'm new to this. Summarising is a word that could be certainly applied. > Isn't it odd that you ask this question pointing to > your own message? It's not odd at all. When I see my ideas, which Tarek originally argued against, published with his name on them, and my name left out, I just felt it fair to myself to ask him how that might have happened. > Are you worried that you won't get credit for the > idea (assuming it's yours)? As I said, I'm new. I've been very happy to help out. This is all a learning process for me. I can accept whatever decision Tarek makes on distutils and the direction of the code. If he chose to ignore my postings and go a different way from what I suggested then that is his perogative. If the failing was on my part to not fully write up PEPS and do full examples, and diagrams and so forth, then I accept that. > Should you perhaps just ask for credit instead of asking a > rhetorical question? I don't really believe that the work is complete enough for anybody to claim credit for just yet. That's why I was surprised to see the announcement. Hence me asking about it. In all fairness, I'm trying to help Tarek here. And the python packaging effort. Getting my name on what I believe are my contributions shouldn't be such a big deal and I'm very sure you'd agree on that. But it is an ongoing struggle for whatever reason that I've been having. I'm sure your guidance can resolve the issues easily.. David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unsubscriptable vs object does not support indexing
R. David Murray wrote: > Looking at the source, these messages are generated from abstract.c, > and the difference appears to be whether or not the tp_as_sequence slot > is filled in or not. If it is, but there is no sq_item method, then > PySequence_GetItem gives the "does not support indexing" message. > If it isn't filled in, you get the 'not subscriptable"(*) message from > PyObject_GetItem. > > The logic appears to be, roughly, if an object does not have mapping > methods, or has them but does not have mp_subscript, and does have > sequence methods but does not have sq_item, then you get a 'does not > support indexing'. Otherwise you get 'not subscriptable'. > > The question is, is this a useful distinction, or is it an > implementation artifact? First on the useful distinction: for better or worse users do seem to have an affinity towards CPython's error messages and especially so when they're better than ours :). But I certainly hope no one is taking a dependency on them by parsing them or anything like that such that it would actually break someone's program. So basically I regard all error messages as implementation artifacts but I have no problem matching them if it'll make someone happier and it's not too crazy to do it. That being said there does seem to be a useful distinction here. It sounds like the idea here is to report a better error message when something is more collection like than a full blown sequence - in particular I'm thinking of .NET's ICollection and Java's Collection interfaces that are very sequence like but don't support getting elements by index. The only oddity in the error message to me is that user defined objects are effectively always treated as sequences. That's completely an implementation artifact but I'm going to copy it too because it's easy, may prevent another bug report, and checking for all the various sequence methods seems like unnecessary overkill. Thanks for the information! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] operator precedence of __eq__, __ne__, etc, if both object have implementations
Willem Broekema wrote: The AND above (which I uppercased) is subtle but important. In the "x op y" case with y being of a subclass of the class of x, if there is no class in between x and y (excluding x, including y) that overrides the __rop__ method, then y,__rop__(x) is *not* tried before x.__op__(y). How does this work at the C typeslot level, where there are no __rop__ methods? -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format
On Tue, Sep 22, 2009 at 20:55, David Lyon wrote: > > Hello Guido, > >> Isn't it clear from Tarek's email that he is summarizing >> distutils-sig? > > Well, I'm new to this. Summarising is a word that could be > certainly applied. > >> Isn't it odd that you ask this question pointing to >> your own message? > > It's not odd at all. When I see my ideas, which Tarek originally > argued against, published with his name on them, and my name left > out, I just felt it fair to myself to ask him how that might have > happened. > >> Are you worried that you won't get credit for the >> idea (assuming it's yours)? > > As I said, I'm new. I've been very happy to help out. This is > all a learning process for me. > > I can accept whatever decision Tarek makes on distutils and the > direction of the code. If he chose to ignore my postings and > go a different way from what I suggested then that is his > perogative. > > If the failing was on my part to not fully write up PEPS and > do full examples, and diagrams and so forth, then I accept that. > >> Should you perhaps just ask for credit instead of asking a >> rhetorical question? > > I don't really believe that the work is complete enough for > anybody to claim credit for just yet. That's why I was surprised > to see the announcement. Hence me asking about it. > > In all fairness, I'm trying to help Tarek here. And the python > packaging effort. > > Getting my name on what I believe are my contributions shouldn't > be such a big deal and I'm very sure you'd agree on that. But it > is an ongoing struggle for whatever reason that I've been having. > > I'm sure your guidance can resolve the issues easily.. If you re-read Tarek's email is uses "we" throughout the entire discussion, only using "I" when referring to the email itself. I don't think anyone on python-dev thought that it was exclusively Tarek's idea or necessarily even mostly his. Personally I just attribute the idea to the distutils-SIG and don't think beyond that. If you want explicit credit, you can co-author a PEP or get thanked in a checkin as you mentioned. But honestly, from my observations of open source, ideas are not what get you noticed, it's producing something tangible like code. Plus ideas and such pull from so many people on mailing lists you can claim you came up with the initial idea, but I am sure a ton of people provided feedback which makes ownership of any idea practically moot. Trust me, if you are doing open source for anything other than altruistic reasons you are bound to be disappointed. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format
On Tue, 22 Sep 2009 22:39:04 -0700, Brett Cannon wrote: > I don't think anyone on python-dev thought that it was exclusively Tarek's > idea or necessarily even mostly his. Actually, he originally argued against it, but that is irrelevant. I'm happy that he's come around and embraced it. Perhaps a bit too much could be my issue. > If you want explicit credit, you can co-author a PEP or get thanked in > a checkin as you mentioned. Good idea. How can I get check-in privileges on distutils ? What is the process? > But honestly, from my observations of open > source, ideas are not what get you noticed, it's producing something > tangible like code. Sure.. you're 100% right. So I need to be able to work on code and be able to check it in. I would love that. How do I get that? > Plus ideas and such pull from so many people on > mailing lists you can claim you came up with the initial idea, but I > am sure a ton of people provided feedback which makes ownership of any > idea practically moot. Claiming ownership? No No. Lets not go there. A worklist and checkin rights would completely suffice. David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format
On Tue, Sep 22, 2009 at 23:20, David Lyon wrote: > On Tue, 22 Sep 2009 22:39:04 -0700, Brett Cannon wrote: >> I don't think anyone on python-dev thought that it was exclusively > Tarek's >> idea or necessarily even mostly his. > > Actually, he originally argued against it, but that is irrelevant. > > I'm happy that he's come around and embraced it. Perhaps a bit too > much could be my issue. > >> If you want explicit credit, you can co-author a PEP or get thanked in >> a checkin as you mentioned. > > Good idea. > > How can I get check-in privileges on distutils ? What is the process? > Contribute patches on the Python issue tracker for six months to a year (depends on how much you contribute) and be generally liked by other committers. Distutils is not separate from Python itself. But notice I said being thanked in a checkin, not making a checkin yourself. >> But honestly, from my observations of open >> source, ideas are not what get you noticed, it's producing something >> tangible like code. > > Sure.. you're 100% right. So I need to be able to work on code and > be able to check it in. I would love that. How do I get that? > You are conflating contributing code and checking it in. You can do the former without the latter. >> Plus ideas and such pull from so many people on >> mailing lists you can claim you came up with the initial idea, but I >> am sure a ton of people provided feedback which makes ownership of any >> idea practically moot. > > Claiming ownership? No No. Lets not go there. > > A worklist and checkin rights would completely suffice. Talk to Tarek or look at bugs.python.org for a worklist; checkin rights come MUCH later. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format
Brett Cannon writes: > OK, stop before it gets any nastier as your email already sounds > rude Rude, yes, but not entirely lacking in truth. Tarek's post to Python- Dev *is* a mess from the point of view of English and organization -- it's *way* below Tarek's normal command of the language. Granted, something that complex is much harder to polish than a 3-sentence post, but it could have been run by a native speaker before posting. Better yet, it could have been run by Distutils-SIG first. At the very least, that would have kept this discussion on Distutils- SIG, and Chris couldn't be accused of trying to make an end run around that process. I suggest that posting progress reports to Python-Dev is a good idea (attracting attention and maybe participation to the process), but making one an opportunity to test the degree of internal consensus (or lack of it) on Distutils-SIG by posting there first is an even better one. > I see no reason why [Tarek] should not be able to short-circuit > discussions when he sees them as having gone on long enough when he > is the one that is going to ultimately end up doing all the coding. Of course there are benefits to having a strong impartial chairman, and installing a benevolent dictator is often a second-best strategy for project management. However, in this case, the question of what is being short-circuited is important. If it's bikeshedding, that's good. If it's a substantial difference, it's not. And it matters, because the benefits of a New! Improved! distutils! really start piling up when adoption becomes nearly universal. How do you tell the difference? Simple. If Philip wants the bikeshed painted pink, but he'll still move his bike to Tarek's blue bikeshed from the existing pink one, further discussion at this point is bikeshedding. If Chris wants the new bikeshed painted chartreuse, and he'll keep parking in the existing green one if Tarek paints the new one blue, that's a real difference. (This assumes Chris represents a sizable group of users/projects, of course.) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
