Re: [Python-Dev] Distutils ML wrap-up: setup.cfg new format

[M.-A. Lemburg]

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.

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 want to
put such a configuration file up on PyPI.

Wouldn't it be better use a new file for this (with the
same syntax), e.g. metadata.cfg ?! This would then just
contain the meta data that needs to be published.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Sep 23 2009)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
Python-Dev mailing list
Python-Dev@python.org
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

[Chris Withers]

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__(x) is tried. 


Also, the above is not so:

Python 2.5.1
>>> class X:
...   def __eq__(self,other):
... print "X __eq__"
>>> class Z: pass
...
>>> Z()==X()
X __eq__

No __req__ in sight...

cheers,

Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
   - http://www.simplistix.co.uk
___
Python-Dev mailing list
Python-Dev@python.org
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

[Floris Bruynooghe]

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't want to
> put such a configuration file up on PyPI.
> 
> Wouldn't it be better use a new file for this (with the
> same syntax), e.g. metadata.cfg ?! This would then just
> contain the meta data that needs to be published.

IIRC the goal was to make minimal changes and setup.cfg is known
already.  It's use is similar too: it configures the setup.py script
with static data.

PyPI could only extract the [setup:*] sections if you'r worried about
it having random configuration from developers.  I don't think this is
enough of a argument in favour or not of a metadata file separate from
setup.cfg.

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Python-Dev mailing list
Python-Dev@python.org
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

[skip]

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 very nice if these complex corner cases had a set of test
cases which could be run by all implementations (CPython, Jython,
IronPython, PyPy, etc).  I don't know.  Maybe the CPython test suite serves
that purpose, but it seems like it would be helpful if this sort of
"validation suite" was maintained as a separate project all implementations
could use and contribute to.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
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

[Mark Dickinson]

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 operations is also mentioned in

http://docs.python.org/reference/datamodel.html#emulating-numeric-types

but then again that section doesn't include the comparison operators.

>
>> - For objects x and y, first x.__op__(y) is tried. If this is not
>> implemented or returns NotImplemented, y.__rop__(x) is tried.
>
> Also, the above is not so:
>
> Python 2.5.1
 class X:
> ...   def __eq__(self,other):
> ...     print "X __eq__"
 class Z: pass
> ...
 Z()==X()
> X __eq__
>
> No __req__ in sight...

Okay, so combine this with the sentence under:

http://docs.python.org/reference/datamodel.html#object.__eq__

that says:

"There are no swapped-argument versions of these methods (to be used
when the left argument does not support the operation but the right
argument does); rather, __lt__() and __gt__() are each other’s
reflection, __le__() and __ge__() are each other’s reflection, and
__eq__() and __ne__() are their own reflection."

So in the earlier doc snippets, if __op__ is __eq__, then __rop__
should also be interpreted as __eq__;  similarly if __op__ is __lt__
then __rop__ is __gt__.

I'm not saying that the documentation here couldn't be improved;  just
that IMO the docs do (with a little bit of extrapolation) describe
what should happen, giving the 'official' specification that you were
after.

I don't know where/whether the behaviour for classes that define both
__cmp__ and __eq__ are documented, though, and I'm far from sure what
the rules are in that case.

One minor oddity is that for arithmetic operations like __add__(self,
other), if type(self) == type(other) then __radd__ isn't checked, on
the basis that if __add__ fails then the operation is presumably not
supported.  This makes sense, but I wonder why this doesn't apply
equally well to __eq__:  that is, in doing A() == A() for a class A,
why do we try the __eq__ method of both instances?

Mark
___
Python-Dev mailing list
Python-Dev@python.org
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

[Mark Dickinson]

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 then do the comparisons w/ logging.
>
> It would be very nice if these complex corner cases had a set of test
> cases which could be run by all implementations (CPython, Jython,
> IronPython, PyPy, etc).  I don't know.  Maybe the CPython test suite serves
> that purpose, but it seems like it would be helpful if this sort of
> "validation suite" was maintained as a separate project all implementations
> could use and contribute to.

+1

Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] altruism

[Antoine Pitrou]

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 "altruistic".
Being involved in a FOSS project is not the same as participating in a charity.

See this quick presentation about motivation of FOSS developers (second slide
says: "Altruism? Not really"):
http://www.infonomics.nl/FLOSS/papers/20030619/index.htm
The full study is at:
http://www.infonomics.nl/FLOSS/report/index.htm
("Part IV: Survey of Developers")

(but of course there's the question of whether "altruism" exists at large, or is
a political and moral fiction)

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
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

[Georg Brandl]

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.__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?

Yes. Unfortunately it's just documented for the other binops, but not
for the comparisons; the note in the docs should be copied to the
respective section.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
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é]

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 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.

Please keep in mind that the original proposal is having the ability to
get static metadata (metadata: PEP 314) without running any code.

Your mail contains two things:

- yet another way to express the conditions  (that's the bikeshedding)
- a setuptools mechanism located in setup.py that works with an option
to build a
  requires.txt file when you install a package or create a binary distribution.

The later is not related to what we want to do, or if it is, please
refine your proposal
and make it clear at Distutils-SIG.


Tarek
-- 
Tarek Ziadé | http://ziade.org | オープンソースはすごい!
___
Python-Dev mailing list
Python-Dev@python.org
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é]

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 improving the
>> packaging situation.
>
> ...except that this isn't bikeshedding. Use of that term just to stifle
> productive discussion is also rude.


- choosing if we are going to use "py<2.6" instead of
"python_version<2.6" is bikeshedding.

- explaining that os.uname() contains irrelevant infos and we
shouldn't add it as-is in the
  execution context is not bikeshedding (see Ronald last mail in the thread)

Please go back to the thread at distutils-SIG and list all points in
the proposal
that seems to you as non-bikeshedding things.

Tarek
-- 
Tarek Ziadé | http://ziade.org | オープンソースはすごい!
___
Python-Dev mailing list
Python-Dev@python.org
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

[Nick Coghlan]

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 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

Quite some time ago, I attempted to accurately document all of this - my
efforts are buried in an ODF document in the SVN sandbox:

http://svn.python.org/view/sandbox/trunk/userref/ODF/Chapter02_StatementsAndExpressions.odt

Extracting all of that text with some kind of ODT2ReST converter has now
been on my to-do list for over a year :P

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
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

[Nick Coghlan]

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__(x) is *not* tried before
>> x.__op__(y).
> 
> How does this work at the C typeslot level, where
> there are no __rop__ methods?

The interpreter doesn't promise to call those slots with "self" first -
self will be the second argument in the "rop" case.

See binary_op1() in abstract.c for the gory details (I had to go look it
up myself in order to rediscover how it worked).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
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é]

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 (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.

Please define what "internal consensus on Distutils-SIG" means.

If it means that everyone present in the Mailing-List
needs to agree on a distutils proposal, this will never happen for many reasons.

Here's one :

That's not the distutils mailing list anymore. Here's a list of the projects
"officialy" hosted in this mailing list:

- distutils
- setuptools
- zc.buildout

So, while it's legitimate to get some feedback from setuptools and
zc.buildout users
and developers, (on anyone else) on what we are planning for
distutils, don't you agree that
it's impossible in this context to get a 100% consensus ? and that I need to
take some decisions to move distutils on ?

Especially for this topic. If you take the time to read everything you'll see
that there were no real alternative design proposed, and that I am
just working out
the details because I maintain and code distutils.

Tarek
-- 
Tarek Ziadé | http://ziade.org | オープンソースはすごい!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] altruism

[Nick Coghlan]

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 to do does not strike me as "altruistic".
> Being involved in a FOSS project is not the same as participating in a 
> charity.

I'd agree that 'altruism' isn't quite the right word - there's also the
fact that plenty of folks these days contribute to open source because
someone is paying them to :)

