Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC
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 multiple implementations of an API; thereby allowing one concrete class to be substitutable for another. This purpose is defeated when useful substitutions are precluded because the ABC is too aggressive in its behavioral requirements -- mandating too many methods, mandating methods that are difficult to implement, or too closely following the full API of a single concrete type. The Integral ABC is somewhat extensive and requires essentially every behavior exhibited by the int concrete class. Usefully, it provides for basic integer behaviors like simple arithmetic and ordering relations. However, the current ABC goes beyond that and requires bit-flipping and other operations that are not fundamental to the notion of being an integer. That makes it challenging to define a new Integral class that isn't already an int. Proposal Remove non-essential abstract methods like __index__, three argument __pow__, __lshift__, __rlshift__, __rshift__, __rrshift__, __and__, __rand__, __xor__, __rxor__, __or__, __ror__, and __invert__, numerator, and denominator. Discussion -- The only known use cases for variants of int are types that limit the range of values to those that fit in a fixed storage width. One existing implementation is in numpy which has types like int0, int8, int16, int32, and int16. The numpy integral types implement all the methods present in Integral except for the new methods like __trunc__, __index__, real, imag, conjugate, numerator, and denominator. For the most part, they are fully substitutable into code that expects regular ints; however, they do have wrap-around behaviors such as int8(200)+int8(100) --> int8(44). The wrap-around behaviors make the numpy types totally unsuitable for some applications of Integral such as the fractions module which accepts any integral numerator and denominator. ___ 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/python%40rcn.com ___ 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] converting the stdlib to str.format
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 always supposed it being deprecated at some point in 3.x. The PEP doesn't specify anything, and I don't recall any discussion, either - the specific timing suggested above is merely my own hopes. While str.format has an awful lot of points in its favour (no tuple/dict special casing, much cleaner handling of named arguments, access to format options for non-builtin types), there are some debugging cases where I suspect the basic version of % formatting will prove to be more convenient. At this point in time, my personal preference would be that later in the 3.x series certain aspects of % formatting will be deprecated (acceptance of non-tuples in favour of the format() builtin, acceptance of dicts in favour of str.format), but that simple % formatting of a tuple of values will still be permitted. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.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] PEP 371: Additional Discussion
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 "multiprocessing" * The API will become PEP 8 compliant My 2 cents on this: PEP 8 compliance in the multiprocessing API is a good idea, but threading should be updated at the same time to provide PEP 8 compliant aliases for the existing names. Using the old Java-based names should provoke a Py3k warning in 2.6 (note: to avoid a runtime performance hit when not using -3, the actual function definitions should be made conditional, rather than checking whether or not to emit the warning every time the legacy API is invoked) The PyGILState_* bug in debug builds that RMO pointed out should also be mentioned in the PEP as something that needs to be fixed in order to implement the PEP. Cheers, Nick. [1] http://bugs.python.org/issue1683 -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.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] converting the stdlib to str.format
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 str.__mod__? I'd always supposed it being deprecated at some point in 3.x. The PEP doesn't specify anything, and I don't recall any discussion, either - the specific timing suggested above is merely my own hopes. While str.format has an awful lot of points in its favour (no tuple/dict special casing, much cleaner handling of named arguments, access to format options for non-builtin types), there are some debugging cases where I suspect the basic version of % formatting will prove to be more convenient. At this point in time, my personal preference would be that later in the 3.x series certain aspects of % formatting will be deprecated (acceptance of non-tuples in favour of the format() builtin, acceptance of dicts in favour of str.format), but that simple % formatting of a tuple of values will still be permitted. +1 Simple string formatting with %s and a single object or a tuple meets >90% of my string formatting needs. Michael Foord Cheers, Nick. ___ 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] converting the stdlib to str.format
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.
___
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] converting the stdlib to str.format
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 format spec right).
repr(s) is simpler still, and doesn't break if s is a tuple :-)
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] converting the stdlib to str.format
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 simpler :)
The basic idea for conversions to the new formatting:
'%r' % v --> repr(v) # or ascii(v) if more appropriate
'%s' % v --> str(v) # or format(v), or format(v, '')
The str/unicode stability that the latter provided in 2.x is no longer
needed in 3.x. The first one never had any advantage that I can see over
invoking repr() directly (since repr() and %r always produce an 8-bit
string in 2.x)
The conversion of fmt % v depends on both fmt and v:
v is a single value, fmt is only a formatting code:
'%x' % v--> format(v, 'x')
v is a single value, fmt is both a formatting code and additional text:
'Value: %x' % v--> 'Value: {0:x}'.format(v)
Note that the old code in this case wouldn't display dict or tuple
instances correctly. Avoiding that ambiguity is a major advantage of the
new approach.
v is a tuple* (more on this below):
'Key: %s Value: %s' % k, v --> 'Key: {0} Value: {1}'.format(k, v)
fmt uses named parameters:
'Value: %(val)s' % dict(val=v) --> 'Value: {val}'.format(val=v)
* I still think the new str.format approach is too verbose and requires
too much thought for simple use cases where the printf-style %
replacement hits a sweet spot between being easy to write and easy to read.
So I see the introduction of str.format in 3.0 as an opportunity to
*fix* %-formatting later in the 3.x series rather than get rid of it
entirely. The fixes I would apply:
- remove support for %(name)s based formatting (str.format is vastly
superior once you start naming the parameters).
- remove support for passing a single value to a format string without
wrapping it in an iterable first
- accept any iterable as the right hand argument str.__mod__
This approach would eliminate the current ambiguity in fmt.v, and would
allow fmt % [x] to be used to box an argument for safe use in a
single-parameter format string instead of having to muck around with
singleton tuples.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.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] converting the stdlib to str.format
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(s) + " X"
I for one am excited to see advanced string formatting via .format(),
but would be very disappointed if future Python versions removed the
simplicity of %.
--
Steven
___
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] converting the stdlib to str.format
> 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 playing with repr() and
the other string formatting facilities.
> Note that the old code in this case wouldn't display dict or tuple
> instances correctly. Avoiding that ambiguity is a major advantage of the
> new approach.
I know. 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.
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] Mini-Pep: Simplifying the Integral ABC
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 fine to me. On Wed, Jun 4, 2008 at 1:54 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > 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 multiple >> implementations of an API; thereby allowing one concrete class to be >> substitutable for another. This purpose is defeated when useful >> substitutions >> are precluded because the ABC is too aggressive in its behavioral >> requirements >> -- mandating too many methods, mandating methods that are difficult to >> implement, or too closely following the full API of a single concrete >> type. >> >> The Integral ABC is somewhat extensive and requires essentially every >> behavior >> exhibited by the int concrete class. Usefully, it provides for basic >> integer >> behaviors like simple arithmetic and ordering relations. However, the >> current >> ABC goes beyond that and requires bit-flipping and other operations that >> are >> not fundamental to the notion of being an integer. That makes it >> challenging >> to define a new Integral class that isn't already an int. >> >> Proposal >> >> Remove non-essential abstract methods like __index__, three argument >> __pow__, >> __lshift__, __rlshift__, __rshift__, __rrshift__, __and__, __rand__, >> __xor__, >> __rxor__, __or__, __ror__, and __invert__, numerator, and denominator. >> >> Discussion >> -- >> The only known use cases for variants of int are types that limit the >> range of >> values to those that fit in a fixed storage width. >> >> One existing implementation is in numpy which has types like int0, int8, >> int16, int32, and int16. The numpy integral types implement all the >> methods >> present in Integral except for the new methods like __trunc__, __index__, >> real, imag, conjugate, numerator, and denominator. For the most part, >> they >> are fully substitutable into code that expects regular ints; however, they >> do >> have wrap-around behaviors such as int8(200)+int8(100) --> int8(44). The >> wrap-around behaviors make the numpy types totally unsuitable for some >> applications of Integral such as the fractions module which accepts any >> integral numerator and denominator. >> >> ___ >> 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/python%40rcn.com > > ___ > 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/jyasskin%40gmail.com > -- Namasté, Jeffrey Yasskin http://jeffrey.yasskin.info/ ___ 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] Mini-Pep: Simplifying the Integral ABC
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: .numerator and .denominator need to be kept in the interface. I really don't want to divorce Integer from Rational. They're trivial to implement, and I won't complain if you leave them unimplemented while claiming conformance. :-) My position: I'm -1 on removing __index__, numerator, denominator, and on removing anything you didn't mention explicitly. You used the phrase "methods like", which seems inappropriate for a specification. Note also that these happen to be concrete methods, not abstract ones like you claim. I'm -0 on removing the bitwise operators, i.e. could be swayed by some +1 votes. --Guido On Wed, Jun 4, 2008 at 1:54 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > 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 multiple >> implementations of an API; thereby allowing one concrete class to be >> substitutable for another. This purpose is defeated when useful >> substitutions >> are precluded because the ABC is too aggressive in its behavioral >> requirements >> -- mandating too many methods, mandating methods that are difficult to >> implement, or too closely following the full API of a single concrete >> type. >> >> The Integral ABC is somewhat extensive and requires essentially every >> behavior >> exhibited by the int concrete class. Usefully, it provides for basic >> integer >> behaviors like simple arithmetic and ordering relations. However, the >> current >> ABC goes beyond that and requires bit-flipping and other operations that >> are >> not fundamental to the notion of being an integer. That makes it >> challenging >> to define a new Integral class that isn't already an int. >> >> Proposal >> >> Remove non-essential abstract methods like __index__, three argument >> __pow__, >> __lshift__, __rlshift__, __rshift__, __rrshift__, __and__, __rand__, >> __xor__, >> __rxor__, __or__, __ror__, and __invert__, numerator, and denominator. >> >> Discussion >> -- >> The only known use cases for variants of int are types that limit the >> range of >> values to those that fit in a fixed storage width. >> >> One existing implementation is in numpy which has types like int0, int8, >> int16, int32, and int16. The numpy integral types implement all the >> methods >> present in Integral except for the new methods like __trunc__, __index__, >> real, imag, conjugate, numerator, and denominator. For the most part, >> they >> are fully substitutable into code that expects regular ints; however, they >> do >> have wrap-around behaviors such as int8(200)+int8(100) --> int8(44). The >> wrap-around behaviors make the numpy types totally unsuitable for some >> applications of Integral such as the fractions module which accepts any >> integral numerator and denominator. >> >> ___ >> 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/python%40rcn.com > > ___ > 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] PEP 371: Additional Discussion
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 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 "multiprocessing" >> * The API will become PEP 8 compliant > > My 2 cents on this: PEP 8 compliance in the multiprocessing API is a good > idea, but threading should be updated at the same time to provide PEP 8 > compliant aliases for the existing names. Using the old Java-based names > should provoke a Py3k warning in 2.6 (note: to avoid a runtime performance > hit when not using -3, the actual function definitions should be made > conditional, rather than checking whether or not to emit the warning every > time the legacy API is invoked) > > The PyGILState_* bug in debug builds that RMO pointed out should also be > mentioned in the PEP as something that needs to be fixed in order to > implement the PEP. > > Cheers, > Nick. > > [1] http://bugs.python.org/issue1683 > > -- > Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia > --- >http://www.boredomandlaziness.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/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] Mini-Pep: Simplifying the Integral ABC
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 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". Requiring all those methods to be defined makes it harder to write a compliant class. Other than int/long, no currently existing type matches-up with Integral. Does anyone care about this? If something like numpy's int8 eventually grows the required methods, it is worriesome that the numerator/denominator properties will be automatically supplied for fractions.py to accept as inputs eventhough int8's wrap-around behavior makes them entirely unsuitable. I don't know if this bothers anyone. It would seem that a consumer of an Integral can assume the existence of methods but nothing about whether the result is usable. That might not be a big deal except that numpy is t he only known use case. Hopefully, some discussion gets generated. But if no one cares, I'll happily drop it. 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] converting the stdlib to str.format
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 one of those things that you quickly get used to. 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] Mini-Pep: Simplifying the Integral ABC
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 this much from it with virtually no discussion >> seems wrong to me. > > 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". > Requiring all those methods to be defined makes it harder to write > a compliant class. In general it is good to require that more thought goes into the design and implementation of a class, so that less thought needs to go into using it. > Other than int/long, no currently existing type > matches-up with Integral. Does anyone care about this? Does "this" refer to "the Integral ABC" or "no type matches up with it" ? > If something like numpy's int8 eventually grows the required methods, > it is worrysome that the numerator/denominator properties will be > automatically supplied for fractions.py to accept as inputs eventhough > int8's wrap-around behavior makes them entirely unsuitable. I'm not sure what you mean. This is probably just my lack of imagination. Can you give a small code example where using an int8 with the fractions module would cause problems? The Fraction class appears to be calling __index__ on its arguments, which would convert the int8 to a proper int (or long, in Python 2.6). > I don't > know if this bothers anyone. It would seem that a consumer of an Integral > can assume the existence of methods but nothing about whether the > result is usable. That might not be a big deal except that numpy is t > he only known use case. Any integer type that performs arithmetic modulo some number is problematic. Perhaps a totally separate ABC needs to be defined for this purpose, one that doesn't inherit from Rational. > Hopefully, some discussion gets generated. But if no one cares, I'll > happily drop it. Have you asked the numpy folks? If enough people care, we could easily create a BinaryInteger ABC that defines the bitwise operations. -- --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] Mini-Pep: An Empty String ABC
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://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC
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". > Requiring all those methods to be defined makes it harder to write > a compliant class. > > Other than int/long, no currently existing type > matches-up with Integral. Does anyone care about this? > > Hopefully, some discussion gets generated. But if no one cares, I'll > happily drop it. I'm just responding out of duty to add more discussion on the topic. I think I agree with Raymond on the basic principle that simple ABC's are easier to use than simple ones. Anyway, it's hard to add anything to the discussion when I haven't seen many applications of the Integral ABC, but in principle, but if I had to vote I'd say that the bitwise operators aren't particularly integery. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 signature.asc Description: Digital signature ___ 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] converting the stdlib to str.format
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 % formatting. One thing to keep in mind: What if you have a lot of %-format strings translated and stored them inside a database, for example? If % would be deprecated, these database entries would have to be converted, so you would have to write yet another program to do this. So if the % formating really is going to vanish, then please not before April 2099 (or when Duke Nukem Forever will be released ;-). Just my 0,02 EUR Henning ___ 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] Mini-Pep: Simplifying the Integral ABC
"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; striking this much from it with virtually no discussion | > seems wrong to me. | | 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". On reading PEP3141 some months ago and again today, I thought and still do that all the methods that depend on a 2s-complement representation and implementation really belong to an implentation-defined subclass of Integral. But I am not sure of the purpose of the class and of including such concrete methods in an ABC, and so said nothing ;-). I notice that the similarly implementation-based frexp and ldexp math methods are *not* in the Real class. | Requiring all those methods to be defined makes it harder to write | a compliant class. Other than int/long, no currently existing type | matches-up with Integral. Does anyone care about this? I might some day, for didactic purposes, write integer classes based on prime-factorization or fibonacci representations. I certainly would skip all the 2s-complement methods. But I do not know that I would care much about being 'non-compliant'. | If something like numpy's int8 eventually grows the required methods, | it is worriesome that the numerator/denominator properties will be | automatically supplied for fractions.py to accept as inputs eventhough | int8's wrap-around behavior makes them entirely unsuitable. In my view, the members of residue/remainder classes are not really integers unless their usage is carefully restricted to avoid invocation of the mod operation. Terry Jan Reedy ___ 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] converting the stdlib to str.format
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 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] converting the stdlib to str.format
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 don't particularly see the advantage of writing: "spam %s spam" % (value,) over "spam %s spam" % value Why require the first version? -- Steven ___ 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] wrt the beta deadline and freelist management
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]; Both approaches are new for 2.6 & 3.0. The patch at http://bugs.python.org/issue2862 is geared towards bring the int/float free list management into line with the others. The patch at http://bugs.python.org/issue3029 adds free list management to the dict, list & set types. The value of this is probably minor, and this patch is thus not significant in its own right other than for consistency. However Raymond's comment to issue 3029 that the management routines shouldn't be public APIs is IMO important (& I happen to agree). It would be nice to reduce the 2 approaches to one. I would rather the gc.collect() approach, as this seems to be more obvious to many users who have gone looking for free list management in prior versions, however my opinion isn't particularly valuable on this. Can this be resolved for 2.6/3.0? Regards, Andrew. -- - Andrew I MacIntyre "These thoughts are mine alone..." E-mail: [EMAIL PROTECTED] (pref) | Snail: PO Box 370 [EMAIL PROTECTED] (alt) |Belconnen ACT 2616 Web:http://www.andymac.org/ |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] Mini-Pep: Simplifying the Integral ABC
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 __invert__, numerator, and denominator. > +1 from me. I'd support removing all these, minus the exceptions already pointed out (__index__, numerator, denominator). As a (so far incomplete) effort to speed up the Decimal type I recently implemented a decimal-based integer type; this type would seem a natural candidate to inherit from Integral, but the logical and shift operators above make less sense for this type. The other odd man out here is three-argument pow; this *is* a method that makes sense for integers without reference to the way they're stored. So maybe this should stay. (Though I've occasionally wondered why three-argument pow is part of the core language, rather than being in the standard library.) 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] Mini-Pep: Simplifying the Integral ABC
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, 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 __invert__, numerator, and denominator. > > +1 from me. > I'd support removing all these, minus the exceptions already pointed out > (__index__, numerator, denominator). As a (so far incomplete) effort > to speed up the Decimal type I recently implemented a decimal-based > integer type; this type would seem a natural candidate to inherit > from Integral, but the logical and shift operators above make less sense > for this type. > The other odd man out here is three-argument pow; this *is* a > method that makes sense for integers without reference to the > way they're stored. So maybe this should stay. (Though I've > occasionally wondered why three-argument pow is part of the > core language, rather than being in the standard library.) > 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
