On Thu, Sep 24, 2009 at 12:23:31AM -0400, David Lyon wrote:
> On Wed, 23 Sep 2009 15:13:55 -, exar...@twistedmatrix.com wrote:
>
> > I would also personally recommend that this person first (well, after
> > tracking down all the slave operators and convincing them to bring their
> > slaves b
On Wed, 23 Sep 2009 15:13:55 -, exar...@twistedmatrix.com wrote:
> Quite a few years of experience with a distributed team of build slave
> managers has shown me that by far the most reliable way to keep slaves
> online is to have them managed by a dedicated team. This team doesn't
> need t
At 07:05 PM 9/23/2009 -0700, Guido van Rossum wrote:
On Wed, Sep 23, 2009 at 6:57 PM, P.J. Eby wrote:
> Once again, I'd like for the badgering to stop. Thanks.
Tarek already agreed to that ("Fine with me. Let's move forward"). I
hope you will stop badgering him too.
The only reason I said "o
Antoine Pitrou wrote:
> As far as I'm concerned, anything which looks intuitive enough (e.g.
> ini-style)
> and not overly complicated is fine. The details of the syntax aren't really
> important as long as they make sense, and don't get in the way.
One small comment before all this goes back to
Antoine Pitrou wrote:
> As far as I'm concerned, anything which looks intuitive enough (e.g.
> ini-style)
> and not overly complicated is fine. The details of the syntax aren't really
> important as long as they make sense, and don't get in the way.
One small comment before all this goes back to
Mark Dickinson wrote:
> On Wed, Sep 23, 2009 at 4:54 PM, Dino Viehland wrote:
>> We are going to start contributing tests back real soon now. I'm not sure
>> that these are the best tests to contribute as they require a version of
>> Python to compare against rather than being nice and stand alon
On Wed, Sep 23, 2009 at 6:57 PM, P.J. Eby wrote:
> Once again, I'd like for the badgering to stop. Thanks.
Tarek already agreed to that ("Fine with me. Let's move forward"). I
hope you will stop badgering him too.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Brett Cannon wrote:
> So +0 on your specific improvment and +1 for trying to think about
> newbies when writing exception messages.
The __eq__/__hash__ messages are somewhat arcane because the problem
they're describing is somewhat arcane.
Michael's suggested improvement also isn't quite right (a
On Wed, Sep 23, 2009 at 5:44 PM, Greg Ewing wrote:
> Nick Coghlan wrote:
>
>> The interpreter doesn't promise to call those slots with "self" first -
>> self will be the second argument in the "rop" case.
>
> I know. My question is: How does it know whether a subclass
> "has overridden __rop__" wh
At 12:40 AM 9/24/2009 +0200, Tarek Ziadé wrote:
Come on phillip, no one is "plotting" against you.
Perhaps this is a language issue. When I said, "if Tarek is too busy
projecting hidden plots onto everything I say and do," I meant that
you were acting as if I were plotting against *you*, not
Eric Smith wrote:
>> From Trent on the snakebite mailing list. Too late for me to look it
>> up though; an exercise I leave to the reader.
>
> http://groups.google.com/group/snakebite-list/browse_thread/thread/d08642261f2cc502
Hmm, I thought I was subscribed to the snakebite list... guess I will
Ben Finney wrote:
It's a single operation as far as the parser is concerned, so there
needs to be a single term for it. That term is “subscript”.
How about something like "does not support the [] operation".
This refers directly to the syntax involved, rather than
using a typographical term t
Nick Coghlan wrote:
The interpreter doesn't promise to call those slots with "self" first -
self will be the second argument in the "rop" case.
I know. My question is: How does it know whether a subclass
"has overridden __rop__" when there is no concept of an
__rop__ method distinct from the _
Chris Withers wrote:
But this isn't coercion! :-)
The raisin is probably hysterical. Once upon a time, Python
had a __coerce__ special method that took care of things
like this in a different (and inferior) way. It gradually
got replaced by the current scheme, but nobody changed the
section he
On Wed, Sep 23, 2009 at 5:25 PM, Antoine Pitrou wrote:
> MRAB mrabarnett.plus.com> writes:
>>
>> It's called a 'subscript' because conventional mathematical notation
>> uses subscripting. Newbies might be acquainted with the term 'index'
>> from books, where the 'value' is non-numeric. It's a bit
MRAB mrabarnett.plus.com> writes:
>
> It's called a 'subscript' because conventional mathematical notation
> uses subscripting. Newbies might be acquainted with the term 'index'
> from books, where the 'value' is non-numeric. It's a bit unfortunate
> that dicts have keys+value instead of index+va
Ben Finney wrote:
Steven D'Aprano writes:
As far as I can see, in practice, people talk about obj[i] as the item
at index i, not the item at subscript i -- the term "subscript" in
this context seems to be rare to non-existent except for the error
message.
Presumably, the same people would al
Janzert wrote:
Steven D'Aprano wrote:
On Thu, 24 Sep 2009 06:47:41 am Dino Viehland wrote:
So I am +1 on unified the message and +1 on using the "does not
support indexing" one.
I'd be +1 on the unified message as well - but it seems what that
message should be may be contentious (and quite a
Michael Foord wrote:
Benjamin Peterson wrote:
2009/9/23 Michael Foord :
Benjamin Peterson wrote:
2009/9/23 Michael Foord :
Isn't that the real compatibility test *anyway* - how successful a new
version of Python is at running all the existing Python code...
Yes, but we
Steven D'Aprano writes:
> As far as I can see, in practice, people talk about obj[i] as the item
> at index i, not the item at subscript i -- the term "subscript" in
> this context seems to be rare to non-existent except for the error
> message.
Presumably, the same people would also call ‘obj[i
On Wed, 23 Sep 2009 09:49:16 +0200, "M.-A. Lemburg" wrote:
> While it's a good idea to put up some form of meta-data
> into an index, I wonder why you are using setup.cfg
> for this.
>
> setup.cfg has traditionally been used to configure distutils,
> not to define meta-data. As such you wouldn't
Steven D'Aprano wrote:
> On Thu, 24 Sep 2009 06:47:41 am Dino Viehland wrote:
>>> So I am +1 on unified the message and +1 on using the "does not
>>> support indexing" one.
>> I'd be +1 on the unified message as well - but it seems what that
>> message should be may be contentious (and quite a bike
On Thu, 24 Sep 2009 06:47:41 am Dino Viehland wrote:
> > So I am +1 on unified the message and +1 on using the "does not
> > support indexing" one.
>
> I'd be +1 on the unified message as well - but it seems what that
> message should be may be contentious (and quite a bike shed
> discussion at tha
Benjamin Peterson wrote:
2009/9/23 Michael Foord :
Benjamin Peterson wrote:
2009/9/23 Michael Foord :
Isn't that the real compatibility test *anyway* - how successful a new
version of Python is at running all the existing Python code...
Yes, but we should have expect
2009/9/23 Michael Foord :
> Benjamin Peterson wrote:
>>
>> 2009/9/23 Michael Foord :
>>
>>>
>>> Isn't that the real compatibility test *anyway* - how successful a new
>>> version of Python is at running all the existing Python code...
>>>
>>
>> Yes, but we should have expect 3rd party code to be de
Benjamin Peterson wrote:
2009/9/23 Michael Foord :
Isn't that the real compatibility test *anyway* - how successful a new
version of Python is at running all the existing Python code...
Yes, but we should have expect 3rd party code to be detecting bugs for
us that our test suite could
2009/9/23 Michael Foord :
> Isn't that the real compatibility test *anyway* - how successful a new
> version of Python is at running all the existing Python code...
Yes, but we should have expect 3rd party code to be detecting bugs for
us that our test suite could have shown on a platform.
--
R
Raymond Hettinger wrote:
[Michael Foord]
Are we definitely decided that 2.7 will be the last major release in
the 2.x cycle?
ISTM, that would depend on the uptake for 3.2.
The users get a say in the matter.
That would be my feeling...
Michael
Raymond
--
http://www.ironpythoninaction
[Michael Foord]
Are we definitely decided that 2.7 will be the last major release in the
2.x cycle?
ISTM, that would depend on the uptake for 3.2.
The users get a say in the matter.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://m
Fine with me. Let's move forward.
On Sep 23, 2009 11:27 PM, "Antoine Pitrou" wrote:
P.J. Eby telecommunity.com> writes: > > Hell, I *support* the bulk
of Tarek's setup.cfg p...
Ok, so Tarek and Philip, are you both ok that those little disagreements
should
belong to the past now? :)
Philip did
(Sorry if it's top posting I am on a mobile)
Come on phillip, no one is "plotting" against you.
You didn't maintain setuptools for a year while people where begging you to
do bug fixes. You blessed Ian and Jim to take over but they are too busy to
do it . I even sent them a mail on my side to try
On Wed, Sep 23, 2009 at 14:49, Michael Foord wrote:
> Brett Cannon wrote:
>>
>> On Wed, Sep 23, 2009 at 14:19, Michael Foord
>> wrote:
>> [SNIP]
>>
>>>
>>> Also +1. I had a friend (an experienced programmer) who started using
>>> Python
>>> recently. The cryptic nature of some of the error messag
Benjamin Peterson wrote:
2009/9/23 Brett Cannon :
On Wed, Sep 23, 2009 at 13:34, Benjamin Peterson wrote:
As for burn out, I expected 2.7.x, as the last 2.x release, to be
different in that several people would do the maintenance releases
(perhaps on a 6 month schedule or so) for the 5
On Wed, Sep 23, 2009 at 14:19, Michael Foord wrote:
> Benjamin Peterson wrote:
>>
>> 2009/9/23 Brett Cannon :
>>
>>>
>>> On Wed, Sep 23, 2009 at 07:35, Benjamin Peterson
>>> wrote:
>>>
Hi everyone,
I've started plotting the release of 2.7. I'd like to try for a final
release m
Brett Cannon wrote:
On Wed, Sep 23, 2009 at 14:19, Michael Foord wrote:
[SNIP]
Also +1. I had a friend (an experienced programmer) who started using Python
recently. The cryptic nature of some of the error messages was a sore point
with him.
Do you know which error messages? We can ch
2009/9/23 Brett Cannon :
> On Wed, Sep 23, 2009 at 13:34, Benjamin Peterson wrote:
>> As for burn out, I expected 2.7.x, as the last 2.x release, to be
>> different in that several people would do the maintenance releases
>> (perhaps on a 6 month schedule or so) for the 5 year period, so that
>> w
On Wed, Sep 23, 2009 at 13:47, Dino Viehland wrote:
> Brett wrote:
>> Let's ignore history, which I bet is the reason for the distinction,
>> and just look at the error messages; does the distinction make sense
>> to a newbie? I would say no and that the "does not support indexing"
>> error messag
Michael Foord voidspace.org.uk> writes:
>
> Are we definitely decided that 2.7 will be the last major release in the
> 2.x cycle?
I don't think any "definitive" decision was made, but judgeing by Benjamin's and
Brett's answers (and by my own sentiment :-)), it certainly is the expectation
of so
On Wed, Sep 23, 2009 at 13:34, Benjamin Peterson wrote:
> 2009/9/23 Brett Cannon :
>> On Wed, Sep 23, 2009 at 07:35, Benjamin Peterson wrote:
>>> Hi everyone,
>>> I've started plotting the release of 2.7. I'd like to try for a final
>>> release mid next summer. 3.2 should be released, if not at t
On Wed, Sep 23, 2009 at 14:19, Michael Foord wrote:
[SNIP]
> Also +1. I had a friend (an experienced programmer) who started using Python
> recently. The cryptic nature of some of the error messages was a sore point
> with him.
Do you know which error messages? We can change them. We have always
2009/9/23 Michael Foord :
> Benjamin Peterson wrote:
>> As for burn out, I expected 2.7.x, as the last 2.x release,
>
> Are we definitely decided that 2.7 will be the last major release in the 2.x
> cycle?
No, but that's what we're planning for atm.
--
Regards,
Benjamin
Benjamin Peterson python.org> writes:
>
> Different RMs would have different times they can do releases,
> so I would worry about there being a release in a slightly different
> stage of a different branch every couple weeks.
Assuming you can do it, +1 for you (Benjamin) being RM for both 2.7 an
P.J. Eby telecommunity.com> writes:
>
> Hell, I *support* the bulk of Tarek's setup.cfg proposal, and don't
> even object to him Pronouncing it or cutting off the discussion! My
> only issue on Python-Dev was his inaccurate implication that it was a
> SIG consensus rather than a pronouncement
Benjamin Peterson wrote:
2009/9/23 Brett Cannon :
On Wed, Sep 23, 2009 at 07:35, Benjamin Peterson wrote:
Hi everyone,
I've started plotting the release of 2.7. I'd like to try for a final
release mid next summer. 3.2 should be released, if not at the same
time as 2.7, within a few wee
M.-A. Lemburg wrote:
Brett Cannon wrote:
On Tue, Sep 22, 2009 at 20:08, R. David Murray wrote:
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 subsc
Brett Cannon wrote:
> On Tue, Sep 22, 2009 at 20:08, R. David Murray wrote:
>> 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 ex
Brett wrote:
> Let's ignore history, which I bet is the reason for the distinction,
> and just look at the error messages; does the distinction make sense
> to a newbie? I would say no and that the "does not support indexing"
> error message is more useful. For expert programmers they could figure
At 07:00 PM 9/23/2009 +0200, Tarek Ziadé wrote:
While it's great to have Philipp being part of our distutils design
discussions,
for his experience, I am not concerned of not having him in this "internal
consensus" since Setuptools is not maintained anymore.
He said some months ago, he would wor
2009/9/23 Brett Cannon :
> On Wed, Sep 23, 2009 at 07:35, Benjamin Peterson wrote:
>> Hi everyone,
>> I've started plotting the release of 2.7. I'd like to try for a final
>> release mid next summer. 3.2 should be released, if not at the same
>> time as 2.7, within a few weeks to avoid 2.x having
All,
I don't have the bandwidth right now to help out much in this thread,
so I'm glad that the collective effort has mostly figured out what the
rules are (as well as what they should be :-). It truly is a mess,
mostly thanks to the various concerns for backwards compatibility
(classic vs. new cl
2009/9/23 Antoine Pitrou :
> Benjamin Peterson python.org> writes:
>>
>> Hi everyone,
>> I've started plotting the release of 2.7. I'd like to try for a final
>> release mid next summer. 3.2 should be released, if not at the same
>> time as 2.7, within a few weeks to avoid 2.x having features whic
On Wed, 23 Sep 2009 10:11:18 -0700, Tarek Ziadé
wrote:
On Wed, Sep 23, 2009 at 7:08 PM, Michael Foord
wrote:
Note that Activestate also have a fledgling package management system
for
Python (unreleased yet I *believe*) so it is probably worth reaching
out to
them as well.
Yes I didn't
At 02:20 PM 9/23/2009 +0200, Tarek Ziadé wrote:
If you take the time to read everything you'll see that there were
no real alternative design proposed,
You did not respond to repeated requests (from more than one person),
for clarification regarding the requirements that your proposal was
try
On 06:03 pm, br...@python.org wrote:
On Wed, Sep 23, 2009 at 07:35, Benjamin Peterson
wrote:
[snip]
Additionally, I'm very apprehensive about doing any kind of release
without the buildbots running. Does anyone know when they might be up?
I don't know the answer, but it might be "never". We
On Wed, Sep 23, 2009 at 07:35, Benjamin Peterson wrote:
> Hi everyone,
> I've started plotting the release of 2.7. I'd like to try for a final
> release mid next summer. 3.2 should be released, if not at the same
> time as 2.7, within a few weeks to avoid 2.x having features which 3.x
> doesn't. I
On Wed, Sep 23, 2009 at 04:36, Antoine Pitrou wrote:
> Brett Cannon python.org> writes:
>>
>> Trust me, if you are doing open source for
>> anything other than altruistic reasons you are bound to be
>> disappointed.
>
> I'm surprised by this statement but perhaps it's a matter of vocabulary.
> Ha
On Tue, Sep 22, 2009 at 20:08, R. David Murray wrote:
> 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]
On 09/23/2009 10:00 AM, Tarek Ziadé wrote:
> But you are right about the need of making sure every package management
> project is involved. We should make sure that Enthought,
> which has its own package management system, is part of that consensus.
>
> Also, I am more concerned of not having en
Tarek Ziadé gmail.com> writes:
>
> Also, I am more concerned of not having enough end users involved in
> that process.
> End users would be: any python developer that needs
> to package his code, or any os packager that needs to package a python
> distribution
> for his system. But those are har
On Wed, Sep 23, 2009 at 7:08 PM, Michael Foord
wrote:
> Note that Activestate also have a fledgling package management system for
> Python (unreleased yet I *believe*) so it is probably worth reaching out to
> them as well.
Yes I didn't mention it because the project is private afaik. I'll ask
th
Tarek Ziadé wrote:
On Wed, Sep 23, 2009 at 4:04 PM, Stephen J. Turnbull wrote:
I did offer a concrete criterion for an individual's participation in
a "internal consensus": that you expect that they will adopt the new
features of distutils as a foundation for their own distribution
systems,
On Wed, Sep 23, 2009 at 4:04 PM, Stephen J. Turnbull wrote:
> I did offer a concrete criterion for an individual's participation in
> a "internal consensus": that you expect that they will adopt the new
> features of distutils as a foundation for their own distribution
> systems, or at least not i
Dino Viehland wrote:
Mark wrote:
On Wed, Sep 23, 2009 at 4:54 PM, Dino Viehland wrote:
We are going to start contributing tests back real soon now. I'm not sure
that these are the best tests to contribute as they require a version of
Python to compare against rather than being nice an
Mark wrote:
> On Wed, Sep 23, 2009 at 4:54 PM, Dino Viehland wrote:
> > We are going to start contributing tests back real soon now. I'm not sure
> > that these are the best tests to contribute as they require a version of
> > Python to compare against rather than being nice and stand alone. But
On Wed, Sep 23, 2009 at 4:54 PM, Dino Viehland wrote:
> We are going to start contributing tests back real soon now. I'm not sure
> that these are the best tests to contribute as they require a version of
> Python to compare against rather than being nice and stand alone. But I'm
> sure we have
Benjamin Peterson python.org> writes:
>
> Hi everyone,
> I've started plotting the release of 2.7. I'd like to try for a final
> release mid next summer. 3.2 should be released, if not at the same
> time as 2.7, within a few weeks to avoid 2.x having features which 3.x
> doesn't. If no one has pr
Skip wrote:
> Dino> For IronPython we wrote a set of tests which go through and define
> Dino> the various operator methods in all sorts of combinations on both
> Dino> new-style and old-style classes as well as subclasses of those
> Dino> classes and then do the comparisons w/ logg
Benjamin Peterson wrote:
Hi everyone,
I've started plotting the release of 2.7. I'd like to try for a final
release mid next summer. 3.2 should be released, if not at the same
time as 2.7, within a few weeks to avoid 2.x having features which 3.x
doesn't. If no one has problems with this, I will
On 02:35 pm, benja...@python.org wrote:
Hi everyone,
I've started plotting the release of 2.7. I'd like to try for a final
release mid next summer. 3.2 should be released, if not at the same
time as 2.7, within a few weeks to avoid 2.x having features which 3.x
doesn't. If no one has problems wit
Eric> IIRC, one of the reasons for "breaking out"[1] the standard library
(and
Eric> its test suite) was to allow for things like this.
In my opinion the standard library and the core test suite (the language
validation stuff) are entirely independent beasts. I can understand pieces
of
Hi everyone,
I've started plotting the release of 2.7. I'd like to try for a final
release mid next summer. 3.2 should be released, if not at the same
time as 2.7, within a few weeks to avoid 2.x having features which 3.x
doesn't. If no one has problems with this, I will draft a schedule.
Are we s
Tarek Ziadé writes:
> On Wed, Sep 23, 2009 at 9:03 AM, Stephen J. Turnbull
> wrote:
> > 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
s...@pobox.com wrote:
Dino> For IronPython we wrote a set of tests which go through and define
Dino> the various operator methods in all sorts of combinations on both
Dino> new-style and old-style classes as well as subclasses of those
Dino> classes and then do the comparisons w/
On Tue, Sep 22, 2009 at 9:15 PM, Dino Viehland wrote:
> 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 gen
On Tue, Sep 22, 2009 at 11:43 PM, wrote:
>
> Dino> For IronPython we wrote a set of tests which go through and define
> Dino> the various operator methods in all sorts of combinations on both
> Dino> new-style and old-style classes as well as subclasses of those
> Dino> classes and th
Antoine Pitrou wrote:
> Brett Cannon python.org> writes:
>> Trust me, if you are doing open source for
>> anything other than altruistic reasons you are bound to be
>> disappointed.
>
> I'm surprised by this statement but perhaps it's a matter of vocabulary.
> Having fun and doing things you like
On Wed, Sep 23, 2009 at 9:03 AM, Stephen J. Turnbull wrote:
> 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 (attr
Greg Ewing wrote:
> 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
Mark Dickinson wrote:
> 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 on
2009/9/23 Chris Withers :
>> 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 improv
On Wed, Sep 23, 2009 at 12:53 AM, Sridhar Ratnakumar
wrote:
> 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 al
Chris Withers schrieb:
> 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.__
Brett Cannon python.org> writes:
>
> Trust me, if you are doing open source for
> anything other than altruistic reasons you are bound to be
> disappointed.
I'm surprised by this statement but perhaps it's a matter of vocabulary.
Having fun and doing things you like to do does not strike me as "
On Wed, Sep 23, 2009 at 4:43 AM, wrote:
>
> Dino> For IronPython we wrote a set of tests which go through and define
> Dino> the various operator methods in all sorts of combinations on both
> Dino> new-style and old-style classes as well as subclasses of those
> Dino> classes and the
On Wed, Sep 23, 2009 at 9:12 AM, Chris Withers wrote:
> Mark Dickinson wrote:
>>
>> I (still :-) think this is covered, for Python 2.x at least, by:
>>
>> http://docs.python.org/reference/datamodel.html#coercion-rules
>
> But this isn't coercion! :-)
Agreed. FWIW this behaviour for arithmetic op
Dino> For IronPython we wrote a set of tests which go through and define
Dino> the various operator methods in all sorts of combinations on both
Dino> new-style and old-style classes as well as subclasses of those
Dino> classes and then do the comparisons w/ logging.
It would be v
On Wed, Sep 23, 2009 at 09:49:16AM +0200, M.-A. Lemburg wrote:
> While it's a good idea to put up some form of meta-data
> into an index, I wonder why you are using setup.cfg
> for this.
>
> setup.cfg has traditionally been used to configure distutils,
> not to define meta-data. As such you wouldn
Mark Dickinson wrote:
I (still :-) think this is covered, for Python 2.x at least, by:
http://docs.python.org/reference/datamodel.html#coercion-rules
But this isn't coercion! :-)
- For objects x and y, first x.__op__(y) is tried. If this is not
implemented or returns NotImplemented, y.__rop_
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.
>
>
89 matches
Mail list logo
