I think it's fine to remove 3-arg pow() from the ABC; implementations
are of course free to provide it.
Raymond, why don't you cook up a patch? It should patch both the PEP
and numbers.py.
On Wed, Jun 4, 2008 at 8:44 PM, Mark Dickinson <[EMAIL PROTECTED]> wrote:
> On Sun, Jun 1, 2008 at 2:15 AM,
On Sun, Jun 1, 2008 at 2:15 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Proposal
>
> Remove non-essential abstract methods like __index__, three argument
> __pow__,
> __lshift__, __rlshift__, __rshift__, __rrshift__, __and__, __rand__,
> __xor__,
> __rxor__, __or__, __ror__, and __
There are 2 disparate approaches to clearing/compacting free lists for
basic types:
- APIs of the form Py_ClearFreeList() called from gc.collect()
[class, frame, method, tuple & unicode types];
- APIs of the form Py_CompactFreeList() called from
sys._compact_freelists() [int & float types];
On Thu, 5 Jun 2008 11:48:07 am Greg Ewing wrote:
> Nick Coghlan wrote:
> > - remove support for passing a single value to a format string
> > without wrapping it in an iterable first
>
> But won't that clobber a large number of the simple
> use cases that you want to keep %-formatting for?
Yes, I
Nick Coghlan wrote:
- remove support for passing a single value to a format string without
wrapping it in an iterable first
But won't that clobber a large number of the simple
use cases that you want to keep %-formatting for?
--
Greg
___
Python-Dev
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| From: "Guido van Rossum" <[EMAIL PROTECTED]>
| > Unless more folks actually say they agree I don't want to go forward
| > with this. There was quite a bit of discussion about PEP 3141 and it
| > was accepted; striki
Please, please, please: Keep the % formatting!
In 99% of the Python code I have seen,
the str.format wouldn't gain any advantage
(not even regarding the code readability).
Yes, there may be special cases where str.format
offers more flexibility, but until now I never missed
anything in the % for
On Wed, Jun 4, 2008 at 12:57 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
> Not sure how to generate more discussion. It seems self-evident
> that an abc with lots of abstract methods is inherently less usable
> and that bitwise operations go beyond the basic notion of "integeriness".
> Requ
Given the lack of responses to my questions, let's reject this.
--
--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://ma
On Wed, Jun 4, 2008 at 12:57 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> From: "Guido van Rossum" <[EMAIL PROTECTED]>
>>
>> Unless more folks actually say they agree I don't want to go forward
>> with this. There was quite a bit of discussion about PEP 3141 and it
>> was accepted; striking t
From: "Antoine" <[EMAIL PROTECTED]
For me the problem is not about ditching the % operator for an
intuitively-named method like format(). It's the format syntax which has
become much more complicated and error-prone without any clear advantage.
It's seems that way to me too. But, it may be on
From: "Guido van Rossum" <[EMAIL PROTECTED]>
Unless more folks actually say they agree I don't want to go forward
with this. There was quite a bit of discussion about PEP 3141 and it
was accepted; striking this much from it with virtually no discussion
seems wrong to me.
Not sure how to generat
Sounds good. (Maybe you want to contribute a patch to threading.py?
Your implementation notes are important. It could be quite independent
from PEP 371.)
On Wed, Jun 4, 2008 at 3:33 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Jesse Noller wrote:
>>
>> Per feedback from Guido, the python-dev list
I haven't seen anyone applaud either.
Unless more folks actually say they agree I don't want to go forward
with this. There was quite a bit of discussion about PEP 3141 and it
was accepted; striking this much from it with virtually no discussion
seems wrong to me.
Jeffrey made a good point: .nume
Because .numerator and .denominator are defined by the Rational ABC,
and Integral inherits from that, removing them from Integral is a
larger change than removing the other methods. You'd have to remove
them from Rational or break the inheritance relation.
Removing the bitwise operators sounds fin
> Antoine Pitrou wrote:
>>
>> Not to mention that e.g. "%r" % s is much simpler than "{0!r}".format(s)
>> (if I got the format spec right).
>
> repr(s) is even simpler :)
Yes, of course, but in the non-trivial case, e.g. "value=%r" % my_value,
it's much easier to use %-style formatting than playin
On Wed, 4 Jun 2008 11:28:40 pm Nick Coghlan wrote:
> > Not to mention that e.g. "%r" % s is much simpler than
> > "{0!r}".format(s) (if I got the format spec right).
>
> repr(s) is even simpler :)
Fair enough, and I see your smiley, but consider:
"X %r X" % s
"X {0!r} X".format(s)
"X " + repr(
Antoine Pitrou wrote:
Michael Foord voidspace.org.uk> writes:
Simple string formatting with %s and a single object or a tuple meets
>90% of my string formatting needs.
Not to mention that e.g. "%r" % s is much simpler than "{0!r}".format(s)
(if I got the format spec right).
repr(s) is even
2008/6/4 Antoine Pitrou <[EMAIL PROTECTED]>:
> Michael Foord voidspace.org.uk> writes:
>> Simple string formatting with %s and a single object or a tuple meets
>> >90% of my string formatting needs.
>
> Not to mention that e.g. "%r" % s is much simpler than "{0!r}".format(s)
> (if I got the forma
Michael Foord voidspace.org.uk> writes:
> Simple string formatting with %s and a single object or a tuple meets
> >90% of my string formatting needs.
Not to mention that e.g. "%r" % s is much simpler than "{0!r}".format(s)
(if I got the format spec right).
cheers
Antoine.
__
Nick Coghlan wrote:
Martin v. Löwis wrote:
Please don't - not before % is actually deprecated (which I hope won't
happen until Python 4, with removal of % in Python 5, in the year
when I retire, i.e. 2037).
Now this is news to me -- was there a discussion that changed the
lifetime expectancy of
Jesse Noller wrote:
Per feedback from Guido, the python-dev list and others, I have sent
in an updated version of PEP 371 - the inclusion of the pyprocessing
module into the standard library.
URL: http://www.python.org/dev/peps/pep-0371/
New highlights:
* The module will be renamed to "multipr
Martin v. Löwis wrote:
Please don't - not before % is actually deprecated (which I hope won't
happen until Python 4, with removal of % in Python 5, in the year
when I retire, i.e. 2037).
Now this is news to me -- was there a discussion that changed the
lifetime expectancy of str.__mod__? I'd alw
The only comment so far was to keep the __index__ method.
Other than that, is this good to go?
Raymond
- Original Message -
Target: Py2.6 and Py3.0
Author: Raymond Hettinger
Date: May 31, 2008
Motivation
--
The principal purpose of an abstract base class is to support multi
24 matches
Mail list logo
