Brett Cannon writes:
> OK, stop before it gets any nastier as your email already sounds
> rude
Rude, yes, but not entirely lacking in truth. Tarek's post to Python-
Dev *is* a mess from the point of view of English and organization --
it's *way* below Tarek's normal command of the language. G
On Tue, Sep 22, 2009 at 23:20, David Lyon wrote:
> On Tue, 22 Sep 2009 22:39:04 -0700, Brett Cannon wrote:
>> I don't think anyone on python-dev thought that it was exclusively
> Tarek's
>> idea or necessarily even mostly his.
>
> Actually, he originally argued against it, but that is irrelevant.
On Tue, 22 Sep 2009 22:39:04 -0700, Brett Cannon wrote:
> I don't think anyone on python-dev thought that it was exclusively
Tarek's
> idea or necessarily even mostly his.
Actually, he originally argued against it, but that is irrelevant.
I'm happy that he's come around and embraced it. Perhaps
On Tue, Sep 22, 2009 at 20:55, David Lyon wrote:
>
> Hello Guido,
>
>> Isn't it clear from Tarek's email that he is summarizing
>> distutils-sig?
>
> Well, I'm new to this. Summarising is a word that could be
> certainly applied.
>
>> Isn't it odd that you ask this question pointing to
>> your own
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.__
R. David Murray wrote:
> Looking at the source, these messages are generated from abstract.c,
> and the difference appears to be whether or not the tp_as_sequence slot
> is filled in or not. If it is, but there is no sq_item method, then
> PySequence_GetItem gives the "does not support indexing" m
Hello Guido,
> Isn't it clear from Tarek's email that he is summarizing
> distutils-sig?
Well, I'm new to this. Summarising is a word that could be
certainly applied.
> Isn't it odd that you ask this question pointing to
> your own message?
It's not odd at all. When I see my ideas, which T
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
David,
Isn't it clear from Tarek's email that he is summarizing
distutils-sig? Isn't it odd that you ask this question pointing to
your own message? Are you worried that you won't get credit for the
idea (assuming it's yours)? Should you perhaps just ask for credit
instead of asking a rhetorical q
Frank wrote:
> > For IronPython we wrote a set of tests which go through and define
> > the various operator methods in all sorts of combinations on both
> > new-style and old-style classes as well as subclasses of those
> classes
> > and then do the comparisons w/ logging.
> We've talked about thi
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
On Tue, Sep 22, 2009 at 5:55 PM, Dino Viehland wrote:
> For IronPython we wrote a set of tests which go through and define
> the various operator methods in all sorts of combinations on both
> new-style and old-style classes as well as subclasses of those classes
> and then do the comparisons w/ l
Tarek,
Are you claiming this as your own work and ideas?
Given:
http://mail.python.org/pipermail/distutils-sig/2009-August/012998.html
Regards
David
On Tue, 22 Sep 2009 15:21:06 +0200, Tarek Ziadé
wrote:
> Hello
>
> Here's a wrapup of the Distutils-SIG discussion
> we had on the "static m
Is there a reason or a rule by which CPython reports different error message
for different failures to subscript?
For example:
>>> set()[2]
Traceback (most recent call last):
File "", line 1, in
TypeError: 'set' object does not support indexing
>>> class c(object): pass
...
>>> c()[2]
Traceba
2009/9/22 Chris Withers :
> Brett Cannon wrote:
>>
>> OK, stop before it gets any nastier as your email already sounds rude,
>> Chris.
>
> Yes, apologies.
Thanks.
>
>> Since the language summit at PyCon 2009 various committers, including
>> me, have been encouraging Tarek to act as distutils dict
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 momen
Brett Cannon wrote:
OK, stop before it gets any nastier as your email already sounds rude, Chris.
Yes, apologies.
Since the language summit at PyCon 2009 various committers, including
me, have been encouraging Tarek to act as distutils dictator to get
things finished as we all know people are
Willem wrote:
>
> It's easy for other implementations to get this wrong. :)
For IronPython we wrote a set of tests which go through and define
the various operator methods in all sorts of combinations on both
new-style and old-style classes as well as subclasses of those classes
and then do the
On Tue, Sep 22, 2009 at 12:51, Chris Withers wrote:
> Tarek Ziadé wrote:
>>
>> Yes, for the syntax bikeshedding on how conditions should be expressed,
>> I have decided I'll be some kind of distutils dictator to end up the
>> endless discussions
>> on how they should be expressed so we can move on
Tarek Ziadé wrote:
Yes, for the syntax bikeshedding on how conditions should be expressed,
I have decided I'll be some kind of distutils dictator to end up the
endless discussions
on how they should be expressed so we can move on.
...except in this case, spelling is important and I'm far from t
At 08:12 PM 9/22/2009 +0200, Tarek Ziadé wrote:
If you are talking about another solution than using setup.cfg with
conditional
expressions, please start a new thread that demonstrates how it will work,
we all want the best solution of course.
I already did that, on the distutils-sig. Or more
--
http://www.ironpythoninaction.com
On 22 Sep 2009, at 19:15, Tarek Ziadé wrote:
On Tue, Sep 22, 2009 at 4:02 PM, Dirkjan Ochtman
wrote:
On Tue, Sep 22, 2009 at 15:55, Michael Foord > wrote:
ConfigParser recognises both, but other tools (*coff* ConfigObj)
only
recognises the latter (=
On Tue, Sep 22, 2009 at 8:12 PM, Tarek Ziadé wrote:
> If you are talking about another solution than using setup.cfg with
> conditional
> expressions, please start a new thread
(in Distutils SIG)
___
Python-Dev mailing list
Python-Dev@python.org
http:/
On Tue, Sep 22, 2009 at 4:02 PM, Dirkjan Ochtman wrote:
> On Tue, Sep 22, 2009 at 15:55, Michael Foord
> wrote:
>> ConfigParser recognises both, but other tools (*coff* ConfigObj) only
>> recognises the latter (=).
>
> So does Mercurial, BTW, because this aspect of ConfigParser was pretty
> anno
2009/9/22 P.J. Eby :
> At 03:21 PM 9/22/2009 +0200, Tarek Ziadé wrote:
>>
>> Hello Here's a wrapup of the Distutils-SIG discussion we had on the
>> "static metadata" topic. I realize that it's a good thing to send in.
>> python-dev such wrapup on distutils design decisions, to keep everyone
>> info
Tarek Ziadé wrote:
On Tue, Sep 22, 2009 at 4:02 PM, Chris Withers wrote:
[setup:python_version == '2.4' or python_version == '2.5']
requires: some_package
As was brought up on the distutils list, this seems unnecessarily
complicated.
Other, simpler, solutions were proposed:
h
On Tue, Sep 22, 2009 at 4:02 PM, Chris Withers wrote:
>> [setup:python_version == '2.4' or python_version == '2.5']
>> requires: some_package
>
> As was brought up on the distutils list, this seems unnecessarily
> complicated.
>
> Other, simpler, solutions were proposed:
>
> http://mail.pyth
On Tue, Sep 22, 2009 at 4:12 PM, Mark Dickinson wrote:
> I'll open an issue for the duplicate __eq__ calls.
http://bugs.python.org/issue6970
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsub
On Tue, Sep 22, 2009 at 15:55, Michael Foord wrote:
> ConfigParser recognises both, but other tools (*coff* ConfigObj) only
> recognises the latter (=).
So does Mercurial, BTW, because this aspect of ConfigParser was pretty
annoying for some of the stuff we try to do (and not at all obvious to
mo
On Tue, Sep 22, 2009 at 5:12 PM, Mark Dickinson wrote:
> - Exception to the previous item: if the left operand is an instance
> of a built-in type or a new-style class, and the right operand is an
> instance of a proper subclass of that type or class AND overrides the
> base’s __rop__() method, th
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 implem
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 whe
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
Hi All,
I didn't see any docs on this:
http://docs.python.org/reference/datamodel.html?highlight=__eq__#object.__eq__
Where are the specifications on what happens if two objects are compared
and both have implementations of __eq__? Which __eq__ is called? What
happens if the first one called
Tarek Ziadé wrote:
The four sentences summary for people in a hurry:
If you're going to promise sentences, please deliver sentences...
Getting metadata of a distribution that is not.
installed means running its setup.py. This means.
downloading the whole archive, and running.
Antoine Pitrou wrote:
Tarek Ziadé gmail.com> writes:
[setup]
name: Foo
version: 1.2
I am probably missing something, but why doesn't it use the more common
ini-style:
[setup]
name = Foo
version = 1.2
ConfigParser recognises both, but other tools (*coff* C
Tarek Ziadé gmail.com> writes:
>
> [setup]
> name: Foo
> version: 1.2
I am probably missing something, but why doesn't it use the more common
ini-style:
[setup]
name = Foo
version = 1.2
Regards
Antoine.
___
Python-Dev maili
At 03:21 PM 9/22/2009 +0200, Tarek Ziadé wrote:
Hello Here's a wrapup of the Distutils-SIG discussion we had on the
"static metadata" topic. I realize that it's a good thing to send
in. python-dev such wrapup on distutils design decisions, to keep
everyone informed and get more feedback when re
On Tue, Sep 22, 2009 at 03:21:06PM +0200, Tarek Ziad? wrote:
> I realize that it's a good thing to send in.
> python-dev such wrapup on distutils design
> decisions, to keep everyone informed and get
> more feedback when required.
Sure it is.
> I will try to do it for every upcoming changes
>
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 ch
40 matches
Mail list logo
