Re: [Python-Dev] str with base
Alex Martelli wrote:
> Is it finally time in Python 2.5 to allow the "obvious" use of, say,
> str(5,2) to give '101', just the converse of the way int('101',1)
> gives 5? I'm not sure why str has never allowed this obvious use --
> any bright beginner assumes it's there and it's awkward to explain
> why it's not!-).
My main concern is what the impact on __str__ would be. It seems
"obvious" that
def str(obj, *args):
return obj.__str__(*args)
because it is ultimately int's responsibility to interpret the base
argument, not str's.
People would then come up with use cases like
class Color:
msg = {'en':['red', 'green', 'blue'], 'de':['rot','grün','blau']}
def __str__(self, language='en'):
return self.msg[language][self.value]
red = Color(0)
so you could say
print str(red, 'de')
I don't think I like this direction.
Regards,
Martin
___
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] str with base
On Tue, 2006-01-17 at 01:03 -0500, Barry Warsaw wrote: > On Mon, 2006-01-16 at 20:49 -0800, Bob Ippolito wrote: > > > The only bases I've ever really had a good use for are 2, 8, 10, and > > 16. There are currently formatting codes for 8 (o), 10 (d, u), and > > 16 (x, X). Why not just add a string format code for unsigned > > binary? The obvious choice is probably "b". > > > > For example: > > > > >>> '%08b' % (12) > > '1100' > > >>> '%b' % (12) > > '1100' > > +1 +1 me too. -- Donovan Baarda <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/ ___ 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] basenumber redux
Alex, I think you're missing a point here: what you are looking
for is an interface, not a base class - simply because the
assumptions you make when finding a "KnownNumberTypes" instance
are only related to an interface you expect them to provide.
A common case class won't really help all that much with this,
since the implementations of the different types will vary a
lot (unlike, for example, strings and Unicode, which implement
a very common interface) and not necessarily provide a common
interface.
If you look at the Python C API, you'll find that "a number"
is actually never tested. The tests always ask for either
integers or floats.
The addition of a basenumber base class won't make these any
simpler.
Here's a snippet which probably does what you're looking for
using Python's natural way of hooking up to an implicit
interface:
import UserString
STRING_TYPES = (basestring, UserString.UserString)
def floatnumber(obj):
if isinstance(obj, STRING_TYPES):
raise TypeError('strings are not numbers')
# Convert to a float
try:
return float(obj)
except (AttributeError, TypeError, ValueError):
raise TypeError('%r is not a float' % obj)
def intnumber(obj):
if isinstance(obj, STRING_TYPES):
raise TypeError('strings are not numbers')
# Convert to an integer
try:
value = int(obj)
except (AttributeError, TypeError, ValueError):
raise TypeError('%r is not an integer' % obj)
# Double check so that we don't lose precision
try:
floatvalue = floatnumber(obj)
except TypeError:
return value
if floatvalue != value:
raise TypeError('%r is not an integer' % obj)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jan 17 2006)
>>> 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free !
___
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] str with base
On Mon, Jan 16, 2006 at 11:13:27PM -0500, Raymond Hettinger wrote: > My reason is that I've rolled-my-own more times than I can count but > infrequently enough to where it was easier to re-write than to search > for the previous use. Me too! The assymetry is annoying. Its easy to consume base 2..36 integers, but its hard to generate them. However str() seems far too important to monkey with to me. I like a method on int that would be great. That keeps all the base conversions in int (either in __init__ or in as_yet_unnamed_method()). Another suggestion would be to give hex() and oct() another parameter, base, so you'd do hex(123123123, 2). Perhaps a little counter-intuitive, but if you were looking for base conversion functions you'd find hex() pretty quickly and the documentation would mention the other parameter. -- Nick Craig-Wood <[EMAIL PROTECTED]> -- http://www.craig-wood.com/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] str with base
Alex Martelli wrote:
> Is it finally time in Python 2.5 to allow the "obvious" use of, say,
> str(5,2) to give '101', just the converse of the way int('101',1)
> gives 5? I'm not sure why str has never allowed this obvious use --
> any bright beginner assumes it's there and it's awkward to explain
> why it's not!-). I'll be happy to propose a patch if the BDFL
> blesses this, but I don't even think it's worth a PEP... it's an
> inexplicable though long-standing omission (given the argumentative
> nature of this crowd I know I'll get pushback, but I still hope the
> BDFL can Pronounce about it anyway;-).
Hmm, how about this:
str(obj, ifisunicode_decode_using_encoding='ascii',
ifisinteger_use_base=10,
ifisfile_open_and_read_it=False,
isdecimal_use_precision=10,
ismoney_use_currency='EUR',
isdatetime_use_format='%c')
and so on ?!
Or even better:
str(obj, **kws) and then call obj.__str__(**kws) instead of
just obj.__str__() ?!
Seriously, shouldn't these more specific "convert to a string"
functions be left to specific object methods or helper
functions ?
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jan 17 2006)
>>> 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free !
___
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] str with base
Bob Ippolito wrote: > On Jan 16, 2006, at 9:12 PM, Andrew Bennetts wrote: > > >>On Mon, Jan 16, 2006 at 11:54:05PM -0500, Raymond Hettinger wrote: >>[...] >> >>>That suggests that it would be better to simply add an int method: >>> >>> x.convert_to_base(7) >> >>This seems clear and simple to me. I like it. I strongly suspect >>the "bright >>beginners" Alex is interested in would have no trouble using it or >>finding it. > > > I don't know about that, all of the methods that int and long > currently have are __special__. They'd really need to start with > Python 2.5 (assuming int/long grow "public methods" in 2.5) to even > think to look there. A format code or a built-in would be more > likely to be found, since that's how you convert integers to hex and > oct string representations with current Python. How about just stuffing some function in the math module? Everything in that module works on floats, but it seems incidental to me; I'm pretty sure I've even looked in that module for such a function before. But it's such an obscure need that only comes up in the kind of algorithms students write, that it just seems odd and unnecessary to put it in str() which is *so* much more general than int() is. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.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] str with base
On Jan 17, 2006, at 2:36 AM, Ian Bicking wrote: > Bob Ippolito wrote: >> On Jan 16, 2006, at 9:12 PM, Andrew Bennetts wrote: >>> On Mon, Jan 16, 2006 at 11:54:05PM -0500, Raymond Hettinger wrote: >>> [...] >>> That suggests that it would be better to simply add an int method: x.convert_to_base(7) >>> >>> This seems clear and simple to me. I like it. I strongly >>> suspect the "bright >>> beginners" Alex is interested in would have no trouble using it >>> or finding it. >> I don't know about that, all of the methods that int and long >> currently have are __special__. They'd really need to start with >> Python 2.5 (assuming int/long grow "public methods" in 2.5) to >> even think to look there. A format code or a built-in would be >> more likely to be found, since that's how you convert integers to >> hex and oct string representations with current Python. > > How about just stuffing some function in the math module? > Everything in that module works on floats, but it seems incidental > to me; I'm pretty sure I've even looked in that module for such a > function before. But it's such an obscure need that only comes up > in the kind of algorithms students write, that it just seems odd > and unnecessary to put it in str() which is *so* much more general > than int() is. I want binary all the time when I'm dealing with bitflags and such. Of course, I'm trained to be able to read bits in hex format, but it would be nicer to see the flags as-is. Even worse when you have to deal with some kind of file format where fields are N bits long, where N is not a multiple of 8. -bob ___ 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] str with base
Bob Ippolito wrote: > I want binary all the time when I'm dealing with bitflags and such. > Of course, I'm trained to be able to read bits in hex format, but it > would be nicer to see the flags as-is. Even worse when you have to > deal with some kind of file format where fields are N bits long, > where N is not a multiple of 8. so you want flags for bit order and fill order too, I assume ? ___ 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] Summer of PyPy
Hi Brett, hi all, On Sat, Jan 14, 2006 at 05:51:25PM -0800, Brett Cannon wrote: > That would be cool! I definitely would not mind working on PyPy. > Unfortunately I would not consider changing universities; I really > like it here. We are looking at the possibility to do a "Summer of PyPy" in the same style as last year's Google's Summer of Code. It might be a way for you (or anybody else interested!) to get to work a bit on PyPy first :-) http://codespeak.net/pipermail/pypy-dev/2006q1/002721.html A bientot, Armin ___ 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] str with base
On Jan 17, 2006, at 2:48 AM, Fredrik Lundh wrote: > Bob Ippolito wrote: > >> I want binary all the time when I'm dealing with bitflags and such. >> Of course, I'm trained to be able to read bits in hex format, but it >> would be nicer to see the flags as-is. Even worse when you have to >> deal with some kind of file format where fields are N bits long, >> where N is not a multiple of 8. > > so you want flags for bit order and fill order too, I assume ? Not really, big endian covers almost everything I need.. and when it doesn't, then I can just flip and/or pad the string accordingly. -bob ___ 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] str with base
On Tue, 2006-01-17 at 10:05 +, Nick Craig-Wood wrote: > On Mon, Jan 16, 2006 at 11:13:27PM -0500, Raymond Hettinger wrote: [...] > Another suggestion would be to give hex() and oct() another parameter, > base, so you'd do hex(123123123, 2). Perhaps a little > counter-intuitive, but if you were looking for base conversion > functions you'd find hex() pretty quickly and the documentation would > mention the other parameter. Ugh! I still favour extending % format strings. I really like '%b' for binary, but if arbitary bases are really wanted, then perhaps also leverage off the "precision" value for %d to indicate base such that '% 3.3d' % 5 = " 12" If people think that using "." is for "precision" and is too ambiguous for "base", you could do something like extend the whole conversion specifier to (in EBNF) [EMAIL PROTECTED] which would allow for weird things like "[EMAIL PROTECTED]" % 5.5 == " 12." Note: it is possible for floats to be represented in non-decimal number systems, its just extremely rare for anyone to do it. I have in my distant past used base 16 float notation for fixed-point numbers. I personally think %b would be adding enough. The other suggestions are just me being silly :-) -- Donovan Baarda <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/ ___ 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] str with base
Donovan Baarda <[EMAIL PROTECTED]> writes: > I personally think %b would be adding enough. The other suggestions are > just me being silly :-) Yeah, the whole area is just crying out for the simplicity and restraint that is common lisp's #'format function :) Cheers, mwh -- INEFFICIENT CAPITALIST YOUR OPULENT TOILET WILL BE YOUR UNDOING -- from Twisted.Quotes ___ 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] basenumber redux
On 1/17/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: [snip] > I don't see a way around creating an integer recognition tool that > doesn't conflate its terminology with broadly-held, pre-existing math > knowledge: complex is a superset of reals, reals include rationals and > irrationals some of which are trancendental, and rationals include > integers which are an infinite superset of non-negative integers, whole > numbers, negative numbers, etc. > > The decimal class only makes this more complicated. All binary floats > can be translated exactly to decimal but not vice-versa. I'm not sure > where they would fit into a inheritance hierarchy. To repeat a popular suggestion these days, python might borrow a page from Haskell. Haskell's Prelude_ defines a number (pardon the pun) of numeric typeclasses, each of which requires certain members. The inheritance graph shapes up roughly like this: Num - the ur-base class for all numbers Real - inherits from Num Integral - inherits from Real. Integral numbers support integer division Fractional - inherits from Num. Fractionals support true division Floating - inherits from Fractional. Floating-class objects support trigonometric and hyperbolic functions and related functions. RealFrac - inherits from Real and Fractional. This is used to operate on the components of fractions. RealFloat - inherits from RealFrac and Floating, providing efficient, machine-independent access to the components of a floating-point number. While it may not be necessary to concoct that many base classes for python, having a solid selection of such classes to subclass would reduce the need for heuristics like attribute testing. Moreover, subclassing a (or several) numeric type classes makes your intentions explicit, rather than relying on testing for an "implicit interface". Given the impact this would have on legacy code, and the need to refit the built-in types and standard library, such a chance might be better put off until Python 3k. _Prelude - http://www.haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html Thanks, Collin Winter ___ 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] str with base
It seems dumb to support *parsing* integers in weird bases, but not *formatting* them in weird bases. Not a big deal, but if you're going to give me a toy, at least give me the whole toy! The %b idea is a little disappointing in two ways. Even with %b, Python is still dumb by the above criterion. And, I suspect users that don't know about %b are unlikely to find it when they want it. I know I've never looked for it there. I think a method 5664400.to_base(13) sounds nice. -j ___ 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] str with base
On Tue, Jan 17, 2006 at 09:23:29AM -0500, Jason Orendorff wrote: > It seems dumb to support *parsing* integers in weird bases, but not > *formatting* them in weird bases. Not a big deal, but if you're going > to give me a toy, at least give me the whole toy! > > The %b idea is a little disappointing in two ways. Even with %b, > Python is still dumb by the above criterion. And, I suspect users > that don't know about %b are unlikely to find it when they want it. I > know I've never looked for it there. > > I think a method 5664400.to_base(13) sounds nice. It's also a SyntaxError. With the current syntax, it would need to be "(5664400).to_base(13)" or "5664400 .to_base(13)". Why not just make the %b take a base, e.g.: '%13b' % 5664400 -Andrew. ___ 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] index (was str with base)
Guido wrote: > more important to implement __index__() in Python 2.5. > This behaves like __int__() for integral types, but is not > defined for float or Decimal. Why not for Decimal, or even float? I would not be surprised if 10.798 failed, but I would expect 1000D to work. If indexing worked with more arbitrary extension integers, then I would expect it work with Decimal, and possibly float, when the number == a whole number, and to raise ValueError otherwise. -jJ ___ 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] str with base
Raymond wrote: > I presume that only the str() builtin would > change and that the underlying __str__ slot > would continue to be hard-wired to the > (reprfunc) signature. Are you saying that subclasses of str should behave differently from the builtin str, and not in the slots that were added or changed? -jJ ___ 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] str with base
Raymond> My reason is that I've rolled-my-own more times than I can Raymond> count but infrequently enough to where it was easier to Raymond> re-write than to search for the previous use. Maybe a bin() builtin would be better. Even better it seems to me would be to add a method to ints and longs that returns a string formatted in a base between 2 and 36 (then deprecate hex and oct). Like Jeremy, I wonder what str([1,2], 4) means. 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] str with base
Alex> Identically the same situation as for int: the base argument is Alex> only accepted if the first argument is a str (not a float, etc). Alex> Just the same way, the base argument to str will only be accepted Alex> if the first argument is an int (not a float, etc). A shortcoming in int() hardly seems like a good reason to mess with str(). 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] str with base
On Tuesday 2006-01-17 15:19, [EMAIL PROTECTED] wrote: > Alex> Identically the same situation as for int: the base argument is > Alex> only accepted if the first argument is a str (not a float, etc). > Alex> Just the same way, the base argument to str will only be accepted > Alex> if the first argument is an int (not a float, etc). > > A shortcoming in int() hardly seems like a good reason to mess with str(). How's it a shortcoming in int() that it doesn't do anything with, say, int(2.345,19)? (What would you like it to do?) Or are you saying that the fact that int() lets you specify a base to interpret the string in is itself a shortcoming, and if so why? -- g ___ 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] index (was str with base)
On 1/17/06, Jim Jewett <[EMAIL PROTECTED]> wrote: > Guido wrote: > > > more important to implement __index__() in Python 2.5. > > This behaves like __int__() for integral types, but is not > > defined for float or Decimal. > > Why not for Decimal, or even float? I would not be surprised > if 10.798 failed, but I would expect 1000D to work. > > If indexing worked with more arbitrary extension integers, > then I would expect it work with Decimal, and possibly float, > when the number == a whole number, and to raise ValueError > otherwise. Sorry, I forgot to explain this. There's a very good reason why this should not be allowed. You don't know if the 1000D was the result of an exact or of an approximate calculation. It could be a pure coincidence that it's 1000D instead of 999.9D; and we certainly don't want the latter to be allowed for indexing. Floating point (including Decimal floating point) calculations are fraught with uncertainties about the precision / accuracy of the outcome. Even if when you test your algorithm you always get exact outcomes, there's no guarantee that with real input data the same will hold. Requiring the index to be an int by *type* solves this by forcing you to think about rounding/truncating. I talked to some Numeric folks and they understand and agree. -- --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] str with base
Alex> Identically the same situation as for int: the base argument is Alex> only accepted if the first argument is a str (not a float, etc). Alex> Just the same way, the base argument to str will only be accepted Alex> if the first argument is an int (not a float, etc). >> Skip> A shortcoming in int() hardly seems like a good reason to mess Skip> with str(). Gareth> How's it a shortcoming in int() that it doesn't do anything Gareth> with, say, int(2.345,19)? My reasoning was that just because int() was written to ignore the second arg depending on type (the "shortcoming") doesn't mean that str() should as well. 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] str with base
[EMAIL PROTECTED] wrote: >Skip> A shortcoming in int() hardly seems like a good reason to mess >Skip> with str(). > >Gareth> How's it a shortcoming in int() that it doesn't do anything >Gareth> with, say, int(2.345,19)? > > My reasoning was that just because int() was written to ignore the second > arg depending on type (the "shortcoming") doesn't mean that str() should as > well. "ignore" is perhaps the wrong word: >>> int(1.0, 1) Traceback (most recent call last): File "", line 1, in ? TypeError: int() can't convert non-string with explicit base ___ 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] index (was str with base)
On 1/17/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 1/17/06, Jim Jewett <[EMAIL PROTECTED]> wrote: > > Guido wrote: > > > > > more important to implement __index__() in Python 2.5. > > > This behaves like __int__() for integral types, but is not > > > defined for float or Decimal. > > > > Why not for Decimal, or even float? I would not be surprised > > if 10.798 failed, but I would expect 1000D to work. > > > > If indexing worked with more arbitrary extension integers, > > then I would expect it work with Decimal, and possibly float, > > when the number == a whole number, and to raise ValueError > > otherwise. > > Sorry, I forgot to explain this. There's a very good reason why this > should not be allowed. > > You don't know if the 1000D was the result of an exact or of an > approximate calculation. It could be a pure coincidence that it's > 1000D instead of 999.9D; and we certainly don't want the latter to be > allowed for indexing. Floating point (including Decimal floating > point) calculations are fraught with uncertainties about the precision > / accuracy of the outcome. Even if when you test your algorithm you > always get exact outcomes, there's no guarantee that with real input > data the same will hold. > > Requiring the index to be an int by *type* solves this by forcing you > to think about rounding/truncating. I talked to some Numeric folks and > they understand and agree. IMO this is better done by replacing float with an interval type, or atleast float context objects with explicit rounding and precision control. The former would tell you when the result is inexact (the gap or "length" is non-zero), the latter would let you pick rounding behavior when you know enough math to back it up. And rather than leave you all hanging I'll say that I believe it could be done by using LLVM (circumventing C entierly.) http://rhamphoryncus.blogspot.com/2006/01/floating-point-and-nans-in-python.html (Why have float at all if the documentation essentially says it channels /dev/urandom?) -- Adam Olsen, aka Rhamphoryncus ___ 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] str with base
On 1/17/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> class Color:
> msg = {'en':['red', 'green', 'blue'], 'de':['rot','grün','blau']}
> def __str__(self, language='en'):
> return self.msg[language][self.value]
>
> red = Color(0)
>
> so you could say
>
> print str(red, 'de')
>
> I don't think I like this direction.
I agree that *args makes the code non-obvious. However, if **kwargs
is used instead:
def str(obj, **kwargs):
return obj.__str__(**kwargs)
class Color:
msg = {'en':['red', 'green', 'blue'], 'de':['rot','grün','blau']}
def __str__(self, language='en'):
return self.msg[language][self.value]
red = Color(0)
print str(red, language='de')
I find that quite readable.
--
Adam Olsen, aka Rhamphoryncus
___
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] str with base
On Mon, Jan 16, 2006, Alex Martelli wrote:
>
> Is it finally time in Python 2.5 to allow the "obvious" use of, say,
> str(5,2) to give '101', just the converse of the way int('101',1)
> gives 5? I'm not sure why str has never allowed this obvious use --
> any bright beginner assumes it's there and it's awkward to explain
> why it's not!-). I'll be happy to propose a patch if the BDFL
> blesses this, but I don't even think it's worth a PEP... it's an
> inexplicable though long-standing omission (given the argumentative
> nature of this crowd I know I'll get pushback, but I still hope the
> BDFL can Pronounce about it anyway;-).
-1
I agree with all the other comments about the functional asymmetry
between int() and str() in the Python universe, and that therefore str()
shouldn't necessarily mimic int()'s API. Propose some other mechanism;
I so far haven't seen a good reasons to prefer any of the ones already
proposed.
--
Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/
"19. A language that doesn't affect the way you think about programming,
is not worth knowing." --Alan Perlis
___
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] Building on OS X 10.4 fails
Building the readline on OS X 10.4 fails, is this known, or am I doing something wrong? Thanks, Thomas building 'readline' extension gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/Users/theller/svn/trunk/./Include -I/Users/theller/svn/trunk/./Mac/Include -I./Include -I. -I/Users/theller/svn/trunk/Include -I/Users/theller/svn/trunk -c /Users/theller/svn/trunk/Modules/readline.c -o build/temp.darwin-8.4.0-Power_Macintosh-2.5/readline.o /Users/theller/svn/trunk/Modules/readline.c: In function 'write_history_file': /Users/theller/svn/trunk/Modules/readline.c:112: warning: implicit declaration of function 'history_truncate_file' /Users/theller/svn/trunk/Modules/readline.c: In function 'py_remove_history': /Users/theller/svn/trunk/Modules/readline.c:301: warning: implicit declaration of function 'remove_history' /Users/theller/svn/trunk/Modules/readline.c:301: warning: assignment makes pointer from integer without a cast /Users/theller/svn/trunk/Modules/readline.c:310: warning: passing argument 1 of 'free' discards qualifiers from pointer target type /Users/theller/svn/trunk/Modules/readline.c:312: warning: passing argument 1 of 'free' discards qualifiers from pointer target type /Users/theller/svn/trunk/Modules/readline.c: In function 'py_replace_history': /Users/theller/svn/trunk/Modules/readline.c:338: warning: implicit declaration of function 'replace_history_entry' /Users/theller/svn/trunk/Modules/readline.c:338: warning: assignment makes pointer from integer without a cast /Users/theller/svn/trunk/Modules/readline.c:347: warning: passing argument 1 of 'free' discards qualifiers from pointer target type /Users/theller/svn/trunk/Modules/readline.c:349: warning: passing argument 1 of 'free' discards qualifiers from pointer target type /Users/theller/svn/trunk/Modules/readline.c: In function 'get_current_history_length': /Users/theller/svn/trunk/Modules/readline.c:453: error: 'HISTORY_STATE' undeclared (first use in this function) /Users/theller/svn/trunk/Modules/readline.c:453: error: (Each undeclared identifier is reported only once /Users/theller/svn/trunk/Modules/readline.c:453: error: for each function it appears in.) /Users/theller/svn/trunk/Modules/readline.c:453: error: 'hist_st' undeclared (first use in this function) /Users/theller/svn/trunk/Modules/readline.c:455: warning: implicit declaration of function 'history_get_history_state' /Users/theller/svn/trunk/Modules/readline.c: In function 'insert_text': /Users/theller/svn/trunk/Modules/readline.c:503: warning: implicit declaration of function 'rl_insert_text' /Users/theller/svn/trunk/Modules/readline.c: In function 'on_completion': /Users/theller/svn/trunk/Modules/readline.c:637: error: 'rl_attempted_completion_over' undeclared (first use in this function) /Users/theller/svn/trunk/Modules/readline.c: In function 'flex_complete': /Users/theller/svn/trunk/Modules/readline.c:675: warning: passing argument 2 of 'completion_matches' from incompatible pointer type /Users/theller/svn/trunk/Modules/readline.c: In function 'setup_readline': /Users/theller/svn/trunk/Modules/readline.c:700: warning: passing argument 2 of 'rl_bind_key_in_map' from incompatible pointer type /Users/theller/svn/trunk/Modules/readline.c:701: warning: passing argument 2 of 'rl_bind_key_in_map' from incompatible pointer type /Users/theller/svn/trunk/Modules/readline.c: In function 'readline_until_enter_or_signal': /Users/theller/svn/trunk/Modules/readline.c:758: warning: passing argument 2 of 'rl_callback_handler_install' from incompatible pointer type /Users/theller/svn/trunk/Modules/readline.c:788: warning: implicit declaration of function 'rl_free_line_state' /Users/theller/svn/trunk/Modules/readline.c:789: warning: implicit declaration of function 'rl_cleanup_after_signal' /Users/theller/svn/trunk/Modules/readline.c: In function 'call_readline': /Users/theller/svn/trunk/Modules/readline.c:883: error: 'HISTORY_STATE' undeclared (first use in this function) /Users/theller/svn/trunk/Modules/readline.c:883: error: 'state' undeclared (first use in this function) /Users/theller/svn/trunk/Modules/readline.c:885: warning: assignment discards qualifiers from pointer target type ___ 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] Python icon
[EMAIL PROTECTED] wrote: > >> does Python have an official icon? > > Ping> i found some images at http://www.pythonology.com/logos... > > It appears the yin/yang Python's on that page are being used in the new site > (beta.python.org). I don't know if that makes it official or not though. Interesting, didn't even know a new page was in the making... Do you know who is responsible for the new page? regards, 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] Python icon
Georg> Interesting, didn't even know a new page was in the making... Do Georg> you know who is responsible for the new page? Tim Parkin is heading things up. Look here: http://beta.python.org/ 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] str with base
Hi Alex,
> Is it finally time in Python 2.5 to allow the "obvious" use of, say,
> str(5,2) to give '101', just the converse of the way int('101',1)
> gives 5?
+1. That's obvious enough for me. Clearly it should only work with int
and long arguments, just like int(x,base) only works if x is a str or
unicode argument (and not something that can be converted to a string,
or even a stringish type for some definition of stringish).
Armin
___
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] Building on OS X 10.4 fails
On Jan 17, 2006, at 10:17 AM, Thomas Heller wrote: > Building the readline on OS X 10.4 fails, is this known, or am I doing > something wrong? Mac OS X doesn't ship with readline. It ships with BSD libedit symlinked to readline. Not good enough for Python. You need a third party copy. I made an egg for it a while ago: http://python.org/pypi/readline -bob ___ 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] Building on OS X 10.4 fails
On Tue, 2006-01-17 at 19:17 +0100, Thomas Heller wrote: > Building the readline on OS X 10.4 fails, is this known, or am I doing > something wrong? There are definitely serious issues with readline on OS X 10.4. I've hit them too but haven't had time to post about it yet. I'm far from an expert on them (Bob, Jack and others can definitely speak with more knowledge on this) but my understanding is that the default readline that comes with Tiger is not sufficient to build the Python extension library. However, I use DarwinPorts and IWBNI Python's build process could search /opt/local for the necessary readline support, using that if found. I know that DP's Python 2.4.2 build does provide readline, so that should definitely work. I've glanced at the setup.py file, but haven't had the time to dig in in enough detail to actually fix and commit. (There was something else that bugged me about the OS X 10.4 Python from-source build but now I can't remember.) -Barry signature.asc Description: This is a digitally signed message part ___ 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] Include ctypes into core Python?
"Martin v. Löwis" <[EMAIL PROTECTED]> writes: > Guido van Rossum wrote: >> On 1/16/06, Thomas Heller <[EMAIL PROTECTED]> wrote: >> >>>It looks like we need a pronouncement now. >> >> >> Sorry. It appeared to me that there was general agreement to using a >> strongly worded warning in the docs, so I tuned out of the rest of the >> discussion. So for the record, I'm fine with that. > > Ok. If Thomas checks in the code and the documentation, I'll do the > Windows/setup part of it. Great. Now, I'm trying to build ctypes on OS X as the first non-windows platform. As I said, ctypes currently has its own source copy of libffi (since there are no separate releases of libffi, and the only platform that comes with libffi by default that I know is cygwin). It is built into a static non-shared library with a call to configure like this: cd /configure --disable-shared --enable-static \ --enable-multilib=no --prefix= make install then libffi.a is linked into the _ctypes extension module. I know near to nothing about 'configure', can/should a call to os.system with the commands above be added to setup.py, or how could this be approached? Thomas ___ 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] Building on OS X 10.4 fails
On 1/17/06, Barry Warsaw <[EMAIL PROTECTED]> wrote: > On Tue, 2006-01-17 at 19:17 +0100, Thomas Heller wrote: > > Building the readline on OS X 10.4 fails, is this known, or am I doing > > something wrong? > > There are definitely serious issues with readline on OS X 10.4. I've > hit them too but haven't had time to post about it yet. I'm far from an > expert on them (Bob, Jack and others can definitely speak with more > knowledge on this) but my understanding is that the default readline > that comes with Tiger is not sufficient to build the Python extension > library. > > However, I use DarwinPorts and IWBNI Python's build process could > search /opt/local for the necessary readline support, using that if > found. I know that DP's Python 2.4.2 build does provide readline, so > that should definitely work. I've glanced at the setup.py file, but > haven't had the time to dig in in enough detail to actually fix and > commit. > OS X-specific package support has been removed from setup.py for the more generic support of LDFLAGS and CPPFLAGS. Set those properly for /opt/local/(lib|include) and it will find readline installed by DP fine (it's how I build my checkout with readline support). -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] str with base
On 1/16/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 1/16/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> > Is it finally time in Python 2.5 to allow the "obvious" use of, say,
> > str(5,2) to give '101', just the converse of the way int('101',1)
> [I'm sure you meant int('101', 2) here]
Yep.
> > gives 5? I'm not sure why str has never allowed this obvious use --
> > any bright beginner assumes it's there and it's awkward to explain
> > why it's not!-). I'll be happy to propose a patch if the BDFL
> > blesses this, but I don't even think it's worth a PEP... it's an
> > inexplicable though long-standing omission (given the argumentative
> > nature of this crowd I know I'll get pushback, but I still hope the
> > BDFL can Pronounce about it anyway;-).
>
> I wish you had an argument better than "every bright beginner assumes
> it exists". :-)
What about "it should obviously be there"?-)
> But (unlike for some other things that bright beginners might assume)
> I don't think there's a deep reason why this couldn't exist.
>
> The only reasons I can come up with is "because input and output are
> notoriously asymmetric in Python" and "because nobody submitted a
> patch". :-)
OK, so, should I just submit a patch?
> There are some corner cases to consider though.
>
> - Should repr() support the same convention? I think not.
> - Should str(3.1, n) be allowed? I think not.
> - Should str(x, n) call x.__str__(n)? Neither.
> - Should bases other than 2..36 be considered? I don't think so.
Agreed on all scores.
> Unfortunately this doesn't obsolete oct() and hex() -- oct(10) returns
> '012', while str(10, 8) soulc return '12'; hex(10) returns '0xa' while
> str(10, 16) would return 'a'.
Sure. hex(x) is like '0x'+str(x,16) and oct(x) is like '0'+str(x,8)
but hex and oct are minutely more concise.
> I do think that before we add this end-user nicety, it's more
> important to implement __index__() in Python 2.5. This behaves like
More important, sure, but also proportionally more work, so I don't
see the two issues as "competing" against each other.
> __int__() for integral types, but is not defined for float or Decimal.
> Operations that intrinsically require an integral argument, like
> indexing and slicing, should call __index__() on their argument rather
> than __int__(), so as to support non-built-in integral arguments while
> still complaining about float arguments.
Hear, hear. Multiplication of sequences, too.
> This is currently implemented
> by explicitly checking for float in a few places, which I find
> repulsing. __index__() won't be requested by bright beginners, but it
You might be surprised by just how bright some (Python) beginners with
deep maths background can be, though they might prefer to spell it
differently
(__int_and_i_really_mean_it__ for example'-) because it may not be
obvious (if they're not Dutch) that multiplying a sequence has to do
with 'indexing';-).
> is important e.g. to the Numeric Python folks, who like to implement
> their own integral types but are suffering from that their integers
> aren't usable everywhere.
As the author and maintainer of gmpy I entirely agree -- I never liked
the fact that instances of gmpy.mpq are "second class citizens" and i
need to plaster int(...) around them to use them as list indices or to
multiply sequences (I vaguely mentioned having in mind a 'baseinteger'
check, but a special method returning the integer value, such as the
__index__ you're talking about, is obviously better).
Alex
___
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] basenumber redux
On 1/17/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > Alex, I think you're missing a point here: what you are looking > for is an interface, not a base class - simply because the I expect numbers to support arithmetic operators, &c -- no need for basenumber to "spell this out", i.e., "be an itnerface". > If you look at the Python C API, you'll find that "a number" > is actually never tested. There being no way to generically test for "a number", that's unsurprising. > The tests always ask for either > integers or floats. But this doesn't apply to the Python Standard Library, for example see line 1348 of imaplib.py: "if isinstance(date_time, (int, float)):". > The addition of a basenumber base class won't make these any > simpler. Being able to change imaplib to use basenumber instead of (int, float) won't make it SIMPLER, but it will surely make it BETTER -- why should a long be rejected, or a Decimal, for that matter? Similarly, on line 1352 it should use the existing basestring, though it now uses str (this function IS weird -- if it finds date_time to be of an unknown TYPE it raises a *ValueError* rather than a *TypeError* -- ah well). Alex ___ 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] str with base
On 1/17/06, Alex Martelli <[EMAIL PROTECTED]> wrote: > OK, so, should I just submit a patch? Hmm, there are quite a few people who strongly dislike the particular API you're proposing. The problem is, bright newbies might be led to wanting str(i, base) as an analogy to int(s, base) only because they see str() and int() as each other's opposites, not having seen other uses of either (especially str()). Given the amount of disagreement on this issue and my own lackluster interest I don't want to pronounce str(i, base) to be the right solution. Sorry! -- --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] basenumber redux
Alex Martelli wrote:
> But this doesn't apply to the Python Standard Library, for example see
> line 1348 of imaplib.py: "if isinstance(date_time, (int, float)):".
[...]
> Being able to change imaplib to use basenumber instead of (int, float)
> won't make it SIMPLER, but it will surely make it BETTER -- why should
> a long be rejected, or a Decimal, for that matter?
Right. I think this function should read
if isinstance(date_time, str) and \
(date_time[0],date_time[-1]) == ('"','"'):
return date_time# Assume in correct format
if isinstance(date_time, (tuple, time.struct_time)):
tt = date_time
else:
tt = time.localtime(date_time)
If this is something that time.localtime can't handle, it will
give a TypeError. This is much better than
raise ValueError("date_time not of a known type")
# (why does it raise a ValueError if it says "type"?)
Regards,
Martin
___
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] str with base
On Tue, Jan 17, 2006 at 09:23:29AM -0500, Jason Orendorff wrote: > I think a method 5664400.to_base(13) sounds nice. [And others suggested int-methods too] I would like to point out that this is almost, but not quite, entirely as inapropriate as using str(). Integers don't have a base. String representations of integers -- and indeed, numbers in general, as the Python tutorial explains in Appendix B -- have a base. Adding such a method to integers (and, I presume, longs) would beg the question why floats, Decimals and complex numbers don't have them. In-favour-of-%2b-ly y'rs, -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] basenumber redux
On 1/17/06, Alex Martelli <[EMAIL PROTECTED]> wrote: > Being able to change imaplib to use basenumber instead of (int, float) > won't make it SIMPLER, but it will surely make it BETTER -- why should > a long be rejected, or a Decimal, > for that matter? Because there's no guarantee that they'll produce correct results? All number types are approximations of true numbers, and they all behave wrong in creative ways. For example: def xrange(start, stop, step): i = start while i < stop: yield i i += step This works fine so long as you only give it int as input, and has no maximum value. >>> for i in xrange(2**53, 2**53+3, 1): print i ... 9007199254740992 9007199254740993 9007199254740994 Float inputs also work so long as you don't get large enough to provoke rounding. However, as soon as you do... >>> for i in xrange(2**53, 2**53+3, 1.0): print i ... 9007199254740992 9.00719925474e+15 9.00719925474e+15 9.00719925474e+15 9.00719925474e+15 9.00719925474e+15 9.00719925474e+15 974e+15 Traceback (most recent call last): File "", line 1, in ? KeyboardInterrupt The function fails. Floating point, despite being a "number" and supporting the "number interface", does not behave close enough to what the programmer desires to work for all values. There might be a way to handle floats specially that a mathematician may understand, but the only way I know of is to convert to int at the start of the function. def xrange(start, stop, step): start, stop, step = int(start), int(stop), int(step) i = start while i < stop: yield i i += step >>> for i in xrange(2**53, 2**53+3, 1.0): print i ... 9007199254740992 9007199254740993 9007199254740994 That works so long as the floats are all integral values. Unfortunately a non-integral value will get truncated silently. An explicit check for equality after the conversion would have to be added, or Guido's __index__ could be used, but __index__ seems misnamed for this usage. Another approach would be changing operations involving floats to return intervals instead. The high end of the interval would continue to count up when rounding is provoked, and would raise an exception when the i < stop is executed (due to being ambiguous). Once float uses intervals you could state that all number types are expected to use intervals in the face of inexactness (and those who don't behave as expected would have unexpected results.) -- Adam Olsen, aka Rhamphoryncus ___ 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] str with base
On 1/17/06, Thomas Wouters <[EMAIL PROTECTED]> wrote: > On Tue, Jan 17, 2006 at 09:23:29AM -0500, Jason Orendorff wrote: > > > I think a method 5664400.to_base(13) sounds nice. > [And others suggested int-methods too] > > I would like to point out that this is almost, but not quite, entirely as > inapropriate as using str(). Integers don't have a base. String > representations of integers -- and indeed, numbers in general, as the Python > tutorial explains in Appendix B -- have a base. Adding such a method to > integers (and, I presume, longs) would beg the question why floats, Decimals > and complex numbers don't have them. I dream of a day when str(3.25, base=2) == '11.01'. That is the number a float really represents. It would be so much easier to understand why floats behave the way they do if it were possible to print them in binary. To be fair, it's not str(x, base=n) I'm after here (although it seems like a clean way to do it.) Rather, I just want SOME way of printing ints and floats in binary. > In-favour-of-%2b-ly y'rs, My only opposition to this is that the byte type may want to use it. I'd rather wait until byte is fully defined, implemented, and released in a python version before that option is taken away. -- Adam Olsen, aka Rhamphoryncus ___ 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] str with base
On 1/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote: > > In-favour-of-%2b-ly y'rs, > > My only opposition to this is that the byte type may want to use it. > I'd rather wait until byte is fully defined, implemented, and released > in a python version before that option is taken away. Has this been proposed? What would %b print? -- --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] str with base
On 1/17/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 1/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote: > > > In-favour-of-%2b-ly y'rs, > > > > My only opposition to this is that the byte type may want to use it. > > I'd rather wait until byte is fully defined, implemented, and released > > in a python version before that option is taken away. > > Has this been proposed? What would %b print? I don't believe it's been proposed and I don't know what it'd print. Perhaps it indicates the bytes should be passed through without conversion. In any case I only advocate waiting until it's clear that bytes have no need for it before we use it for binary conversions. -- Adam Olsen, aka Rhamphoryncus ___ 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] Building on OS X 10.4 fails
On Wednesday 18 January 2006 06:19, Barry Warsaw wrote: > On Tue, 2006-01-17 at 19:17 +0100, Thomas Heller wrote: > > Building the readline on OS X 10.4 fails, is this known, or am I > > doing something wrong? > > There are definitely serious issues with readline on OS X 10.4. > I've hit them too but haven't had time to post about it yet. I'm > far from an expert on them (Bob, Jack and others can definitely > speak with more knowledge on this) but my understanding is that the > default readline that comes with Tiger is not sufficient to build > the Python extension library. It sounds like configure needs to grow a test to detect that a "libreadline" it finds is actually the crackful "libedit" and refuse to use it if so. Anthony ___ 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] str with base
On Jan 17, 2006, at 4:09 PM, Adam Olsen wrote: > On 1/17/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> On 1/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote: In-favour-of-%2b-ly y'rs, >>> >>> My only opposition to this is that the byte type may want to use it. >>> I'd rather wait until byte is fully defined, implemented, and >>> released >>> in a python version before that option is taken away. >> >> Has this been proposed? What would %b print? > > I don't believe it's been proposed and I don't know what it'd print. > Perhaps it indicates the bytes should be passed through without > conversion. That doesn't make any sense. What is "without conversion"? Does that mean UTF-8, UCS-2, UCS-4, latin-1, Shift-JIS? You can't have unicode without some kind of conversion. > In any case I only advocate waiting until it's clear that bytes have > no need for it before we use it for binary conversions. I don't see what business a byte type has mingling with string formatters other than the normal str and repr coercions via %s and %r respectively. -bob ___ 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] str with base
On Tue, Jan 17, 2006 at 04:02:43PM -0800, Guido van Rossum wrote: > On 1/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote: > > > In-favour-of-%2b-ly y'rs, > > > > My only opposition to this is that the byte type may want to use it. > > I'd rather wait until byte is fully defined, implemented, and released > > in a python version before that option is taken away. > > Has this been proposed? What would %b print? > It was proposed in this or another thread about the same in the last few days (gmane search doesn't like the % in '%b'). The suggestion is to add 'b' as a sprintf-like format string %[][.]b Where the optional is the base to print in and is the optional minimum length of chars to print (as I recall). Default is base 2. Me? I like it. -Jack ___ 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] str with base
On Jan 17, 2006, at 3:38 PM, Adam Olsen wrote: > On 1/17/06, Thomas Wouters <[EMAIL PROTECTED]> wrote: >> On Tue, Jan 17, 2006 at 09:23:29AM -0500, Jason Orendorff wrote: >> >>> I think a method 5664400.to_base(13) sounds nice. >> [And others suggested int-methods too] >> >> I would like to point out that this is almost, but not quite, >> entirely as >> inapropriate as using str(). Integers don't have a base. String >> representations of integers -- and indeed, numbers in general, as >> the Python >> tutorial explains in Appendix B -- have a base. Adding such a >> method to >> integers (and, I presume, longs) would beg the question why >> floats, Decimals >> and complex numbers don't have them. > > I dream of a day when str(3.25, base=2) == '11.01'. That is the > number a float really represents. It would be so much easier to > understand why floats behave the way they do if it were possible to > print them in binary. Actually if you wanted something that closely represents what a floating point number is then you would want to see this:: >>> str(3.25, base=2) '1.101e1' >>> str(0.25, base=2) '1.0e-10' Printing the bits without an exponent is nearly as misleading as printing them in decimal. -bob ___ 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] Building on OS X 10.4 fails
On Jan 17, 2006, at 4:17 PM, Anthony Baxter wrote: > On Wednesday 18 January 2006 06:19, Barry Warsaw wrote: >> On Tue, 2006-01-17 at 19:17 +0100, Thomas Heller wrote: >>> Building the readline on OS X 10.4 fails, is this known, or am I >>> doing something wrong? >> >> There are definitely serious issues with readline on OS X 10.4. >> I've hit them too but haven't had time to post about it yet. I'm >> far from an expert on them (Bob, Jack and others can definitely >> speak with more knowledge on this) but my understanding is that the >> default readline that comes with Tiger is not sufficient to build >> the Python extension library. > > It sounds like configure needs to grow a test to detect that a > "libreadline" it finds is actually the crackful "libedit" and refuse > to use it if so. Unless something has changed since 2.4.1, that is the current behavior. Thomas' title should've probably been "Building readline on OS X 10.4 fails", rather than "Building on OS X 10.4 fails" (which reads as "Building Python on OS X 10.4 fails" given the list). -bob ___ 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] str with base
On Jan 17, 2006, at 5:01 PM, Jack Diederich wrote: > On Tue, Jan 17, 2006 at 04:02:43PM -0800, Guido van Rossum wrote: >> On 1/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote: In-favour-of-%2b-ly y'rs, >>> >>> My only opposition to this is that the byte type may want to use it. >>> I'd rather wait until byte is fully defined, implemented, and >>> released >>> in a python version before that option is taken away. >> >> Has this been proposed? What would %b print? >> > It was proposed in this or another thread about the same in the > last few > days (gmane search doesn't like the % in '%b'). > > The suggestion is to add 'b' as a sprintf-like format string > %[][.]b > > Where the optional is the base to print in and is the > optional > minimum length of chars to print (as I recall). Default is base 2. > > Me? I like it. Personally I would prefer the "b" format code to behave similarly to "o", "d", and "d", except for binary instead of octal, decimal, and hexadecimal. Something that needs to account for three factors (zero pad, space pad, base) should probably be a function (maybe a builtin). Hell, maybe it could take a fourth argument to specify how a negative number should be printed (e.g. a number of bits to use for the 2's complement). However... if %b were to represent arbitrary bases, I think that's backwards. It should be %[][.]b, which would do this: >>> '%08b %08o %08d %08x' % 12 '1100 0014 0012 000C' Where your suggestion would have this behavior (or something close to it): >>> '%08b %08o %08d %08x' % 12 '14 0014 0012 000C' -bob ___ 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] str with base
On 1/17/06, Bob Ippolito <[EMAIL PROTECTED]> wrote: > > On Jan 17, 2006, at 3:38 PM, Adam Olsen wrote: > > > I dream of a day when str(3.25, base=2) == '11.01'. That is the > > number a float really represents. It would be so much easier to > > understand why floats behave the way they do if it were possible to > > print them in binary. > > Actually if you wanted something that closely represents what a > floating point number is then you would want to see this:: > > >>> str(3.25, base=2) > '1.101e1' > >>> str(0.25, base=2) > '1.0e-10' > > Printing the bits without an exponent is nearly as misleading as > printing them in decimal. I disagree. The exponent is involved in rounding to fit in compact storage but once that is complete the value can be represented exactly without it. -- Adam Olsen, aka Rhamphoryncus ___ 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] str with base
On 1/17/06, Bob Ippolito <[EMAIL PROTECTED]> wrote:
>
> On Jan 17, 2006, at 4:09 PM, Adam Olsen wrote:
>
> > On 1/17/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >> On 1/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> In-favour-of-%2b-ly y'rs,
> >>>
> >>> My only opposition to this is that the byte type may want to use it.
> >>> I'd rather wait until byte is fully defined, implemented, and
> >>> released
> >>> in a python version before that option is taken away.
> >>
> >> Has this been proposed? What would %b print?
> >
> > I don't believe it's been proposed and I don't know what it'd print.
> > Perhaps it indicates the bytes should be passed through without
> > conversion.
>
> That doesn't make any sense. What is "without conversion"? Does
> that mean UTF-8, UCS-2, UCS-4, latin-1, Shift-JIS? You can't have
> unicode without some kind of conversion.
>
> > In any case I only advocate waiting until it's clear that bytes have
> > no need for it before we use it for binary conversions.
>
> I don't see what business a byte type has mingling with string
> formatters other than the normal str and repr coercions via %s and %r
> respectively.
Is the byte type intended to be involved in string formatters at all?
Does byte("%i") % 3 have the obvious effect, or is it an error?
Although upon further consideration I don't see any case where %s and
%b would have different effects.. *shrug* I never said it did have a
purpose, just that it *might* be given a purpose when byte was spec'd
out.
--
Adam Olsen, aka Rhamphoryncus
___
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] str with base
On Tue, Jan 17, 2006 at 06:11:36PM -0800, Bob Ippolito wrote: > > On Jan 17, 2006, at 5:01 PM, Jack Diederich wrote: > > >On Tue, Jan 17, 2006 at 04:02:43PM -0800, Guido van Rossum wrote: > >>On 1/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote: > In-favour-of-%2b-ly y'rs, > >>> > >>>My only opposition to this is that the byte type may want to use it. > >>>I'd rather wait until byte is fully defined, implemented, and > >>>released > >>>in a python version before that option is taken away. > >> > >>Has this been proposed? What would %b print? > >> > >It was proposed in this or another thread about the same in the > >last few > >days (gmane search doesn't like the % in '%b'). > > > >The suggestion is to add 'b' as a sprintf-like format string > > %[][.]b > > > >Where the optional is the base to print in and is the > >optional > >minimum length of chars to print (as I recall). Default is base 2. > > > >Me? I like it. > > Personally I would prefer the "b" format code to behave similarly to > "o", "d", and "d", except for binary instead of octal, decimal, and > hexadecimal. Something that needs to account for three factors (zero > pad, space pad, base) should probably be a function (maybe a > builtin). Hell, maybe it could take a fourth argument to specify how > a negative number should be printed (e.g. a number of bits to use for > the 2's complement). > > However... if %b were to represent arbitrary bases, I think that's > backwards. It should be %[][.]b, which would do this: > > >>> '%08b %08o %08d %08x' % 12 > '1100 0014 0012 000C' > Were I BDFAD (not to be confused with BD-FOAD) I'd add %b, %B and, binary() to match %x, %X, and hex(). The arbitrary base case isn't even academic or we would see homework questions about it on c.l.py. No one asks about hex or octal because they are there. No one asks about base seven formatting because everyone knows numerologists prefer Perl. -Jack nb, that's "For A Day." ___ 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] str with base
On Jan 17, 2006, at 7:12 PM, Jack Diederich wrote:
> On Tue, Jan 17, 2006 at 06:11:36PM -0800, Bob Ippolito wrote:
>>
>> On Jan 17, 2006, at 5:01 PM, Jack Diederich wrote:
>>
>>> On Tue, Jan 17, 2006 at 04:02:43PM -0800, Guido van Rossum wrote:
On 1/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
>> In-favour-of-%2b-ly y'rs,
>
> My only opposition to this is that the byte type may want to
> use it.
> I'd rather wait until byte is fully defined, implemented, and
> released
> in a python version before that option is taken away.
Has this been proposed? What would %b print?
>>> It was proposed in this or another thread about the same in the
>>> last few
>>> days (gmane search doesn't like the % in '%b').
>>>
>>> The suggestion is to add 'b' as a sprintf-like format string
>>> %[][.]b
>>>
>>> Where the optional is the base to print in and is the
>>> optional
>>> minimum length of chars to print (as I recall). Default is base 2.
>>>
>>> Me? I like it.
>>
>> Personally I would prefer the "b" format code to behave similarly to
>> "o", "d", and "d", except for binary instead of octal, decimal, and
>> hexadecimal. Something that needs to account for three factors (zero
>> pad, space pad, base) should probably be a function (maybe a
>> builtin). Hell, maybe it could take a fourth argument to specify how
>> a negative number should be printed (e.g. a number of bits to use for
>> the 2's complement).
>>
>> However... if %b were to represent arbitrary bases, I think that's
>> backwards. It should be %[][.]b, which would do this:
>>
>> >>> '%08b %08o %08d %08x' % 12
>> '1100 0014 0012 000C'
>>
>
> Were I BDFAD (not to be confused with BD-FOAD) I'd add %b, %B and,
> binary()
> to match %x, %X, and hex(). The arbitrary base case isn't even
> academic
> or we would see homework questions about it on c.l.py. No one asks
> about
> hex or octal because they are there. No one asks about base seven
> formatting because everyone knows numerologists prefer Perl.
There shouldn't be a %B for the same reason there isn't an %O or %D
-- they're all just digits, so there's not a need for an uppercase
variant.
The difference between hex() and oct() and the proposed binary() is
that hex() and oct() return valid Python expressions in that base.
In order for it to make sense, Python would need to grow some syntax.
If Python were to have syntax for binary literals, I'd propose a
trailing b: "1100b". It would be convenient at times to represent
bit flags, but I'm not sure it's worth the syntax change.
binarydigit ::= ("0" | "1")
binaryinteger ::= binarydigit+ "b"
integer ::= decimalinteger | octinteger | hexinteger | binaryinteger
-bob
___
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] computed goto's in ceval loop
I have been experimenting with replacing the big switch in ceval.c by a computed goto construct [1]. It uses #define's to make it optional. This work was inspired by Mono's MINT interpreter code, and Neil Norwitz's attempt to use a function pointer table [2]. Result: about 1% slower on the pystone benchmark. It also seems to have broken the interpreter; at least one test fails (test_StringIO). Whoops. Not sure if the other switch-speedup hacks (eg. PREDICT(op)) conflict at all with this patch (ie. make it slower than it could be). Mono uses a much larger opcode set, with 2-byte opcodes, that includes type info in each opcode. This means that the actual case statements are much faster. My initial thought about using computed goto's (January 2003) was that the python opcode cases were much fatter than mono's (often involving a function call) so that the overhead of branching on opcodes would be insignificant. It seems that this is true indeed. The patch id is 1408710. [1] http://developer.apple.com/documentation/DeveloperTools/gcc-4.0.1/gcc/Labels-as-Values.html [2] http://mail.python.org/pipermail/python-dev/2003-February/033705.html Simon. -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 02 6249 6940 http://arrowtheory.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] str with base
On 1/17/06, Bob Ippolito <[EMAIL PROTECTED]> wrote: > There shouldn't be a %B for the same reason there isn't an %O or %D > -- they're all just digits, so there's not a need for an uppercase > variant. Right. > The difference between hex() and oct() and the proposed binary() is I'd propose bin() to stay in line with the short abbreviated names. > that hex() and oct() return valid Python expressions in that base. > In order for it to make sense, Python would need to grow some syntax. Fair enough. So let's define it. > If Python were to have syntax for binary literals, I'd propose a > trailing b: "1100b". It would be convenient at times to represent > bit flags, but I'm not sure it's worth the syntax change. Typically, suffixes are used to indicated *types*: 12L, 12j, and even 12e0 in some sense. The binary type should have a 0b prefix. Perhaps this could be implemented at the PyCon sprint? -- --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] str with base
On 1/17/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 1/17/06, Bob Ippolito <[EMAIL PROTECTED]> wrote: > > There shouldn't be a %B for the same reason there isn't an %O or %D > > -- they're all just digits, so there's not a need for an uppercase > > variant. > > Right. > > > The difference between hex() and oct() and the proposed binary() is > > I'd propose bin() to stay in line with the short abbreviated names. > > > that hex() and oct() return valid Python expressions in that base. > > In order for it to make sense, Python would need to grow some syntax. > > Fair enough. So let's define it. > > > If Python were to have syntax for binary literals, I'd propose a > > trailing b: "1100b". It would be convenient at times to represent > > bit flags, but I'm not sure it's worth the syntax change. > > Typically, suffixes are used to indicated *types*: 12L, 12j, and even > 12e0 in some sense. > > The binary type should have a 0b prefix. > 0b101 for 5? > Perhaps this could be implemented at the PyCon sprint? > Added to the wiki along with possibly hashing out the bytes type. -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] Building on OS X 10.4 fails
> "Anthony" == Anthony Baxter <[EMAIL PROTECTED]> writes: Anthony> It sounds like configure needs to grow a test to detect Anthony> that a "libreadline" it finds is actually the crackful Anthony> "libedit" and refuse to use it if so. FYI: Real libreadline is GPL, and rms made a point of forcing (Aladdin-licensed) Ghostscript to remove stanzas from the Makefile that allowed linking to it as a user option. Ie, this particular pain in the neck is deliberate FSF policy, to encourage use of the GPL. Unless rms has changed his position on this, or there has been relevant legislation or a court decision in the meantime, explicitly requiring or checking for "real" libreadline, even as a user option, risks rms's wrath. (Of course, Python could change its license to GPL, which would undoubtedly flood Cambridge with tears of joy). As long as the link to fake libreadline succeeds and the resulting program works identically to one linked to real libreadline, he has no complaint. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. ___ 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] str with base
On 1/17/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > > The difference between hex() and oct() and the proposed binary() is > > I'd propose bin() to stay in line with the short abbreviated names. Are these features used enough to have 3 builtins? Would format(number, base) suffice? format(5, base=2) == '101' format(5, base=8) == '5' format(5, base=8, prefix=True) == '05' format(5, base=16) == '5' format(5, base=16, prefix=True) == '0x5' Or something like that. Then there can be symmetry with int() (arbitrary bases) and we get rid of 2 other builtins eventually. Not sure if there are/should be uses other than number formating. > > that hex() and oct() return valid Python expressions in that base. > > In order for it to make sense, Python would need to grow some syntax. > > Fair enough. So let's define it. > > > If Python were to have syntax for binary literals, I'd propose a > > trailing b: "1100b". It would be convenient at times to represent > > bit flags, but I'm not sure it's worth the syntax change. > > Typically, suffixes are used to indicated *types*: 12L, 12j, and even > 12e0 in some sense. > > The binary type should have a 0b prefix. -0. Is this common enough to add (even in 3k)? For the instances I could have used this, it would have been completely impractical since the hex strings were generally over 80 characters. n ___ 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] str with base
Guido van Rossum wrote:
[...]
>
> I'd propose bin() to stay in line with the short abbreviated names.
>
[...]
>
> The binary type should have a 0b prefix.
It seems odd to me to add both a builtin *and* new syntax for something that's
occasionally handy, but only occasionally. If we're going to clutter a module
with this function, why not e.g. the math module instead of builtins? I thought
the consensus was that we had too many builtins already.
Similarly, the need for 0b101 syntax seems pretty low to me when you can
already do int("101", 2).
-Andrew.
___
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] str with base
Jack Diederich <[EMAIL PROTECTED]> writes: > > However... if %b were to represent arbitrary bases, I think that's > > backwards. It should be %[][.]b, which would do this: > > > > >>> '%08b %08o %08d %08x' % 12 > > '1100 0014 0012 000C' > > > > Were I BDFAD (not to be confused with BD-FOAD) I'd add %b, %B and, binary() > to match %x, %X, and hex(). The arbitrary base case isn't even academic > or we would see homework questions about it on c.l.py. No one asks about > hex or octal because they are there. No one asks about base seven > formatting because everyone knows numerologists prefer Perl. BTW, Perl already do binary literals and %b formatting so there is some precedence for it: $ perl -e '$a = 0b1100; printf "%08b %08o %08d %08x\n", $a, $a, $a, $a' 1100 0014 0012 000c --Gisle ___ 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
