Re: [Python-Dev] str with base

[Stephen J. Turnbull]

 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

[Gareth McCaughan]

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

[Thomas Wouters]

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

[Guido van Rossum]

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

[Shane Holloway (IEEE)]

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

[Aahz]

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

[Scott David Daniels]

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

[Jeremy Hylton]

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

[Bob Ippolito]

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

[Nick Coghlan]

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

[Steve Holden]

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

[Tim Peters]

[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

[Bob Ippolito]

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

[Barry Warsaw]

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

[Steve Holden]

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

[Steve Holden]

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

[Steve Holden]

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

[Donovan Baarda]

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

[Aahz]

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

[Raymond Hettinger]

  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

[skip]

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

[Jason Orendorff]

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

[Steve Holden]

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

[Brett Cannon]

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

[Python-Dev] str with base

[Jim Jewett]

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

[Nick Coghlan]

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

Re: [Python-Dev] str with base

[Alex Martelli]

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]

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

[Raymond Hettinger]

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

[Neal Norwitz]

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

[Bob Ippolito]

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

[Martin v. Löwis]

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

[Nick Craig-Wood]

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

[M.-A. Lemburg]

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

[Ian Bicking]

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

[Bob Ippolito]

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

[Fredrik Lundh]

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 ?

/F 



___
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]

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

[Michael Hudson]

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

-- 
  exarkun 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

[Jason Orendorff]

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

[Andrew Bennetts]

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

wink

-Andrew.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] str with base

[Jim Jewett]

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

[skip]

Raymond My reason is that I've rolled-my-own more times than I can
Raymond count but infrequently enough to where it was easier to
Raymond re-write than to search for the previous use.

Maybe a bin() builtin would be better.  Even better it seems to me would be
to add a method to ints and longs that returns a string formatted in a base
between 2 and 36 (then deprecate hex and oct).  Like Jeremy, I wonder what
str([1,2], 4) means.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] str with base

[skip]

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

[Gareth McCaughan]

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(a string) 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

[skip]

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

[Adam Olsen]

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

[Aahz]

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

[Alex Martelli]

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

[Guido van Rossum]

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

[Thomas Wouters]

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

[Adam Olsen]

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

[Guido van Rossum]

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

[Adam Olsen]

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

[Bob Ippolito]

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

[Jack Diederich]

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
  %[base][.pad]b

Where the optional base is the base to print in and pad 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

[Bob Ippolito]

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

[Bob Ippolito]

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
   %[base][.pad]b

 Where the optional base is the base to print in and pad 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 %[pad][.base]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

[Adam Olsen]

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

[Adam Olsen]

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

[Jack Diederich]

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
   %[base][.pad]b
 
 Where the optional base is the base to print in and pad 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 %[pad][.base]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

[Bob Ippolito]

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
  %[base][.pad]b

 Where the optional base is the base to print in and pad 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 %[pad][.base]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

[Guido van Rossum]

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

[Brett Cannon]

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

[Neal Norwitz]

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

[Andrew Bennetts]

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

[Gisle Aas]

Jack Diederich [EMAIL PROTECTED] writes:

  However... if %b were to represent arbitrary bases, I think that's  
  backwards.  It should be %[pad][.base]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

[Python-Dev] str with base

[Alex Martelli]

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

Re: [Python-Dev] str with base

[Brett Cannon]

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

Re: [Python-Dev] str with base

[Raymond Hettinger]

 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

[Jeremy Hylton]

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

[Guido van Rossum]

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

[Andrew Bennetts]

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

[Raymond Hettinger]

 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

[Jean-Paul Calderone]

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

[Barry Warsaw]

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

[Alex Martelli]

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

[Jeremy Hylton]

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

[Bob Ippolito]

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

[Raymond Hettinger]

[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

[Andrew Bennetts]

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

[Bob Ippolito]

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

[Andrew Bennetts]

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

[Barry Warsaw]

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

[Brett Cannon]

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

[Brett Cannon]

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