However, Brett's basic point that good input may sometimes go uncredited
through no fault of the poster's remains valid.

Patches and particularly good bug reports/suggestions get credited in
commit messages and sometimes NEWS items and the What's New, significant
patches generally earn a mention in the ACKS file and each PEP usually
has an acknowledgement section that lists major contributors to the
associated discussion and reviews.

Posts (even well-thought out ones) on the various discussion lists? Not
so much - it's too easy to lose track of who posted what in an involved
discussion. The highest respect you can really earn in those is to make
a valid point clearly enough that you convince others to adopt your
point of view. Although sometimes you can still persuade others even
when you later turn out to be wrong* ;)

Cheers,
Nick.

* See a couple of the footnotes to PEP 343 if you want to know what that
smiley is about :)

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
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 Wierzbicki]

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 then do the comparisons w/ logging.
>
> It would be very nice if these complex corner cases had a set of test
> cases which could be run by all implementations (CPython, Jython,
> IronPython, PyPy, etc).  I don't know.  Maybe the CPython test suite serves
> that purpose, but it seems like it would be helpful if this sort of
> "validation suite" was maintained as a separate project all implementations
> could use and contribute to.
Talk has started up again on the stdlib-sig list about finding a core
stdlib + tests that can be shared by all implementations, potentially
living apart from CPython.  I have volunteered to put together a PEP
on the subject, with Jessie Noller and Brett Canon are helping me out.
 When I have something worth showing, I'll start the real PEP process.

-Frank
___
Python-Dev mailing list
Python-Dev@python.org
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 Wierzbicki]

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 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.
Great, thanks!  I'll take a look (for real this time :)

-Frank
___
Python-Dev mailing list
Python-Dev@python.org
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

[Eric Smith]

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/ logging.

It would be very nice if these complex corner cases had a set of test
cases which could be run by all implementations (CPython, Jython,
IronPython, PyPy, etc).  I don't know.  Maybe the CPython test suite serves
that purpose, but it seems like it would be helpful if this sort of
"validation suite" was maintained as a separate project all implementations
could use and contribute to.


IIRC, one of the reasons for "breaking out"[1] the standard library (and 
its test suite) was to allow for things like this.


Eric.

[1] For whatever definition "breaking out" ends up having.

___
Python-Dev mailing list
Python-Dev@python.org
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

[Stephen J. Turnbull]

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 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.
 > 
 > Please define what "internal consensus on Distutils-SIG" means.

Definition is your job, as chairman/dictator.

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 implement and promote an alternative.

As for who needs to be included, if the author of setuptools isn't
part of the internal consensus (on that, I'm just guessing from the
fact that he went off to "start a new thread"), I think you should be
concerned.  He's already implemented and promoted an alternative in
the past, so he doesn't even have to do any implementation.  Just keep
on using and promoting his preferred tools and formats.

A third point is that you can have a consensus on "agreeing to
disagree".  But it's unlikely that you will have 100% *dis*agreement.
If you can get a consensus that on certain points certain people are
simply not going to change their minds, it's often possible to move
past that to work on things that you can agree on.  (And if some
people are unwilling to even admit that, it's usually clear to
absolutely everybody else.)

 > distutils, don't you agree that it's impossible in this context to
 > get a 100% consensus ?

Depends on how you define "100% consensus".  If you mean 100% of
people agree on 100% of the proposal, of course not.  But there may be
40% of the proposal you can get 90% of the people to agree on, and
maybe 90% of the proposal is acceptable to 40% of the people.  (That
would be pretty good in this case, but this community regularly
manages to come close to that, so there's some hope.)

If you can get the setuptools and buildout people to agree to use some
parts of "new distutils", that's a form of consensus, and definite
progress.

 > and that I need to take some decisions to move distutils on ?

I don't know; a better distribution system is not something I need as
a user or a developer.  What worries me is that a simple progress
report caused dissension to spill over onto the Python-Dev list.  That
is relatively rare in this community.  And people like Brett think
it's important that some progress be made on distutils, so I'd like to
see it done as quickly as possible -- but no quicker.

 > Especially for this topic. If you take the time to read everything
 > you'll see that there were no real alternative design proposed, and
 > that I am just working out the details because I maintain and code
 > distutils.

Well, from the behavior of Philip and Chris, it seems that their
position is that there was insufficient time to put forward an
alternative design before the summary was posted to Python-Dev.  *I
don't care whether its true or not*, it's your job as chairman/
dictator to decide that, and we shouldn't discuss it here.  But merely
leaving the *impression* is damaging, and I suggested a simple
procedure (posting the summary to your mailing list and requesting
comments) that would very likely improve the summary, and also be
likely to keep unnecessary controversy off Python-Dev.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] thinking about 2.7

[Benjamin Peterson]

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 still planning to make 3.3 the main development focus and start
the 5 years of 2.x maintenance after this release?

Additionally, I'm very apprehensive about doing any kind of release
without the buildbots running. Does anyone know when they might be up?

-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
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

[skip]

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 the standard library not being available in one variant or another, but
key semantic aspects of the language proper should be constant across
implementations.

That said, I agree that if the standard library is split off from CPython
then the relevant portions of the test suite should go along with it.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] thinking about 2.7

[exarkun]

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 with this, I will draft a schedule.

Are we still planning to make 3.3 the main development focus and start
the 5 years of 2.x maintenance after this release?


I hope that this decision will be delayed until the release is closer, 
so that it can be based on how 3.x adoption is progressing.

Additionally, I'm very apprehensive about doing any kind of release
without the buildbots running. Does anyone know when they might be up?


I was planning on replying to Antoine's earlier message about the 
buildbots after a sufficiently long silence.  I'll reply here instead.


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 to be small, but since finding dedicated people can sometimes be 
challenging, I think small teams are the most likely outcome (possibly 
resulting in a team of one).  Adding more people who are only mildly 
interested doesn't help.  If, as I believe is the case with Python's 
buildbot configuration, the mildly interested people have sole control 
over certain slaves, then it is actually detrimental.


It's easy for someone to volunteer to set up a new slave.  It's even 
easy to make sure it keeps running for 6 months.  But it's not as easy 
to keep it running indefinitely.  This isn't about the software involved 
(at least not entirely).  It's about someone paying attention to whether 
the slave restarts on reboots, and about paying attention to whether the 
slave host has lots its network connection, or been decomissioned, or 
whether a system upgrade disabled the slave, or whatever other random 
administrative-like tasks are necessary to keep things running.  Casual 
volunteers generally just won't keep up with these tasks.


I suggest finding someone who's seriously interested in the quality of 
CPython and giving them the responsibility of keeping things operating 
properly.  This includes paying attention to the status of slaves, 
cajoling hardware operators into bringing hosts back online and fixing 
network issues, and finding replacements of the appropriate type 
(hardware/software platform) when a slave host is permanently lost.


I would also personally recommend that this person first (well, after 
tracking down all the slave operators and convincing them to bring their 
slaves back online) acquire shell access to all of the slave machines so 
that the owners of the slave hosts themselves no longer need to be the 
gating factor for most issues.


Jean-Paul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] thinking about 2.7

[Michael Foord]

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 draft a schedule.
  

+1

I'm keen to see a 2.7 release as there are good new features on trunk 
(particularly in unittest :-)


Michael


Are we still planning to make 3.3 the main development focus and start
the 5 years of 2.x maintenance after this release?

Additionally, I'm very apprehensive about doing any kind of release
without the buildbots running. Does anyone know when they might be up?

  



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
Python-Dev mailing list
Python-Dev@python.org
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

