Re: [Python-Dev] str with base
> "BAW" == Barry Warsaw <[EMAIL PROTECTED]> writes: BAW> Unix weenies shouldn't be totally forgotten in P3K. Great idea! Put all this stuff in a "weenie" module. You can have weenie.unix and weenie.vms and weenie.unicode, besides the weenie.math that got all this started. -- 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 Fri, 2006-01-20 at 06:56 +1000, Nick Coghlan wrote:
> I'm not aware of anyone that would miss octal literals, but there are plenty
> of hardware weenies like me that would find "int("DEAD", 16)" less convenient
> than "0xDEAD".
Although octal literals is handy for things like os.chmod(). Unix
weenies shouldn't be totally forgotten in P3K. I'm also for keeping
hex() and oct() although if you want to move them out of builtins,
that's fine. +0b1 for binary literals and %b.
-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] str with base
On Jan 19, 2006, at 4:17 PM, Thomas Wouters wrote: > On Fri, Jan 20, 2006 at 06:56:23AM +1000, Nick Coghlan wrote: > >> I'm not aware of anyone that would miss octal literals, > > Except anyone who uses os.chmod. I would be mighty sad if we > removed octal > and hexadecimal literals for 'cleanliness' reasons alone. I have a LOT of code that has hex literals, and a little code with oct literals (as you say, just os.chmod). I'm -1 on removing hex and oct, and +0 on adding binary. As a point of reference, both Perl and Ruby support 0b110 binary literal syntax $ ruby -e 'print 0b110, "\n"' 6 $ perl -e 'print 0b110 . "\n"' 6 -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 Fri, Jan 20, 2006 at 06:56:23AM +1000, Nick Coghlan wrote: > I'm not aware of anyone that would miss octal literals, Except anyone who uses os.chmod. I would be mighty sad if we removed octal and hexadecimal literals for 'cleanliness' reasons alone. -- 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] str with base
[Nick Coghlan] > ... > I quite like the suggestion of using 'math.base' rather than a builtin, but > there are still issues to be figured out there: >- the math module is currently a thin wrapper around C's "math.h". Do we > really want to change that by adding more methods? That's not an issue. Some math functions go beyond C's (like 2-argument log(), and all flavors of log() returning sensible results for inputs larger than the largest C double), and some functions aren't part of C at all (like math.radians()). A stronger reason to keep it out of `math` is that all functions there operate on, and return, floats: it's a bizarre place to put an integer->string function. >- is 'base' the right name? >- should we allow a "digits" argument, or just the radix argument? Add to_base(self, radix=16) as a new numeric method. End of problem ;-) ___ 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
Nick Coghlan wrote:
> Guido van Rossum wrote:
>
>>On 1/19/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>>
>>>Guido van Rossum wrote:
>>>
>>>
I think we ought to let this sit for a while and come back to it in a
few week's time. Is 'base' really the right name? It could just as
well be considered a conversion in the other direction.
>>>
>>>the same applies to hex and oct, of course.
>>
>>Right. And this is not a hypothetical issue either -- in Perl, hex and
>>oct *do* work the other way I believe. More reasons to get rid of
>>these in Python 3000. Perhaps we should also get rid of hex/oct
>>lterals?
>
>
> I'm not aware of anyone that would miss octal literals, but there are plenty
> of hardware weenies like me that would find "int("DEAD", 16)" less convenient
> than "0xDEAD". Python is a bit too heavyweight for a lot of embedded work,
> but
> its *great* for writing host-based test harnesses.
>
> I quite like the suggestion of using 'math.base' rather than a builtin, but
> there are still issues to be figured out there:
>- the math module is currently a thin wrapper around C's "math.h". Do we
> really want to change that by adding more methods?
>- is 'base' the right name?
>- should we allow a "digits" argument, or just the radix argument?
>
Another possibility, since Python 3 can break backward compatibility: we
could take a page out of Icon's book and use an "rN" suffix for
non-decimal literals.
23 == 27r8 == 17r16
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/
___
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:
> On 1/19/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>>
>>> I think we ought to let this sit for a while and come back to it in a
>>> few week's time. Is 'base' really the right name? It could just as
>>> well be considered a conversion in the other direction.
>> the same applies to hex and oct, of course.
>
> Right. And this is not a hypothetical issue either -- in Perl, hex and
> oct *do* work the other way I believe. More reasons to get rid of
> these in Python 3000. Perhaps we should also get rid of hex/oct
> lterals?
I'm not aware of anyone that would miss octal literals, but there are plenty
of hardware weenies like me that would find "int("DEAD", 16)" less convenient
than "0xDEAD". Python is a bit too heavyweight for a lot of embedded work, but
its *great* for writing host-based test harnesses.
I quite like the suggestion of using 'math.base' rather than a builtin, but
there are still issues to be figured out there:
- the math module is currently a thin wrapper around C's "math.h". Do we
really want to change that by adding more methods?
- is 'base' the right name?
- should we allow a "digits" argument, or just the radix argument?
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] str with base
On Jan 19, 2006, at 11:12 AM, Guido van Rossum wrote:
> On 1/19/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>>
>>> I think we ought to let this sit for a while and come back to it
>>> in a
>>> few week's time. Is 'base' really the right name? It could just as
>>> well be considered a conversion in the other direction.
>>
>> the same applies to hex and oct, of course.
>
> Right. And this is not a hypothetical issue either -- in Perl, hex and
> oct *do* work the other way I believe. More reasons to get rid of
> these in Python 3000. Perhaps we should also get rid of hex/oct
> lterals?
In Perl, hex(n) is like int(n, 16) and oct(n) is like int(n, 8) --
but they "try very hard" to make sense out of the given scalar (e.g.
more like int(n, 0) with a suggestion for base).
$ perl -e 'print hex("12") . " " . oct("12") . " " . oct("0x12") . "
" . hex("fubar")'
18 10 18 15
If you notice, oct("0x12") gives the hexadecimal result, and the
functions will try and make a value even out of garbage data.
In Ruby, you have the optional radix argument to_s and to_i, where
to_i will just return 0 for invalid values. They will take any radix
from 2..36.
$ irb
irb(main):001:0> 12.to_s
=> "12"
irb(main):002:0> 12.to_s(16)
=> "c"
irb(main):003:0> 12.to_s(8)
=> "14"
irb(main):004:0> "12".to_i(8)
=> 10
irb(main):005:0> "12".to_i(16)
=> 18
irb(main):006:0> "0x12".to_i(16)
=> 18
irb(main):007:0> "0x12".to_i(8)
=> 0
irb(main):008:0> "0x12".to_i
=> 0
irb(main):009:0> "fubar".to_i
=> 0
irb(main):010:0> "fubar".to_i(36)
=> 26608563
-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/19/06, Aahz <[EMAIL PROTECTED]> wrote: > On Thu, Jan 19, 2006, Jeremy Hylton wrote: > > > > I'm not sure I believe this should be a builtin. I think the > > threshold for new builtins ought to be nearly as high as the threshold > > for new keywords. Or the proposer ought to make an argument about > > what the function should not go in a module. > > The way I'd put it, any function that wants to go in builtins should > require a formal PEP. I'm suggesting a criterion for evaluating the choice of builtin vs. module, not making a suggestion about the process. Jeremy ___ 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 Hettinger wrote:
> That suggests that it would be better to simply add an int method:
> x.convert_to_base(7)
I'd suggest allowing:
x.convert_to_base('0123456')
Where the (str or unicode) argument is the list of digits in order.
This would allow easy converting to base-64 and other weird formats, as
well as providing decimal conversion into some unicode number ranges
outside the ASCII group.
--Scott David Daniels
[EMAIL PROTECTED]
___
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 Thu, Jan 19, 2006, Jeremy Hylton wrote: > > I'm not sure I believe this should be a builtin. I think the > threshold for new builtins ought to be nearly as high as the threshold > for new keywords. Or the proposer ought to make an argument about > what the function should not go in a module. The way I'd put it, any function that wants to go in builtins should require a formal PEP. And in case it isn't clear, I'm +1 on deprecating oct()/hex() (or moving them into another module as convenience functions for base() -- just to make conversion easier). -- 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
Re: [Python-Dev] str with base
On 1/19/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > > I think we ought to let this sit for a while and come back to it in a > > few week's time. Is 'base' really the right name? It could just as > > well be considered a conversion in the other direction. > > the same applies to hex and oct, of course. Right. And this is not a hypothetical issue either -- in Perl, hex and oct *do* work the other way I believe. More reasons to get rid of these in Python 3000. Perhaps we should also get rid of hex/oct lterals? > as for base itself, I'm more concerned about the google product place- > ment here. what's next? a froogle builtin? The default __import__ will use Google Code to locate an appropriate module to import instead of restricting itself to the boring and predictable sys.path. -- --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
Guido van Rossum wrote: > I think we ought to let this sit for a while and come back to it in a > few week's time. Is 'base' really the right name? It could just as > well be considered a conversion in the other direction. the same applies to hex and oct, of course. as for base itself, I'm more concerned about the google product place- ment here. what's next? a froogle builtin? ___ 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 19, 2006, at 10:31, Guido van Rossum wrote:
To keep it simple, the proposal is for the value to be any int or
long.
With an underlying __base__ method call, it wouldn't be hard for
someone
to build it out to support other numeric types if the need arises.
Let's not. What would 3.14 be expressed in base 3?
10.010210001
It turned out to be a fun aside, and I've attached my quick and dirty
script as a strawman.
For what it's worth, I don't like the name base() because it sounds
like something I would call on a class to get it's bases. Perhaps
nbase? And maybe fbase for the floating point one...
Thanks,
-Shane Holloway
#!/usr/bin/env python
#
#~ Imports
#
import math
#
#~ Definitions
#
def ibase(n, radix=2, maxlen=None):
r = []
while n:
n,p = divmod(n, radix)
r.append('%d' % p)
if maxlen and len(r) > maxlen:
break
r.reverse()
return ''.join(r)
def fbase(n, radix=2, maxlen=8):
r = []
f = math.modf(n)[0]
while f:
f, p = math.modf(f*radix)
r.append('%.0f' % p)
if maxlen and len(r) > maxlen:
break
return ''.join(r)
def base(n, radix, maxfloat=8):
if isinstance(n, float):
return ibase(n, radix)+'.'+fbase(n, radix, maxfloat)
elif isinstance(n, (str, unicode)):
n,f = n.split('.')
n = int(n, radix)
f = int(f, radix)/float(radix**len(f))
return n + f
else:
return ibase(n, radix)
#
#~ Main
#
if __name__=='__main__':
pi = 3.14
print 'pi:', pi, 'base 10'
piBase3 = base(pi, 3)
print 'pi:', piBase3, 'base 3'
piFromBase3 = base(piBase3, 3)
print 'pi:', piFromBase3, 'base 10 from base 3'
___
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
I'm not sure I believe this should be a builtin. I think the threshold for new builtins ought to be nearly as high as the threshold for new keywords. Or the proposer ought to make an argument about what the function should not go in a module. Jeremy On 1/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 1/18/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > Guido, we may be converging on a consensus for my proposal: > > > > base(value, radix=2) > > > > So far no one has shot at it, and it has gathered +1's from Steven, > > Alex, Brett, and Nick. > > I think we ought to let this sit for a while and come back to it in a > few week's time. Is 'base' really the right name? It could just as > well be considered a conversion in the other direction. In common > usage, 'base' and 'radix' are about synonymous (except no-one uses > radix). Pethaps the 2nd argument should not be a keyword argument? > > Also, this discussion made me wonder if conversions using other bases > than 10 should even be built-ins. A library module seems a more > appropriate place. The prevalence here of people who actually use hex > numbers on a regular basis is probably easily explained by a > combination of old-timers, language implementers, and super-geeks; > hardly the typical Python user. The desire of (bright) beginners to do > any kind of non-decimal conversion probably stems from a misguided > meme (dating back to the invention of computers) that in order to > learn about computers you ought to begin by learning about Boolean > algebra and binary numbers. That might be true long ago, but today, > binary, octal and hexadecimal numbers are mostly a curiosity used in > obscure low-level APIs like ioctl(). > > > To keep it simple, the proposal is for the value to be any int or long. > > With an underlying __base__ method call, it wouldn't be hard for someone > > to build it out to support other numeric types if the need arises. > > Let's not. What would 3.14 be expressed in base 3? > > > The output would have no prefixes. As Alex pointed out, it is easier > > and more direct to add those after the fact if needed. > > Agreed. > > > Care to pronounce on it? > > Rather not yet. > > -- > --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/jeremy%40alum.mit.edu > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
On 1/18/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > Guido, we may be converging on a consensus for my proposal: > > base(value, radix=2) > > So far no one has shot at it, and it has gathered +1's from Steven, > Alex, Brett, and Nick. I think we ought to let this sit for a while and come back to it in a few week's time. Is 'base' really the right name? It could just as well be considered a conversion in the other direction. In common usage, 'base' and 'radix' are about synonymous (except no-one uses radix). Pethaps the 2nd argument should not be a keyword argument? Also, this discussion made me wonder if conversions using other bases than 10 should even be built-ins. A library module seems a more appropriate place. The prevalence here of people who actually use hex numbers on a regular basis is probably easily explained by a combination of old-timers, language implementers, and super-geeks; hardly the typical Python user. The desire of (bright) beginners to do any kind of non-decimal conversion probably stems from a misguided meme (dating back to the invention of computers) that in order to learn about computers you ought to begin by learning about Boolean algebra and binary numbers. That might be true long ago, but today, binary, octal and hexadecimal numbers are mostly a curiosity used in obscure low-level APIs like ioctl(). > To keep it simple, the proposal is for the value to be any int or long. > With an underlying __base__ method call, it wouldn't be hard for someone > to build it out to support other numeric types if the need arises. Let's not. What would 3.14 be expressed in base 3? > The output would have no prefixes. As Alex pointed out, it is easier > and more direct to add those after the fact if needed. Agreed. > Care to pronounce on it? Rather not yet. -- --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 Thursday 2006-01-19 11:15, Thomas Wouters wrote:
> On Thu, Jan 19, 2006 at 10:23:30AM +, Gareth McCaughan wrote:
...
> > Introducing a new builtin with a name that's a common, short
> > English word is a bit disagreeable.
>
> While I don't particularly mind the new function in either the builtin
> module or another, like math, I don't understand the problem with the name.
> Most builtin names are short and english-ish words. I like that, I'm glad
> they are that way, and the two names I dislike most are 'isinstance' and
> 'issubclass'.
"issubclass" is horrible because wordsjammedtogetherlikethisarehardtoread,
especially when they're misleading as to pronunciation ("iss-ubclass").
Short English words are nice because they're easy to type and
(at least sometimes) their meanings are immediately obvious.
For the same reason, they're useful as variable names. Of course
the world doesn't end if a builtin name is the same as a variable
name you'd like to use, but it's ... well, "a bit disagreeable"
probably expresses about the right degree of nuisance.
> > The other thing about the name "base" is that it's not entirely obvious
> > which way it converts: do you say
> >
> > base(123,5)
> >
> > to get a string representing 123 in base 5, or
> >
> > base("123",5)
> >
> > to get the integer whose base 5 representation is "123"?
>
> This is an argument for 'str(123, 5)', but I don't agree.
It's not (intended as) an argument *for* any particular form.
> Not _everything_
> has to be obvious at first glance. The very same could be said about hex(),
> oct(), dir(), even names like list() (what does it list?), str() (stripping
> something?), etc.
Actually, I happen to dislike hex() slightly -- I never use or see
oct(), so don't much care about that -- for exactly that reason.
> Having int() do it one way and base() the other makes fine
> sense to me, and I don't see it as any harder to explain than, say, why
> hex("123") doesn't return 291. I've personally never had to explain
> hex/oct's behaviour.
To me, base() is less obvious than hex(), which itself is just
ambiguous enough to cost me maybe one second per month. Not a big
deal at all, but not zero.
> While I think 'str' would be a slightly better name than 'base' (despite the
> specialcasing of numbers,) I don't mind either. I do mind names like
> 'to_base' or 'as_str' or 'shouldbestr' or other names that make me turn on
> autocompletion in my editor.
You need to turn off the Python Mind Control feature. :-)
I think math.base (apart from sounding like it ought to be a
variable that controls the base in which numbers are represented,
or something of the sort) is about as much typing as to_base,
so I'm not sure how the latter can be much worse in this respect.
> > Alternatively, a name like "to_base" that clarifies the intent and is less
> > likely to clash with variable names might be an improvement.
>
> Builtins aren't reserved names, so the clash is minimal.
Sure, it's not disabling. But in practice it's nice to be able
to avoid builtin names, and "base" is a word I'd rather not have
to take measures to avoid: too many meanings, some of them
quite common.
(I don't care much about this, and if base() gets introduced
I shan't complain.)
--
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] str with base
On Thu, Jan 19, 2006 at 10:23:30AM +, Gareth McCaughan wrote:
> > +1 on introducing base()
> Introducing a new builtin with a name that's a common, short
> English word is a bit disagreeable.
While I don't particularly mind the new function in either the builtin
module or another, like math, I don't understand the problem with the name.
Most builtin names are short and english-ish words. I like that, I'm glad
they are that way, and the two names I dislike most are 'isinstance' and
'issubclass'.
> The other thing about the name "base" is that it's not entirely obvious
> which way it converts: do you say
>
> base(123,5)
>
> to get a string representing 123 in base 5, or
>
> base("123",5)
>
> to get the integer whose base 5 representation is "123"?
This is an argument for 'str(123, 5)', but I don't agree. Not _everything_
has to be obvious at first glance. The very same could be said about hex(),
oct(), dir(), even names like list() (what does it list?), str() (stripping
something?), etc. Having int() do it one way and base() the other makes fine
sense to me, and I don't see it as any harder to explain than, say, why
hex("123") doesn't return 291. I've personally never had to explain
hex/oct's behaviour.
While I think 'str' would be a slightly better name than 'base' (despite the
specialcasing of numbers,) I don't mind either. I do mind names like
'to_base' or 'as_str' or 'shouldbestr' or other names that make me turn on
autocompletion in my editor.
> Alternatively, a name like "to_base" that clarifies the intent and is less
> likely to clash with variable names might be an improvement.
Builtins aren't reserved names, so the clash is minimal.
--
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] str with base
On Wednesday 2006-01-18 16:55, Steven Bethard wrote:
> [Raymond]
> > Perhaps introduce a single function, base(val, radix=10,
> > prefix=''), as a universal base converter that could replace
> > bin(), hex(), oct(), etc.
>
> +1 on introducing base()
Introducing a new builtin with a name that's a common, short
English word is a bit disagreeable. The other thing about the
name "base" is that it's not entirely obvious which way it
converts: do you say
base(123,5)
to get a string representing 123 in base 5, or
base("123",5)
to get the integer whose base 5 representation is "123"?
Well, one option would be to have both of those work :-).
(Some people may need to do some deep breathing while
reciting the mantra "practicality beats purity" in order
to contemplate that with equanimity.)
Alternatively, a name like "to_base" that clarifies the
intent and is less likely to clash with variable names
might be an improvement.
Or there's always %b, whether that ends up standing for
"binary" or "base". Or %b for binary and %r for radix,
not forgetting the modifiers to get numbers formatted
as Roman numerals.
--
Gareth McCaughan
___
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 18, 2006, at 11:37 PM, Neal Norwitz wrote: > On 1/18/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: >> Guido, we may be converging on a consensus for my proposal: >> >> base(value, radix=2) >> >> So far no one has shot at it, and it has gathered +1's from Steven, >> Alex, Brett, and Nick. > > +1 for me too, but I'd also like to deprecate hex() and oct() and > slate them for removal in 3k. > > To expand, valid radix values would be 2..36 (ie, same as for int). > It was discussed putting base() in some module. Was there consensus > about builtin vs a module? I'd prefer a module, but builtin is ok > with me. I'd drop the default radix, or make it something common like 16... especially if hex and oct are to be py3k deprecated. +1 for: base(value, radix) +1 for: "%b" % (integer,) +0 for binary literals: 0b01101 -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/18/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > Guido, we may be converging on a consensus for my proposal: > > base(value, radix=2) > > So far no one has shot at it, and it has gathered +1's from Steven, > Alex, Brett, and Nick. +1 for me too, but I'd also like to deprecate hex() and oct() and slate them for removal in 3k. To expand, valid radix values would be 2..36 (ie, same as for int). It was discussed putting base() in some module. Was there consensus about builtin vs a module? I'd prefer a module, but builtin is ok with me. > To keep it simple, the proposal is for the value to be any int or long. > With an underlying __base__ method call, it wouldn't be hard for someone > to build it out to support other numeric types if the need arises. > > The output would have no prefixes. As Alex pointed out, it is easier > and more direct to add those after the fact if needed. +1 > Care to pronounce on 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] str with base
Guido, we may be converging on a consensus for my proposal: base(value, radix=2) So far no one has shot at it, and it has gathered +1's from Steven, Alex, Brett, and Nick. To keep it simple, the proposal is for the value to be any int or long. With an underlying __base__ method call, it wouldn't be hard for someone to build it out to support other numeric types if the need arises. The output would have no prefixes. As Alex pointed out, it is easier and more direct to add those after the fact if needed. Care to pronounce on 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] str with base
On 1/18/06, Alex Martelli <[EMAIL PROTECTED]> wrote: > On Jan 18, 2006, at 11:09 AM, Brett Cannon wrote: > > > On 1/18/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > I'd propose bin() to stay in line with the short abbreviated names. > >>> > >>> There has been some previous discussion about removing hex()/oct() > >> from > >>> builtins for Python 3.0, IIRC. I sure don't think bin() belongs > >> there. > >> > >> Perhaps introduce a single function, base(val, radix=10, > >> prefix=''), as > >> a universal base converter that could replace bin(), hex(), oct(), > >> etc. > >> > >> That would give us fewer builtins and provide an inverse for all the > >> int() conversions (i.e. arbitrary bases). Also, it would allow an > >> unprefixed output which is what I usually need. > > > > +1. Differs from Neal's format() function by not magically > > determining the prefix from the radix which I like. > > I'm not sure I see the advantage of, say, > > print base(x, radix=2, prefix='0b') > > versus > > print '0b'+base(x, radix=2) > > IOW, if the prefix needs to be explicitly specified anyway, what's > the advantage of specifying it as an argument to base, rather than > just string-concatenating it? It collects the data that is expected to be used in the common case in a single location/operation. This would allow you to do something like ``base(x, **radix_and_prefix_dict)`` and have everythihng in a nice, neat package. Plus the operation would be faster if base() is written in C. =) The other option is to go with Neal's solution for automatically including the prefix for known prefix types, but instead of it being a boolean, let it be a string argument. That means if you want no prefix you would just set the argument to the empty string. Not setting it will just use the most sensible prefix or none if one is not known for the specified radix. Could have something somewhere, like string or math, where more radix/prefix pairs can be added by the user and have base() reference that for its prefix values. IOW I am +0 on prefix in one of these forms. -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 Jan 18, 2006, at 11:09 AM, Brett Cannon wrote: > On 1/18/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: I'd propose bin() to stay in line with the short abbreviated names. >>> >>> There has been some previous discussion about removing hex()/oct() >> from >>> builtins for Python 3.0, IIRC. I sure don't think bin() belongs >> there. >> >> Perhaps introduce a single function, base(val, radix=10, >> prefix=''), as >> a universal base converter that could replace bin(), hex(), oct(), >> etc. >> >> That would give us fewer builtins and provide an inverse for all the >> int() conversions (i.e. arbitrary bases). Also, it would allow an >> unprefixed output which is what I usually need. > > +1. Differs from Neal's format() function by not magically > determining the prefix from the radix which I like. I'm not sure I see the advantage of, say, print base(x, radix=2, prefix='0b') versus print '0b'+base(x, radix=2) IOW, if the prefix needs to be explicitly specified anyway, what's the advantage of specifying it as an argument to base, rather than just string-concatenating it? Apart from that quibble, the base function appears to cover all the use cases for my proposed str-with-base, so, since it appears to attract less arguments, I'm definitely +1 on it. 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
Brett Cannon wrote: > On 1/18/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: I'd propose bin() to stay in line with the short abbreviated names. >>> There has been some previous discussion about removing hex()/oct() >> from >>> builtins for Python 3.0, IIRC. I sure don't think bin() belongs >> there. >> >> Perhaps introduce a single function, base(val, radix=10, prefix=''), as >> a universal base converter that could replace bin(), hex(), oct(), etc. >> >> That would give us fewer builtins and provide an inverse for all the >> int() conversions (i.e. arbitrary bases). Also, it would allow an >> unprefixed output which is what I usually need. >> > > +1. Differs from Neal's format() function by not magically > determining the prefix from the radix which I like. +1 here, too, particularly if hex/oct acquire Deprecation (or even just PendingDeprecation) warnings at the same time. I have my own reason for wanting to avoid the name format() - I'd still like to see it used one day to provide a builtin way to use string.Template syntax for arbitrary string formatting. 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
[Python-Dev] str with base
Jack wrote: > 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. I have wanted base-36 far more often than I've wanted base-8. I haven't needed any base (except 10) often enough to justify putting it in builtins rather than a stdlib module. I do like the idea of adding Raymond's def base(number, base, prefix) to the stdlib (possibly in math). -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
On 1/18/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > > I'd propose bin() to stay in line with the short abbreviated names. > > > > There has been some previous discussion about removing hex()/oct() > from > > builtins for Python 3.0, IIRC. I sure don't think bin() belongs > there. > > Perhaps introduce a single function, base(val, radix=10, prefix=''), as > a universal base converter that could replace bin(), hex(), oct(), etc. > > That would give us fewer builtins and provide an inverse for all the > int() conversions (i.e. arbitrary bases). Also, it would allow an > unprefixed output which is what I usually need. > +1. Differs from Neal's format() function by not magically determining the prefix from the radix which I like. -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
Jason Orendorff wrote: > On 1/18/06, Donovan Baarda <[EMAIL PROTECTED]> wrote: > >>I think supporting arbitrary bases for floats is way overkill and not >>worth considering. > > > If you mean actual base-3 floating-point arithmetic, I agree. That's > outlandish. > > But if there were a stdlib function to format floats losslessly in hex > or binary, Tim Peters would use it at least once every six weeks to > illustrate the finer points of floating point arithmetic. <0.00390625 > wink> > > +1.0 > Nah, Tim's got the chops to use the struct model to get his point across. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ ___ 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] > Perhaps introduce a single function, base(val, radix=10, > prefix=''), as a universal base converter that could replace > bin(), hex(), oct(), etc. +1 on introducing base() [Skip] > Would it (should it) work with floats, decimals, complexes? I presume it > would work with ints and longs. While support for floats, decimals, etc. might be nice (and I certainly wouldn't complain if someone wanted to supply the patch) I don't think those features should be necessary for base()'s initial introduction. If they're there, great, but if not, I don't think that should hold up the patch... STeVe -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ 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/18/06, Donovan Baarda <[EMAIL PROTECTED]> wrote: > I think supporting arbitrary bases for floats is way overkill and not > worth considering. If you mean actual base-3 floating-point arithmetic, I agree. That's outlandish. But if there were a stdlib function to format floats losslessly in hex or binary, Tim Peters would use it at least once every six weeks to illustrate the finer points of floating point arithmetic. <0.00390625 wink> +1.0 -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
Raymond> Perhaps introduce a single function, base(val, radix=10, Raymond> prefix=''), as a universal base converter that could replace Raymond> bin(), hex(), oct(), etc. Would it (should it) work with floats, decimals, complexes? I presume it would work with ints and longs. 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
> > I'd propose bin() to stay in line with the short abbreviated names. > > There has been some previous discussion about removing hex()/oct() from > builtins for Python 3.0, IIRC. I sure don't think bin() belongs there. Perhaps introduce a single function, base(val, radix=10, prefix=''), as a universal base converter that could replace bin(), hex(), oct(), etc. That would give us fewer builtins and provide an inverse for all the int() conversions (i.e. arbitrary bases). Also, it would allow an unprefixed output which is what I usually need. 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] str with base
On Tue, Jan 17, 2006, Guido van Rossum wrote: > On 1/17/06, Bob Ippolito <[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. There has been some previous discussion about removing hex()/oct() from builtins for Python 3.0, IIRC. I sure don't think bin() belongs there. > The binary type should have a 0b prefix. -0 on adding a new prefix; +1 on this syntax if we do. -- 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
Re: [Python-Dev] str with base
On Tue, 2006-01-17 at 20:25 -0800, Guido van Rossum 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 [...] so %b is "binary", +1 > > The difference between hex() and oct() and the proposed binary() is > > I'd propose bin() to stay in line with the short abbreviated names. [...] +1 > The binary type should have a 0b prefix. [...] +1 For those who argue "who would ever use it?", I would :-) Note that this does not support and is independent of supporting arbitrary bases. I don't think we need to support arbitrary bases, but if we did I would vote for ".precision" to mean ".base" for "%d"... ie; "%3.3d" % 5 == " 12" I think supporting arbitrary bases for floats is way overkill and not worth considering. -- 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
On Tue, 2006-01-17 at 16:38 -0700, 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 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. [...] Heh... that's pretty much why I used base16 float notation when doing fixed point stuff in assembler... uses less digits than binary, but easily visualised as bits. However, I do think that we could go overboard here... I don't know that we really need arbitrary base string formatting for all numeric types. I think this is a case of "very little gained for too much added complexity". If we really do, and someone is prepared to implement it, then I think adding "@base" is the best way to do it (see my half joking post earlier). If we only want arbitrary bases for integer types, the best way would be to leverage off the existing ".precision" so that it means ".base" for "%d". > > 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. There's always "B" for bytes and "b" for bits... though I can't imagine why byte would need it's own conversion type. I'm not entirely sure everyone is on the same page for "%b" here... it would only be a shorthand for "binary" in the same way that "%x" is for "hexidecimal". It would not support arbitrary bases, and thus "%2b" would mean a binary string with minimum length of 2 characters. -- 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
Steve Holden wrote: [...] > Personally I wouldn't even be interested in seeing > 1.3407807929942597e+154 written in fixed point form *in decimal*, let > alone in binary where the representation, though unambiguous, would have > over 500 bits, most of them zeros. > Well, shot myself in the foot there of course, since the number I meant was actually 2.0 ** 512 (or 13407807929942597099574024998205846127479365820592393377723561443721764030073546 976801874298166903427690031858186486050853753882811946569946433649006084096.0) rather than the decimal approximation above. But I'm sure you get the point that fixed-point representations aren't always appropriate. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ ___ 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
Adam Olsen wrote: > 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. > Albeit with excessively long representations for the larger values one sometimes sees represented in float form. Personally I wouldn't even be interested in seeing 1.3407807929942597e+154 written in fixed point form *in decimal*, let alone in binary where the representation, though unambiguous, would have over 500 bits, most of them zeros. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ ___ 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
Adam Olsen wrote:
> 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.
>
I suppose we'd better reserve "%q" for 'quirky types we just invented',
too? ;-)
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/
___
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
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
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
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] 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 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
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 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 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 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 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] 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 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 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] 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, 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 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] 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] 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] 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] 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
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
[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] 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
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] 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
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
[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
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
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
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] 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
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
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
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: > 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
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
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
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] 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 1/16/06, Bob Ippolito <[EMAIL PROTECTED]> 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.
>
> >>> [name for name in dir(0)+dir(0L) if not name.startswith('__')]
If a method is the best solution, then fine, 2.5 is the beginning of
methods on int/long. We could do a static method like
int.from_str("101", 2) and str.from_int(5, 2) if people don't like the
overloading of the constructors. Otherwise add methods like
'101'.to_int(2) or 5 .to_str(2) .
-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]
> > 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". :-)
>
> 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". :-)
>
> 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.
>
> 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'.
>
> 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
> __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. 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
> 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.
>
+1 from me (feel like this has come up before, but not totally sure).
Be nice to add an abstraction for indexing.
Added to the PyCon wiki as a possible sprint topic.
-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 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 -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] str with base
On Mon, Jan 16, 2006 at 09:28:10PM -0800, Bob Ippolito wrote:
> On Jan 16, 2006, at 9:12 PM, Andrew Bennetts wrote:
[...]
> >> 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.
>
> >>> [name for name in dir(0)+dir(0L) if not name.startswith('__')]
> []
I should have said, I'm equally happy with the format code as well (although it
doesn't allow arbitary base conversions, I've never had need for that, so I'm
not too worried about that case). Either option is better than making the str
constructor do relatively rarely used mathematics!
-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
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.
>>> [name for name in dir(0)+dir(0L) if not name.startswith('__')]
[]
-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 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. -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
[Jeremy Hylton] > The concept of base is closely related to ints, and the base argument > is useful for a large percentage of the types that int accepts. It is > not related to strings, in general, and applies to only one of the > types it accepts. In one case "not a float, etc." applies to a very > limited set of types, in the other case it applies to every > conceivable type (except int). That suggests that it would be better to simply add an int method: x.convert_to_base(7) 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] str with base
On Jan 16, 2006, at 8:18 PM, Barry Warsaw wrote:
> On Tue, 2006-01-17 at 15:08 +1100, Andrew Bennetts wrote:
>
>> My reaction having read this far was "huh?". It took some time
>> (several
>> seconds) before it occurred to me what you wanted str(5,2) to
>> mean, and why it
>> should give '101'.
>>
>> If you'd proposed, say (5).as_binary() == '101', or "5".encode
>> ("base2"), I
>> wouldn't have been as baffled. Or perhaps even str(5, base=2),
>> but frankly the
>> idea of the string type doing numeric base conversions seems weird
>> to me, rather
>> than symmetric.
>>
>> I wouldn't mind seeing arbitrary base encoding of integers
>> included somewhere,
>> but as a method of str -- let alone the constructor! -- it feels
>> quite wrong.
>
> Hear, hear. I was similarly perplexed when I first read that!
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'
I'd probably expect "5".encode("base2") to return '00110101', because
"5".encode("hex") returns '35'
-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/16/06, Alex Martelli <[EMAIL PROTECTED]> wrote: > > On Jan 16, 2006, at 8:03 PM, Jeremy Hylton wrote: > > I think it shouldn't be changed, because the second positional > > argument only works for a small number of the panoply types that can > > be passed to str(). > > Identically the same situation as for int: the base argument is only > accepted if the first argument is a str (not a float, etc). Just the > same way, the base argument to str will only be accepted if the first > argument is an int (not a float, etc). The concept of base is closely related to ints, and the base argument is useful for a large percentage of the types that int accepts. It is not related to strings, in general, and applies to only one of the types it accepts. In one case "not a float, etc." applies to a very limited set of types, in the other case it applies to every conceivable type (except int). If str() were to take two argument, the analogy with int suggests it should be an encoding, where the second argument describes how to interpret the representation of the first (it's base 7 or it's utf-8). Jeremy ___ 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 16, 2006, at 8:03 PM, Jeremy Hylton wrote: > It never occured to me that str() would behave like int() for this > case. It makes complete sense to me that a factory for numbers would > ask about the base of the number. What would the base of a string be, > except in a few limited cases? str([1, 2], 4) doesn't make any sense. > You might argue that I wasn't all that bright as a beginner <0.5 > wink>. > > I think it shouldn't be changed, because the second positional > argument only works for a small number of the panoply types that can > be passed to str(). Identically the same situation as for int: the base argument is only accepted if the first argument is a str (not a float, etc). Just the same way, the base argument to str will only be accepted if the first argument is an int (not a float, etc). 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 Tue, 2006-01-17 at 15:08 +1100, Andrew Bennetts wrote:
> My reaction having read this far was "huh?". It took some time (several
> seconds) before it occurred to me what you wanted str(5,2) to mean, and why it
> should give '101'.
>
> If you'd proposed, say (5).as_binary() == '101', or "5".encode("base2"), I
> wouldn't have been as baffled. Or perhaps even str(5, base=2), but frankly
> the
> idea of the string type doing numeric base conversions seems weird to me,
> rather
> than symmetric.
>
> I wouldn't mind seeing arbitrary base encoding of integers included somewhere,
> but as a method of str -- let alone the constructor! -- it feels quite wrong.
Hear, hear. I was similarly perplexed when I first read that!
-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] str with base
On Mon, 16 Jan 2006 19:44:44 -0800, 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)
>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. Confusing and non-obvious. The functionality may be valuable but
it is mis-placed as a feature of str() or a method of the str type. I
work with a lot of Python beginners too, and while they occassionally
ask for this functionality, I've never heard anyone wonder why str()
didn't provide it or suggest that it should.
Jean-Paul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
> I wish you had an argument better than "every bright beginner assumes > it exists". :-) > > 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". :-) 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. Another quick thought: 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. 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] str with base
On Mon, Jan 16, 2006 at 07:44:44PM -0800, Alex Martelli wrote:
> Is it finally time in Python 2.5 to allow the "obvious" use of, say,
> str(5,2) to give '101',
My reaction having read this far was "huh?". It took some time (several
seconds) before it occurred to me what you wanted str(5,2) to mean, and why it
should give '101'.
If you'd proposed, say (5).as_binary() == '101', or "5".encode("base2"), I
wouldn't have been as baffled. Or perhaps even str(5, base=2), but frankly the
idea of the string type doing numeric base conversions seems weird to me, rather
than symmetric.
I wouldn't mind seeing arbitrary base encoding of integers included somewhere,
but as a method of str -- let alone the constructor! -- it feels quite wrong.
-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
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]
> 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". :-)
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". :-)
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.
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'.
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
__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. 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
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.
--
--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
It never occured to me that str() would behave like int() for this
case. It makes complete sense to me that a factory for numbers would
ask about the base of the number. What would the base of a string be,
except in a few limited cases? str([1, 2], 4) doesn't make any sense.
You might argue that I wasn't all that bright as a beginner <0.5
wink>.
I think it shouldn't be changed, because the second positional
argument only works for a small number of the panoply types that can
be passed to str(). It would be fine to have a function for this
hiding somewhere, perhaps even as a method on numbers, but str() is
too generic.
Jeremy
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)
> 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;-).
>
>
> 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/jeremy%40alum.mit.edu
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
> 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',2)
> gives 5?
+1
The only downside is that like list.reverse(), it will deprive students
of being assigned to write the roll-your-own version.
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] str with base
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 think you mean ``int('101' 2)``. =)
> 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'm +0. Not a big thing for me, but having the symmetry seems reasonable.
-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
[Python-Dev] str with base
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;-).
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