[Dino Viehland]

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/ logging.
> 
> It would be very nice if these complex corner cases had a set of test
> cases which could be run by all implementations (CPython, Jython,
> IronPython, PyPy, etc).  I don't know.  Maybe the CPython test suite serves
> that purpose, but it seems like it would be helpful if this sort of
> "validation suite" was maintained as a separate project all implementations
> could use and contribute to.

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 other tests which cover this as well just not as exhaustively.  
We could also possibly check in the baseline file and then CPython could 
compare it's self to previous versions but it'd probably be a pretty
big file - so it probably shouldn't be included in the standard install
in the tests directory.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] thinking about 2.7

[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 which 3.x
> doesn't. If no one has problems with this, I will draft a schedule.

If you want to avoid the low-activity low-responsiveness holiday period, you
might shoot for June or September/October instead.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
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

[Mark Dickinson]

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 other tests which cover this as well just not as exhaustively.
> We could also possibly check in the baseline file and then CPython could
> compare it's self to previous versions but it'd probably be a pretty
> big file - so it probably shouldn't be included in the standard install
> in the tests directory.

How big is big?  For comparison, CPython's Lib/test/decimaltestdata
directory alone is already over 4Mb, so maybe size isn't an issue?

Mark
___
Python-Dev mailing list
Python-Dev@python.org
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

[Dino Viehland]

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 I'm
> > sure we have other tests which cover this as well just not as exhaustively.
> > We could also possibly check in the baseline file and then CPython could
> > compare it's self to previous versions but it'd probably be a pretty
> > big file - so it probably shouldn't be included in the standard install
> > in the tests directory.
> 
> How big is big?  For comparison, CPython's Lib/test/decimaltestdata
> directory alone is already over 4Mb, so maybe size isn't an issue?

Running all of the side by side tests except our exceptions test it's 
about 73Mb.  It might be highly compressible though.
___
Python-Dev mailing list
Python-Dev@python.org
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

[Michael Foord]

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 and stand alone.  But I'm
sure we have other tests which cover this as well just not as exhaustively.
We could also possibly check in the baseline file and then CPython could
compare it's self to previous versions but it'd probably be a pretty
big file - so it probably shouldn't be included in the standard install
in the tests directory.
  

How big is big?  For comparison, CPython's Lib/test/decimaltestdata
directory alone is already over 4Mb, so maybe size isn't an issue?



Running all of the side by side tests except our exceptions test it's 
about 73Mb.  It might be highly compressible though.
  


It sounds like many of these belong in an 'implementation-compliance' 
test suite separate from the main test suite.


On the other hand many of the tests probably cover areas that are really 
'sparsely' covered by current Python tests. For many of them getting a 
'defined' set of results and changing the tests to compare against that 
rather than against CPython could be really useful - but probably a lot 
of work to create.


Michael

___
Python-Dev mailing list
Python-Dev@python.org
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
Python-Dev@python.org
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é]

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 implement and promote an alternative.
>
> As for who needs to be included, if the author of setuptools isn't
> part of the internal consensus (on that, I'm just guessing from the
> fact that he went off to "start a new thread"), I think you should be
> concerned.  He's already implemented and promoted an alternative in
> the past, so he doesn't even have to do any implementation.  Just keep
> on using and promoting his preferred tools and formats.

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 work on a brand new setuptools
version with zero
dependency to distutils. But it's still vaporware (from his own
words), and the previous version is unmaintained for a year, so it was
forked.

The Distribute (setuptools fork), which is likely to be the first and
only public packaging system
on the top of distutils working under Python 3 (the trunk is
py3k-ready and should be released
in a few days), is pretty active, and none of his contributor raised
against the proposal.

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 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 hard to get involved.

> Well, from the behavior of Philip and Chris, it seems that their
> position is that there was insufficient time to put forward an
> alternative design before the summary was posted to Python-Dev.  *I
> don't care whether its true or not*, it's your job as chairman/
> dictator to decide that, and we shouldn't discuss it here.  But merely
> leaving the *impression* is damaging, and I suggested a simple
> procedure (posting the summary to your mailing list and requesting
> comments) that would very likely improve the summary, and also be
> likely to keep unnecessary controversy off Python-Dev.

Please note that the controversy that popped in python-dev didn't popped in
distutils-SIG after I clearly stated that I was going to send a
summary in python-dev,
(which I did four days after). No one commented on it then.

Next time I'll wait a week and I will also send the summary as you suggested,
to make sure everyone sees the message, not hidden inside a big thread.

But I doubt this will cut all further controversy once it's in
Pyton-dev, because
being controversial in Python-dev doesn't have the same impact for the writer
and the readers.

Tarek
___
Python-Dev mailing list
Python-Dev@python.org
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

[Michael Foord]

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, or at least not implement and promote an alternative.

As for who needs to be included, if the author of setuptools isn't
part of the internal consensus (on that, I'm just guessing from the
fact that he went off to "start a new thread"), I think you should be
concerned.  He's already implemented and promoted an alternative in
the past, so he doesn't even have to do any implementation.  Just keep
on using and promoting his preferred tools and formats.



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 work on a brand new setuptools
version with zero
dependency to distutils. But it's still vaporware (from his own
words), and the previous version is unmaintained for a year, so it was
forked.

The Distribute (setuptools fork), which is likely to be the first and
only public packaging system
on the top of distutils working under Python 3 (the trunk is
py3k-ready and should be released
in a few days), is pretty active, and none of his contributor raised
against the proposal.

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.

  


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.



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 hard to get involved.
  


Perhaps post your summaries on your blog as well (which is aggregated on 
Planet Python right?) - including a description of the problem it aims 
to solve and how it will be used.


You'll *mostly* be reaching the same set of people, but at least it 
spreads the net a bit wider.


Michael

  

Well, from the behavior of Philip and Chris, it seems that their
position is that there was insufficient time to put forward an
alternative design before the summary was posted to Python-Dev.  *I
don't care whether its true or not*, it's your job as chairman/
dictator to decide that, and we shouldn't discuss it here.  But merely
leaving the *impression* is damaging, and I suggested a simple
procedure (posting the summary to your mailing list and requesting
comments) that would very likely improve the summary, and also be
likely to keep unnecessary controversy off Python-Dev.



Please note that the controversy that popped in python-dev didn't popped in
distutils-SIG after I clearly stated that I was going to send a
summary in python-dev,
(which I did four days after). No one commented on it then.

Next time I'll wait a week and I will also send the summary as you suggested,
to make sure everyone sees the message, not hidden inside a big thread.

But I doubt this will cut all further controversy once it's in
Pyton-dev, because
being controversial in Python-dev doesn't have the same impact for the writer
and the readers.

Tarek
___
Python-Dev mailing list
Python-Dev@python.org
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
Python-Dev@python.org
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é]

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
them if it's planned
to be released.


> Perhaps post your summaries on your blog as well (which is aggregated on
> Planet Python right?) - including a description of the problem it aims to
> solve and how it will be used.
>
> You'll *mostly* be reaching the same set of people, but at least it spreads
> the net a bit wider.

That's right, I'll do it as well.
___
Python-Dev mailing list
Python-Dev@python.org
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]

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 hard to get involved.

I'm sure there are some of them on this list.
If you are concerned about opinion diversity, you can always try to probe
python-list (c.l.py) about it ;)

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.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
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

[Toshio Kuratomi]

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 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 hard to get involved.
> 
As one of the people who deals with packaging python modules for
distributions, I'm sorry for not having spent more time looking into
this.  I simply haven't had the time lately.  One helpful resource for
engaging linux distributions is:

##distros on irc.freenode.net and their mailing list:
http://lists.freedesktop.org/mailman/listinfo/distributions

Both are low traffic but people from the various linux distributions are
watching and responding on it even if they don't make much noise on
their own.  Just bear in mind that sometimes they will need to connect
you with the right person within their distro rather than being able to
give feedback directly.

-Toshio
___
Python-Dev mailing list
Python-Dev@python.org
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

[Brett Cannon]

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]
>>>  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?

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
out the problem with either error message. The only help is if you are
trying to debug a type, but I am willing to bet most of us didn't know
the distinction at the C level until David looked it up.

So I am +1 on unified the message and +1 on using the "does not
support indexing" one.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] altruism

[Brett Cannon]

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.
> Having fun and doing things you like to do does not strike me as "altruistic".
> Being involved in a FOSS project is not the same as participating in a 
> charity.
>
> See this quick presentation about motivation of FOSS developers (second slide
> says: "Altruism? Not really"):
> http://www.infonomics.nl/FLOSS/papers/20030619/index.htm
> The full study is at:
> http://www.infonomics.nl/FLOSS/report/index.htm
> ("Part IV: Survey of Developers")
>
> (but of course there's the question of whether "altruism" exists at large, or 
> is
> a political and moral fiction)

Ignoring the temptation to pull out my philosophy degree and devolve
into a ridiculously involved conversation, I meant "altruism" in
regard to not expecting to get anything from others for what you do. I
do think you should only do open source work if you have fun and enjoy
it, but I also think you should not do it for anyone but yourself
unless you are drawing a paycheck.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] thinking about 2.7

[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 features which 3.x
> doesn't. If no one has problems with this, I will draft a schedule.
>

Yes. Does this mean you are volunteering to be the 3.2 release
manager? Or simply prodding for volunteers? If it's the former are you
at all worried about burn-out from doing two release so close together
and being on the hook for two point releases at roughly the same time
for about two years after?

> Are we still planning to make 3.3 the main development focus and start
> the 5 years of 2.x maintenance after this release?

I think so. As Jean-Paul somewhat pointed out the decision can change,
but at this point I know I am willing to say that I don't want to have
to port to four branches anymore if I don't need to.

>
> 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 used to do
releases without them, so it's not impossible. Just means you have to
really push the alphas, betas, and RCs.

Titus Brown is actually working on a buildbot alternative that's more
volunteer-friendly (pony-build). Hopefully that will be up and going
by then so we can contemplate using that.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] thinking about 2.7

[exarkun]

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 used to do
releases without them, so it's not impossible. Just means you have to
really push the alphas, betas, and RCs.

Titus Brown is actually working on a buildbot alternative that's more
volunteer-friendly (pony-build). Hopefully that will be up and going
by then so we can contemplate using that.


I certainly wish Titus luck in his project, but I'm skeptical about 
pony-build magically fixing the problems CPython development has with 
buildbot.


Jean-Paul
___
Python-Dev mailing list
Python-Dev@python.org
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

[P.J. Eby]

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 
trying to fill.  More than one person expressed reservations about 
the complexity of your candidate proposal, and wanted to know why we 
needed a fully conditional syntax, if the only use case for 
conditionals was expressing dependencies.


That there was not a "complete" alternative proposal is true...  but 
that's only because you would not answer the question that several 
people asked: that is, why do we *need* conditionals, for anything 
besides dependencies?  What are the use cases?


More than one person asked that question, but I never saw you answer 
it.  (In one case, you answered with the use cases for what the 
conditionals needed to be able to *check*, but not *what the 
conditionals were conditioning* -- which was the whole point of the question.)


A lack of polished alternatives to your proposal does not constitute 
a positive rationale for your own proposal, especially if people are 
asking for the rationale in order to determine whether a simpler 
proposal would suffice!


I dropped my previous competing proposal some time ago when you 
presented strong use cases for static metadata.  And I'd have happily 
dropped my support for Sridhar's proposal, too, if you'd given 
similarly strong use cases for the proposal you went with.


But even if you *didn't* give those use cases, I'd have been fine 
with you saying to Python-Dev, "I got tired of the discussion and 
chose to Pronounce."  (After all, that is what you more or less said 
on the distutils-sig.)


But what hacked me off is that *here*, you presented your 
pronouncement as if it were a summary of distutils-sig discussion, 
when the last flurry of traffic on the distutils-sig right beforehand 
was a bunch of questions and requests for use cases.  Not nice.


___
Python-Dev mailing list
Python-Dev@python.org
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

[Sridhar Ratnakumar]

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 mention it because the project is private afaik. I'll ask
them if it's planned
to be released.


PyPM is planned to be released to the public shortly after the planned  
2.6.3 release. Most likely during the first week of October.


-srid
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] thinking about 2.7

[Benjamin Peterson]

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 which 3.x
>> doesn't. If no one has problems with this, I will draft a schedule.
>
> If you want to avoid the low-activity low-responsiveness holiday period, you
> might shoot for June or September/October instead.

That is a good point, so I think we should shoot for June.



-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
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

[Guido van Rossum]

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 classes *and* __cmp__ vs rich comparisons makes for a
truly maddening compatibility matrix).

The double __eq__ calls in the pastebin examples are a surprise even
to me; it seems the logic for first giving the left object a chance
and then the right object is duplicated in the generic rich comparison
logic in object.c and again in instance_richcompare() in
classobject.c.

As Brett cautioned in the bug, I would be hesitant to try and fix this
in 2.x; there's simply too much code that relies on whatever odd
behavior CPython happens to exhibit, especially in test suites that
often over-constrain the behavior (see e.g. the other thread about
error messages, where I have nothing to add that Brett didn't already
say). In 3.2 I'm fine with the (ever so slight) semantic change,
especially since the behavior will rarely be exhibited in practice.
(You'd have to have two different objects with __eq__ methods that
return NotImplemented *and* have some kind of side effect that is
expected.)

--Guido

On Tue, Sep 22, 2009 at 8:12 AM, 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 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
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] thinking about 2.7

[Benjamin Peterson]

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 features which 3.x
>> doesn't. If no one has problems with this, I will draft a schedule.
>>
>
> Yes. Does this mean you are volunteering to be the 3.2 release
> manager? Or simply prodding for volunteers? If it's the former are you
> at all worried about burn-out from doing two release so close together
> and being on the hook for two point releases at roughly the same time
> for about two years after?

While I certainly wouldn't mind doing only 2.7, I don't know how we
could preserve everyone's sanity and release them at about the same
time. 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.

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
would leave me with just 3.2.x (and maybe another 3.1.x release).

...
>>
>> 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 used to do
> releases without them, so it's not impossible. Just means you have to
> really push the alphas, betas, and RCs.

What do you mean "push"?





-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
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

[P.J. Eby]

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 work on a brand new setuptools
version with zero
dependency to distutils. But it's still vaporware (from his own
words), and the previous version is unmaintained for a year, so it was
forked.


Here's what actually happened, if anyone cares.  Tarek and friends 
announced a fork of setuptools.  I reviewed the work and saw that -- 
for the most part -- I was happy with it, and opined as how I might 
be willing to bless the the "package inquisition" team as official 
maintainers of the 0.6 branch of setuptools, so that I could work on 
the fun bits I've long planned for 0.7, but never felt free to start 
on while there was so much still needing to be done on 0.6.


However, just as I mentioned this, and suggested an option for what I 
could do that would be helpful to his Distribute 0.7 project as well 
as various other tools (e.g. implementing some of Jim Fulton's 
long-requested features for better modularization of setuptools), 
Tarek accused me of somehow trying to undermine his plans.


In addition, it appears Tarek was also offended by my earlier 
statement that there were only a few people in the Python community 
who had *already* earned my implicit trust to not only hack on 
setuptools unsupervised, but also to take over its *future* direction 
and BDFL-ship.  (For example, Jim Fulton and Ian Bicking.)


Tarek, however, appears to have taken this to mean that I personally 
thought he was an incompetent programmer or something (when I 
actually had no opinion one way or the other), and ever since he has 
taken to levelling potshots like the above at me on a semi-regular basis.


I've tried to ignore this and play nice, because he is actually 
working on this stuff and I am not.  But it's hard for me to actually 
give any help in practice, if Tarek is too busy projecting hidden 
plots onto everything I say and do.


If you read Tarek's distutils-sig posts, it appears my 
already-existing trust in Ian and Jim was not only a personal insult 
to Tarek, but also a plot to ensure that nobody with any time to do 
so would ever work on setuptools, just as my excitement about working 
on setuptools again was a plot to steal thunder from his fork.


All I want is for good stuff to happen for setuptools users and 
Python users in general, so I don't think all the suspicion and 
backbiting is merited.  I certainly don't appreciate it, and I would 
like it to stop.  It also isn't even relevant to the thread, since my 
lack of work on setuptools says exactly zero about the merits or lack 
thereof of Tarek's proposals for the distutils!


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 on it.  There is and was no 
need for any of this to get personal, and I have continually strived 
to keep my posts here and distutils-sig civil, even when I didn't 
feel like being civil in response to Tarek's jabs.  I have in fact 
bent over backwards to be *nice* to Tarek, because he seemed so damn 
sensitive about everything.  Apparently, however, this does not 
actually help things.  :-(


___
Python-Dev mailing list
Python-Dev@python.org
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]

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
> out the problem with either error message. The only help is if you are
> trying to debug a type, but I am willing to bet most of us didn't know
> the distinction at the C level until David looked it up.
> 
> 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 that).
The bug David linked to (http://bugs.python.org/issue5760) has a 
preference for subscript because that's what's used elsewhere in the 
language. 
___
Python-Dev mailing list
Python-Dev@python.org
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

[M.-A. Lemburg]

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 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?
> 
> 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
> out the problem with either error message. The only help is if you are
> trying to debug a type, but I am willing to bet most of us didn't know
> the distinction at the C level until David looked it up.
> 
> So I am +1 on unified the message and +1 on using the "does not
> support indexing" one.

+1 as well.

Note that the wording of error message has never been something
we guaranteed backwards compatibility for, so such changes are a
lot easier to implement than API changes.

(I just hope that doctest doesn't rely on the message texts.)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Sep 23 2009)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
Python-Dev mailing list
Python-Dev@python.org
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

[Michael Foord]

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 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?
  

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
out the problem with either error message. The only help is if you are
trying to debug a type, but I am willing to bet most of us didn't know
the distinction at the C level until David looked it up.

So I am +1 on unified the message and +1 on using the "does not
support indexing" one.



+1 as well.
  


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.


Michael


Note that the wording of error message has never been something
we guaranteed backwards compatibility for, so such changes are a
lot easier to implement than API changes.

(I just hope that doctest doesn't rely on the message texts.)

  



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] thinking about 2.7

[Michael Foord]

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 weeks to avoid 2.x having features which 3.x
doesn't. If no one has problems with this, I will draft a schedule.

  

Yes. Does this mean you are volunteering to be the 3.2 release
manager? Or simply prodding for volunteers? If it's the former are you
at all worried about burn-out from doing two release so close together
and being on the hook for two point releases at roughly the same time
for about two years after?



While I certainly wouldn't mind doing only 2.7, I don't know how we
could preserve everyone's sanity and release them at about the same
time. 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.

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?


Michael


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
would leave me with just 3.2.x (and maybe another 3.1.x release).

...
  

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 used to do
releases without them, so it's not impossible. Just means you have to
really push the alphas, betas, and RCs.



What do you mean "push"?





  



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
Python-Dev mailing list
Python-Dev@python.org
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]

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 on it.  There is and was no 
> need for any of this to get personal, and I have continually strived 
> to keep my posts here and distutils-sig civil, even when I didn't 
> feel like being civil in response to Tarek's jabs.  I have in fact 
> bent over backwards to be *nice* to Tarek, because he seemed so damn 
> sensitive about everything.  Apparently, however, this does not 
> actually help things.

Ok, so Tarek and Philip, are you both ok that those little disagreements should
belong to the past now? :)

Philip did an important job in bringing setuptools to the Python community, and
Tarek took a difficult decision when he finally decided to fork setuptools (he
had probably been privately encouraged for months by people like me, and was
still reluctant to do it AFAICT). Both of you have been tremendously helpful to
Python, and I'm sure we can move forward graciously.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] thinking about 2.7

[Antoine Pitrou]

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 and 3.1.
Indeed, both branches need to be synchronized anyway and the best way to achieve
this is for a single person to overview both of them.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] thinking about 2.7

[Benjamin Peterson]

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
___
Python-Dev mailing list
Python-Dev@python.org
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

[Brett Cannon]

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
said that we view exception messages as something that can change in
minor releases and that you should be very careful if you ever use
them in tests.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] thinking about 2.7

[Brett Cannon]

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 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.
>>>
>>
>> Yes. Does this mean you are volunteering to be the 3.2 release
>> manager? Or simply prodding for volunteers? If it's the former are you
>> at all worried about burn-out from doing two release so close together
>> and being on the hook for two point releases at roughly the same time
>> for about two years after?
>
> While I certainly wouldn't mind doing only 2.7, I don't know how we
> could preserve everyone's sanity and release them at about the same
> time. 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.
>

If you are okay with it then that's fine.

> 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
> would leave me with just 3.2.x (and maybe another 3.1.x release).

Well, if you want that to happen you should make that clear now as I
expected you to do the first few micro releases of 2.7.

>
> ...
>>>
>>> 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 used to do
>> releases without them, so it's not impossible. Just means you have to
>> really push the alphas, betas, and RCs.
>
> What do you mean "push"?

Promote.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] thinking about 2.7

[Antoine Pitrou]

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 some core developers that we focus primarily on 3.x after 2.7 is released.

Of course, if a large enough number of core developers want to backport stuff to
2.x, they probably can arrange to do so.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
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

[Brett Cannon]

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 message is more useful. For expert programmers they could figure
>> out the problem with either error message. The only help is if you are
>> trying to debug a type, but I am willing to bet most of us didn't know
>> the distinction at the C level until David looked it up.
>>
>> 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 that).
> The bug David linked to (http://bugs.python.org/issue5760) has a
> preference for subscript because that's what's used elsewhere in the
> language.

That's what's used in the language spec which VERY few people read.
That can use more technical jargon, but I still don't see experienced
programmers having issuesvfiguring out that note being able to index
an object is the same as not being subscriptable. And we can change
the docs as well if needed, but I don't think that is necessary.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] thinking about 2.7

[Benjamin Peterson]

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
>> would leave me with just 3.2.x (and maybe another 3.1.x release).
>
> Well, if you want that to happen you should make that clear now as I
> expected you to do the first few micro releases of 2.7.

I will do the first few 2.7 bug fix releases.

 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 used to do
>>> releases without them, so it's not impossible. Just means you have to
>>> really push the alphas, betas, and RCs.
>>
>> What do you mean "push"?
>
> Promote.

That basically means we will be relying on 3rd party libraries for our
quality control?


-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
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

[Michael Foord]

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 change them. We have always
said that we view exception messages as something that can change in
minor releases and that you should be very careful if you ever use
them in tests.
  


There were a couple and I can only remember the last one he talked 
about. He ran some code with "python -3" that used someone else's 
library and resulted in the following warning, that he felt was cryptic:


   DeprecationWarning: Overriding __eq__ blocks inheritance of __hash__ 
in 3.x


Hmm... not entirely sure how we can make it clearer. There is a great 
blog entry on the subject by Eric Lippert though (Microsoft I'm afraid):


   http://blogs.msdn.com/ericlippert/archive/2006/07/07/659259.aspx

Error messages: diagnostic is preferable to prescriptive

   * Polite: making the user feel like an idiot is very, very bad.
   * Readable: poor grammar and tortured sentence structure is bad.
   * Accurate: error messages must accurately describe the problem.
   * Precise: "Something is wrong" is an accurate error message but not 
a very precise one!
   * Diagnostic but not prescriptive: describe the problem, not the 
solution.


How about (?):

   If you implement equality (__eq__) you should also implement hashing 
(__hash__), it won't be inherited in 3.x.


Although that is prescriptive of course...

Michael

-Brett
  



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] thinking about 2.7

[Brett Cannon]

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 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.


>>>
>>> Yes. Does this mean you are volunteering to be the 3.2 release
>>> manager? Or simply prodding for volunteers? If it's the former are you
>>> at all worried about burn-out from doing two release so close together
>>> and being on the hook for two point releases at roughly the same time
>>> for about two years after?
>>>
>>
>> While I certainly wouldn't mind doing only 2.7, I don't know how we
>> could preserve everyone's sanity and release them at about the same
>> time. 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.
>>
>> 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?

I would say we won't be sure until we are closer to release, but I
would be willing to put money down that it will be.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] thinking about 2.7

[Michael Foord]

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 year period, so that
would leave me with just 3.2.x (and maybe another 3.1.x release).
  

Well, if you want that to happen you should make that clear now as I
expected you to do the first few micro releases of 2.7.



I will do the first few 2.7 bug fix releases.

  

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 used to do
releases without them, so it's not impossible. Just means you have to
really push the alphas, betas, and RCs.


What do you mean "push"?
  

Promote.



That basically means we will be relying on 3rd party libraries for our
quality control?


  
Isn't that the real compatibility test *anyway* - how successful a new 
version of Python is at running all the existing Python code...


Michael

--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
Python-Dev mailing list
Python-Dev@python.org
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

[Brett Cannon]

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 messages was a sore
>>> point
>>> with him.
>>>
>>
>> Do you know which error messages? We can change them. We have always
>> said that we view exception messages as something that can change in
>> minor releases and that you should be very careful if you ever use
>> them in tests.
>>
>
> There were a couple and I can only remember the last one he talked about. He
> ran some code with "python -3" that used someone else's library and resulted
> in the following warning, that he felt was cryptic:
>
>   DeprecationWarning: Overriding __eq__ blocks inheritance of __hash__ in
> 3.x
>
> Hmm... not entirely sure how we can make it clearer. There is a great blog
> entry on the subject by Eric Lippert though (Microsoft I'm afraid):
>
>   http://blogs.msdn.com/ericlippert/archive/2006/07/07/659259.aspx
>
> Error messages: diagnostic is preferable to prescriptive
>
>   * Polite: making the user feel like an idiot is very, very bad.
>   * Readable: poor grammar and tortured sentence structure is bad.
>   * Accurate: error messages must accurately describe the problem.
>   * Precise: "Something is wrong" is an accurate error message but not a
> very precise one!
>   * Diagnostic but not prescriptive: describe the problem, not the solution.
>
> How about (?):
>
>   If you implement equality (__eq__) you should also implement hashing
> (__hash__), it won't be inherited in 3.x.
>
> Although that is prescriptive of course...

So the original makes sense if you are implementing an object's
comparison operator. But if you are not it won't make much sense,
although if you are not implementing it then it shouldn't be your
concern. Then again, if you are trying to upgrade your code and some
library you used has not, I can see how that message would throw you
for a loop.

So +0 on your specific improvment and +1 for trying to think about
newbies when writing exception messages.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
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é]

(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 to convince them.

So we asked you to bless someone else that was active (not in particular me
as your mail seem to say) but you did not. So we forked. And people were
pissed off at you. (Which I am sorry about)

If a project is not maintained and if the maintainer does not open it to
other maintainers, that s the way to go .

And the fact that I took the lead of that fork doesn't mean I am offended
because you did not bless me to maintain setuptools. It just means that I
want to move forward and have a working tool for python 3.

So let me make it clear that when you say "Tarek appears" it is something I
have never said but rather something you are thinking like being the truth.

Now for the Distribute work , your patches are very welcome. It s a
community project.

On Sep 23, 2009 10:47 PM, "P.J. Eby"  wrote:

At 07:00 PM 9/23/2009 +0200, Tarek Ziadé wrote: > > While it's great to have
Philipp being part of o...
Here's what actually happened, if anyone cares.  Tarek and friends announced
a fork of setuptools.  I reviewed the work and saw that -- for the most part
-- I was happy with it, and opined as how I might be willing to bless the
the "package inquisition" team as official maintainers of the 0.6 branch of
setuptools, so that I could work on the fun bits I've long planned for 0.7,
but never felt free to start on while there was so much still needing to be
done on 0.6.

However, just as I mentioned this, and suggested an option for what I could
do that would be helpful to his Distribute 0.7 project as well as various
other tools (e.g. implementing some of Jim Fulton's long-requested features
for better modularization of setuptools), Tarek accused me of somehow trying
to undermine his plans.

In addition, it appears Tarek was also offended by my earlier statement that
there were only a few people in the Python community who had *already*
earned my implicit trust to not only hack on setuptools unsupervised, but
also to take over its *future* direction and BDFL-ship.  (For example, Jim
Fulton and Ian Bicking.)

Tarek, however, appears to have taken this to mean that I personally thought
he was an incompetent programmer or something (when I actually had no
opinion one way or the other), and ever since he has taken to levelling
potshots like the above at me on a semi-regular basis.

I've tried to ignore this and play nice, because he is actually working on
this stuff and I am not.  But it's hard for me to actually give any help in
practice, if Tarek is too busy projecting hidden plots onto everything I say
and do.

If you read Tarek's distutils-sig posts, it appears my already-existing
trust in Ian and Jim was not only a personal insult to Tarek, but also a
plot to ensure that nobody with any time to do so would ever work on
setuptools, just as my excitement about working on setuptools again was a
plot to steal thunder from his fork.

All I want is for good stuff to happen for setuptools users and Python users
in general, so I don't think all the suspicion and backbiting is merited.  I
certainly don't appreciate it, and I would like it to stop.  It also isn't
even relevant to the thread, since my lack of work on setuptools says
exactly zero about the merits or lack thereof of Tarek's proposals for the
distutils!

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 on it.  There is and was no need for any of this
to get personal, and I have continually strived to keep my posts here and
distutils-sig civil, even when I didn't feel like being civil in response to
Tarek's jabs.  I have in fact bent over backwards to be *nice* to Tarek,
because he seemed so damn sensitive about everything.  Apparently, however,
this does not actually help things.  :-(
___
Python-Dev mailing list
Python-Dev@python.org
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é]

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 an important job in bringing setuptools to the Python community,
and
Tarek took a difficult decision when he finally decided to fork setuptools
(he
had probably been privately encouraged for months by people like me, and was
still reluctant to do it AFAICT). Both of you have been tremendously helpful
to
Python, and I'm sure we can move forward graciously.

Regards

Antoine.

___ Python-Dev mailing list
Python-Dev@python.org http...
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] thinking about 2.7

[Raymond Hettinger]

[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://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] thinking about 2.7

[Michael Foord]

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.com/
http://www.voidspace.org.uk/blog


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] thinking about 2.7

[Benjamin Peterson]

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.


-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] thinking about 2.7

[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 detecting bugs for
us that our test suite could have shown on a platform.


  
Well, Trent Nelson is going to devote some real time to Snakebite - so 
there is a very good chance that it will be up and active before the 
release. Naturally I agree it would be *preferable* to run tests on all 
supported platforms prior to release.


Michael

--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] thinking about 2.7

[Benjamin Peterson]

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 detecting bugs for
>> us that our test suite could have shown on a platform.
>>
>>
>>
>
> Well, Trent Nelson is going to devote some real time to Snakebite - so there
> is a very good chance that it will be up and active before the release.
> Naturally I agree it would be *preferable* to run tests on all supported
> platforms prior to release.

Could I inquiry about your source of this information?



-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] thinking about 2.7

[Michael Foord]

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 3rd party code to be detecting bugs for
us that our test suite could have shown on a platform.



  

Well, Trent Nelson is going to devote some real time to Snakebite - so there
is a very good chance that it will be up and active before the release.
Naturally I agree it would be *preferable* to run tests on all supported
platforms prior to release.



Could I inquiry about your source of this information?



  
From Trent on the snakebite mailing list. Too late for me to look it up 
though; an exercise I leave to the reader.


Michael

--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
Python-Dev mailing list
Python-Dev@python.org
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

[Steven D'Aprano]

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 that). The bug David linked to
> (http://bugs.python.org/issue5760) has a preference for subscript
> because that's what's used elsewhere in the language.

For what it's worth, "unsubscriptable object" seems to me to be 
mysterious to many newbies, and even a few non-newbies. It took me 
something like seven years of coding to stop reading it 
as "unscriptable object", and I'm sure I won't be the only one.

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.



-- 
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@python.org
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

[Janzert]

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 shed
>> discussion at that). The bug David linked to
>> (http://bugs.python.org/issue5760) has a preference for subscript
>> because that's what's used elsewhere in the language.
> 
> For what it's worth, "unsubscriptable object" seems to me to be 
> mysterious to many newbies, and even a few non-newbies. It took me 
> something like seven years of coding to stop reading it 
> as "unscriptable object", and I'm sure I won't be the only one.
> 
> 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.
> 
> 
> 

How about if it's obj["item"]? To me the following makes complete sense,
but then it seems that I may just be the odd one out.

>>> class A(object):
... pass
...
>>> a = A()
>>> a[1]
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'A' object is unindexable
>>> a["a"]
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'A' object is unsubscriptable
>>>

Janzert

___
Python-Dev mailing list
Python-Dev@python.org
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 Lyon]

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 want to
> put such a configuration file up on PyPI.
> 
> Wouldn't it be better use a new file for this (with the
> same syntax), e.g. metadata.cfg ?! This would then just
> contain the meta data that needs to be published.

Forgive me if I answer this from being on the distutils-ml
but it is easy to answer and might save somebody else time.

Currently, the metadata is stored within setup.py and the
biggest issue with that is maintaining the version number.
For instance, getting the same version number to go into the
documentation files, etc. So consensus was that keeping that 
information in setup.py is somewhat cumbersome and putting
it somewhere else would be better. Tarek suggested setup.cfg
and it seems to make the most sense.

By moving the metadata values into a configParser format file, 
it would mean that external scripts could more easily 
access/update the version number as required.

Of course, setup.cfg wouldn't get uploaded. Nobody would
want to do that.

But distutils would create the .PKG_INFO file and metadata
from configuration, and not from hardcoded string values
within setup.py as it does now.

David





___
Python-Dev mailing list
Python-Dev@python.org
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

[Ben Finney]

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]’ the item at *key*
‘i’, if ‘obj’ is a dictionary. For an object that supports neither
indexes nor keys, though, how is Python to know which the user meant?
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”.

Your point about the awkward word “unsubscriptable” is well-taken,
though. Perhaps a simple improvement to the message wording:

>>> foo = 3
>>> foo[6]
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'int' object does not support subscripts
>>> foo['spam']
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'int' object does not support subscripts

-- 
 \  “I lost a button-hole.” —Steven Wright |
  `\   |
_o__)  |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] thinking about 2.7

[Eric Smith]

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 should have expect 3rd party code to be detecting bugs for
us that our test suite could have shown on a platform.



  
Well, Trent Nelson is going to devote some real time to Snakebite - 
so there

is a very good chance that it will be up and active before the release.
Naturally I agree it would be *preferable* to run tests on all supported
platforms prior to release.



Could I inquiry about your source of this information?



  
 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

Eric.

___
Python-Dev mailing list
Python-Dev@python.org
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

[MRAB]

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 bike shed
discussion at that). The bug David linked to
(http://bugs.python.org/issue5760) has a preference for subscript
because that's what's used elsewhere in the language.
For what it's worth, "unsubscriptable object" seems to me to be 
mysterious to many newbies, and even a few non-newbies. It took me 
something like seven years of coding to stop reading it 
as "unscriptable object", and I'm sure I won't be the only one.


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.






How about if it's obj["item"]? To me the following makes complete sense,
but then it seems that I may just be the odd one out.


class A(object):

... pass
...

a = A()
a[1]

Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'A' object is unindexable

a["a"]

Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'A' object is unsubscriptable


I prefer "index" to "subscript" and "does not support foo" or "cannot be
fooed" to "is unfooable" (because, to me, "not" is more explicit than
"un-"). I also prefer the same term to be used irrespective of the
value used.
___
Python-Dev mailing list
Python-Dev@python.org
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

[MRAB]

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 also call ‘obj[i]’ the item at *key*
‘i’, if ‘obj’ is a dictionary. For an object that supports neither
indexes nor keys, though, how is Python to know which the user meant?
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”.

Your point about the awkward word “unsubscriptable” is well-taken,
though. Perhaps a simple improvement to the message wording:

>>> foo = 3
>>> foo[6]
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'int' object does not support subscripts
>>> foo['spam']
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'int' object does not support subscripts


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+value! :-)
___
Python-Dev mailing list
Python-Dev@python.org
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

[Antoine Pitrou]

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+value! 

Well, "index" for me points to the mathematical notion of an index, which AFAIK
is always numeric. So it would be a mistake to use that term for dicts.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
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

[Guido van Rossum]

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 unfortunate
>> that dicts have keys+value instead of index+value!
>
> Well, "index" for me points to the mathematical notion of an index, which 
> AFAIK
> is always numeric. So it would be a mistake to use that term for dicts.

'Key' and 'index' refer to semantics. 'Subscript' refers to syntax.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
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

[Greg Ewing]

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 heading in the docs.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
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

[Greg Ewing]

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 __op__ method?

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
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

[Greg Ewing]

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 that is at best a metaphor when
applied to a language written linearly.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] thinking about 2.7

[Nick Coghlan]

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
have to check my settings.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
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

[P.J. Eby]

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 the other 
way around.  (For example, you described one of my proposals as 
"suspicious", in a context that made it appear you were concerned it 
would undermine your plans for Distribute.)


However, I find it "suspicious" myself, that, rather than actually 
address *any* of the substantial issues I brought up, you chose to 
re-argue points I'm not even disputing.


For example, is it really necessary to make *every* post of yours 
that mentions me include an essay on how long it's been since the 
last setuptools release?  As I said below, I don't see how that's 
remotely relevant to the value of my contributions...  but somehow 
you find a way to bring it up constantly.


Do you feel so guilty about forking that you need to continually 
re-justify yourself?  If you're doing it on my account, do please 
stop.  AFAIR, I haven't said a negative thing about your fork since 
it got off the ground, and have in fact said many positive things 
about it.  Indeed, the only negative thing I would currently say 
about it, is that your characterization of it as a "friendly" fork is 
not consistent with your public behavior and demeanor towards me.


Once again, I'd like for the badgering to stop.  Thanks.

At 12:40 AM 9/24/2009 +0200, Tarek Ziadé wrote:
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 to 
convince them.


So we asked you to bless someone else that was active (not in 
particular me as your mail seem to say) but you did not. So we 
forked. And people were pissed off at you. (Which I am sorry about)


If a project is not maintained and if the maintainer does not open 
it to other maintainers, that s the way to go .


And the fact that I took the lead of that fork doesn't mean I am 
offended because you did not bless me to maintain setuptools. It 
just means that I want to move forward and have a working tool for python 3.


So let me make it clear that when you say "Tarek appears" it is 
something I have never said but rather something you are thinking 
like being the truth.


Now for the Distribute work , your patches are very welcome. It s a 
community project.


On Sep 23, 2009 10:47 PM, "P.J. Eby" 
<p...@telecommunity.com> wrote:


At 07:00 PM 9/23/2009 +0200, Tarek Ziadé wrote: > > While it's 
great to have Philipp being part of o...
Here's what actually happened, if anyone cares.  Tarek and friends 
announced a fork of setuptools.  I reviewed the work and saw that 
-- for the most part -- I was happy with it, and opined as how I 
might be willing to bless the the "package inquisition" team as 
official maintainers of the 0.6 branch of setuptools, so that I 
could work on the fun bits I've long planned for 0.7, but never 
felt free to start on while there was so much still needing to be done on 0.6.


However, just as I mentioned this, and suggested an option for what 
I could do that would be helpful to his Distribute 0.7 project as 
well as various other tools (e.g. implementing some of Jim Fulton's 
long-requested features for better modularization of setuptools), 
Tarek accused me of somehow trying to undermine his plans.


In addition, it appears Tarek was also offended by my earlier 
statement that there were only a few people in the Python community 
who had *already* earned my implicit trust to not only hack on 
setuptools unsupervised, but also to take over its *future* 
direction and BDFL-ship.  (For example, Jim Fulton and Ian Bicking.)


Tarek, however, appears to have taken this to mean that I 
personally thought he was an incompetent programmer or something 
(when I actually had no opinion one way or the other), and ever 
since he has taken to levelling potshots like the above at me on a 
semi-regular basis.


I've tried to ignore this and play nice, because he is actually 
working on this stuff and I am not.  But it's hard for me to 
actually give any help in practice, if Tarek is too busy projecting 
hidden plots onto everything I say and do.


If you read Tarek's distutils-sig posts, it appears my 
already-existing trust in Ian and Jim was not only a personal 
insult to Tarek, but also a plot to ensure that nobody with any 
time to do so would ever work on setuptools, just as my excitement 
about working on setuptools again was a plot to steal thunder from his fork.


All I want is for good stuff to happen for setuptools users and 
Python users in general, so I don't think all the suspicion and 
backbiting is merited.  I certainly don't appreciate it, and I 
would like it to stop.  It also isn't even rele

Re: [Python-Dev] operator precedence of __eq__, __ne__, etc, if both object have implementations

[Guido van Rossum]

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__" when there is no concept of an
> __rop__ method distinct from the __op__ method?

This is a constraint on types implemented in C -- the same definition
is required to apply to __op__ and __rop__.

The datetime module actually has a slight problem here because it
wants to override datetime - timedelta but not timedelta - datetime
(since the latter would have to return a negative time, which is
meaningless). It solves this easily by doing a type check on each
argument and returning Py_NotImplemented for the unimplemented
combinations -- see the various _subtract functions in
Modules/datetimemodule.c. Returning NotImplemented is close enough to
not actually implementing the method.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
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

[Nick Coghlan]

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 (and I believe
indicates that we're susceptible to issuing false alarms in this case).
You really only need to override __hash__ if you want your object to
remain hashable, but we currently issue the warning for any object that
defines __eq__ without defining __hash__.

Perhaps the implementation of that warning should be improved so that it
is only issued if the default __hash__  implementation is actually
invoked on an affected object? (the downside is that depending on the
implementation technique the extra checks may slow down hashing under
"python -3", but I guess that kind of the undesirable impact is the
reason we have all those warnings switched off by default)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
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

[Guido van Rossum]

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/)
___
Python-Dev mailing list
Python-Dev@python.org
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

[Nick Coghlan]

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 alone.  But I'm
>> sure we have other tests which cover this as well just not as exhaustively.
>> We could also possibly check in the baseline file and then CPython could
>> compare it's self to previous versions but it'd probably be a pretty
>> big file - so it probably shouldn't be included in the standard install
>> in the tests directory.
> 
> How big is big?  For comparison, CPython's Lib/test/decimaltestdata
> directory alone is already over 4Mb, so maybe size isn't an issue?

For big test files, there's also the option of including download logic
in the test to go retrieve it from a known URL (I believe we already do
that for some of the codec tests).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
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

[Nick Coghlan]

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 the distutils list: the
abbreviation "py" shouldn't be used to refer to the Python interpreter
as it is somewhat ambiguous due to the existence of the independent "py"
package [1]. The longer "python_version" has a genuine advantage in
clarity here.

Cheers,
Nick.

[1] http://codespeak.net/py/dist/index.html

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
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

[Nick Coghlan]

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 the distutils list: the
abbreviation "py" shouldn't be used to refer to the Python interpreter
as it is somewhat ambiguous due to the existence of the independent "py"
package [1]. The longer "python_version" has a genuine advantage in
clarity here.

Cheers,
Nick.

[1] http://codespeak.net/py/dist/index.html

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
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

[P.J. Eby]

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 "once again" above instead of, "One last 
time", is because I didn't want to be misconstrued as making some 
sort of threat.  However, I can assure you, the above is the very 
last time I will make that request.


In any case, I hadn't yet seen the message of Tarek's you allude to 
above, in large part because it wasn't actually *addressed* to 
me.  It went out only to Python-Dev, whereas the message calling me 
paranoid went straight to my inbox.


I doubt that it was intentional on Tarek's part (checking the thread 
shows that Antoine's the one who first cut the cc: list), but the 
fact remains that I hadn't seen it when I sent my 
message.  Otherwise, I'd have replied in *that* thread, rather than this one.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] thinking about 2.7 / buildbots / testing

[David Lyon]

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 to be small, but since finding dedicated people can sometimes be 
> challenging, I think small teams are the most likely outcome (possibly 
> resulting in a team of one).  

> ..

> Casual volunteers generally just won't keep up with these tasks.

True.

> I suggest finding someone who's seriously interested in the quality of 
> CPython and giving them the responsibility of keeping things operating 
> properly.  This includes paying attention to the status of slaves, 
> cajoling hardware operators into bringing hosts back online and fixing 
> network issues, and finding replacements of the appropriate type 
> (hardware/software platform) when a slave host is permanently lost.

Well, I'm a system administrator now, and a casual developer.

Yes, you need somebody who watches machine control panels and can
type emails on python lists at the same time.

> I would also personally recommend that this person first (well, after 
> tracking down all the slave operators and convincing them to bring their 
> slaves back online) acquire shell access to all of the slave machines so 
> that the owners of the slave hosts themselves no longer need to be the 
> gating factor for most issues.

Depends on where the machines are. There are good tools do check all
automatically. Nagios is one.

Anyway, this would suite my work schedule for the next 12 months.

Do we already have the machines? or do they need to be acquired?

David



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] thinking about 2.7 / buildbots / testing

[C. Titus Brown]

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 back online) acquire shell access to all of the slave machines so 
> > that the owners of the slave hosts themselves no longer need to be the 
> > gating factor for most issues.
> 
> Depends on where the machines are. There are good tools do check all
> automatically. Nagios is one.
> 
> Anyway, this would suite my work schedule for the next 12 months.
> 
> Do we already have the machines? or do they need to be acquired?

Hi David,

as Brett leaked, I am developing software towards making this buildbot
dilemma easier to deal with.  It's not really ready for primetime yet;
I'll send you a link off-list.

I am also (physically) hosting Snakebite, which Trent Nelson will be
tackling over the next few months.

And, finally, I now have Windows VMs (XP, Vista, 7) and a Mac OS X box
that I can dedicate to Python purposes.  I even have a student that will
be monitoring those boxes.  I am happy to give you access to these
machines if you want to set up buildbot on them; buildbot is compatible
with my own endeavors, so that would actually help me out ;)

I will be buying more/better/bigger Linux hardware over the next few
months, too, and I am happy to slice that off to provide more VMs --
basically whatever x86-based platforms people think are needed.

cheers,
--titus
-- 
C. Titus Brown, c...@msu.edu
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com