Re: [Python-Dev] str with base
On Fri, 2006-01-20 at 06:56 +1000, Nick Coghlan wrote:
> I'm not aware of anyone that would miss octal literals, but there are plenty
> of hardware weenies like me that would find "int("DEAD", 16)" less convenient
> than "0xDEAD".
Although octal literals is handy for things like os.chmod(). Unix
weenies shouldn't be totally forgotten in P3K. I'm also for keeping
hex() and oct() although if you want to move them out of builtins,
that's fine. +0b1 for binary literals and %b.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 343 and __context__()
I just noticed that my name is in PEP 343 attached to the idea of the __context__() method, and I'm slightly queasy over it. The rationale was to help e.g. decimal.DecimalContext support 'with'. Maybe that's a bad idea. DecimalContext has a few problems. In code where it matters, every function you write has to worry about it. (That is, you can't just write __decimal_context__ = ... at the top of the file and be done with it, the way you can with, say, __metaclass__.) And DecimalContext doesn't fit in with generators. sys.stdout has similar problems. It feels like PEP 343 will make people want to follow this model. That is, we'll see more global behavior-controlling variables in the future. There are grizzlier fates; I just wondered if anyone had thought of this. Cheers, -j ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
On 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] pystate.c changes for Python 2.4.2
[Gabriel Becedillas] > Can anybody tell me if the patch I suggested is ok ? > That will be to add the following code at the end of PyThreadState_Delete: > > if (autoTLSkey && PyThread_get_key_value(autoTLSkey) == tstate) > PyThread_delete_key_value(autoTLSkey); It needs a little work, but I think it should be fine, and people tend to listen to me on issues like this ;-) The reason it can't work as-is is shallow: autoTLSkey doesn't exist unless Python is compiled with WITH_THREAD defined. So you need to wrap that inside an "#ifdef WITH_THREAD" block; or add it similarly to tstate_delete_common(), and remove it from PyThreadState_DeleteCurrent(). The primary reason people find this so confusing is because it is :-). In the dim mists of history, neither multiple interpreters nor PyThreadState_DeleteCurrent() existed. While multiple interpreters do exist now, they're poorly understood, and the PEP that introduced the GIL state API explicitly disavowed any responsibility for the new API working at all with multiple interpreters: http://www.python.org/peps/pep-0311.html This proposal identifies a solution for extension authors with complex multi-threaded requirements, but that only require a single "PyInterpreterState". There is no attempt to cater for extensions that require multiple interpreter states. At the time of writing, no extension has been identified that requires multiple PyInterpreterStates, and indeed it is not clear if that facility works correctly in Python itself. In a parallel development, thread races during Python shutdown were discovered that could lead to segfaults, and PyThreadState_DeleteCurrent() was introduced to repair those. As a result, it so happens that core Python never uses the original PyThreadState_Delete() anymore, except when Py_NewInterpreter() has to throw away the brand new thread state it created because it turns out it can't create a new interpreter. Since core Python never calls Py_NewInterpreter() or PyThreadState_Delete(), you're in an intersection of areas no current Python developer even thinks about, let alone tests. But by the same token, _because_ it's unused, there's nothing you can do to PyThreadState_Delete() that can hurt core Python either. That's why people should be more encouraging here ;-) It certainly makes sense to me that if a thread state is going away, any record of it in the auto-GIL-state machinery must also go away. > Thank you very much. Thank you! If you put a patch on SourceForge, I'll probably be happy to check it in. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
On Fri, Jan 20, 2006 at 06:56:23AM +1000, Nick Coghlan wrote: > I'm not aware of anyone that would miss octal literals, Except anyone who uses os.chmod. I would be mighty sad if we removed octal and hexadecimal literals for 'cleanliness' reasons alone. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
[Nick Coghlan] > ... > I quite like the suggestion of using 'math.base' rather than a builtin, but > there are still issues to be figured out there: >- the math module is currently a thin wrapper around C's "math.h". Do we > really want to change that by adding more methods? That's not an issue. Some math functions go beyond C's (like 2-argument log(), and all flavors of log() returning sensible results for inputs larger than the largest C double), and some functions aren't part of C at all (like math.radians()). A stronger reason to keep it out of `math` is that all functions there operate on, and return, floats: it's a bizarre place to put an integer->string function. >- is 'base' the right name? >- should we allow a "digits" argument, or just the radix argument? Add to_base(self, radix=16) as a new numeric method. End of problem ;-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Include ctypes into core Python?
On Jan 19, 2006, at 4:24 PM, Thomas Heller wrote: > > Several of these files are licensed under GPL: > > aclocal.m4 config-ml.in config.guess config.sub depcomp ltcf-c.sh > ltconfig missing > Are you sure? The copies of aclocal.m4 and config-ml.in both disagree with you. aclocal seems to have a completely liberal license, and config-ml has a "whatever the license of the program it's building" license. James aclocal.m4:: # generated automatically by aclocal 1.7.3 -*- Autoconf -*- # Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002 # Free Software Foundation, Inc. # This file is free software; the Free Software Foundation # gives unlimited permission to copy and/or distribute it, # with or without modifications, as long as this notice is preserved. # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY, to the extent permitted by law; without # even the implied warranty of MERCHANTABILITY or FITNESS FOR A # PARTICULAR PURPOSE. # libtool.m4 - Configure libtool for the host system. -*-Autoconf-*- config-ml.in:: # Configure fragment invoked in the post-target section for subdirs # wanting multilib support. # # Copyright (C) 1995, 1997, 1998, 1999, 2000, 2001, 2002, 2003 # Free Software Foundation, Inc. # # This file is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place - Suite 330, # Boston, MA 02111-1307, USA. # # As a special exception to the GNU General Public License, if you # distribute this file as part of a program that contains a # configuration script generated by Autoconf, you may include it under # the same distribution terms that you use for the rest of that program. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Include ctypes into core Python?
Thomas Heller wrote: > Is it a problem to have these files in the Python source code? I would think so, yes. Including them in the Python distribution, without licensing the entire Python distribution under GPL, would be a GPL violation. The actual libffi appears to have a fairly liberal license (also it still requires to include the LICENSE file, atleast in the source distribution). Importing the original source in /external would be no problem (AFAICT), as long as you then delete them during/after the svn cp. > Maybe it would be possible to reimplement the functionality in the > setup.py script, but this is way beyond my expertise. Right. Given the large number of people that want to see this happen (not necessarily on python-dev, but on comp.lang.python), I'm sure there is somebody who can come up with a build process. If nobody volunteers to do the actual work, I have no problems with dropping the idea for now. I wouldn't have any problems with just including a Windows port, either. 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] Include ctypes into core Python?
"Martin v. Löwis" <[EMAIL PROTECTED]> writes: > Guido van Rossum wrote: >> On 1/16/06, Thomas Heller <[EMAIL PROTECTED]> wrote: >> >>>It looks like we need a pronouncement now. >> >> >> Sorry. It appeared to me that there was general agreement to using a >> strongly worded warning in the docs, so I tuned out of the rest of the >> discussion. So for the record, I'm fine with that. > ctypes includes libffi. libffi is build with GNU tools, which would have to be committed in the python svn repository. Several of these files are licensed under GPL: aclocal.m4 config-ml.in config.guess config.sub depcomp ltcf-c.sh ltconfig missing AFAICT, these files are only used to *build* libffi, and are not linked into or have to be distributed with the binaries. Is it a problem to have these files in the Python source code? Maybe it would be possible to reimplement the functionality in the setup.py script, but this is way beyond my expertise. Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
Nick Coghlan wrote:
> Guido van Rossum wrote:
>
>>On 1/19/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>>
>>>Guido van Rossum wrote:
>>>
>>>
I think we ought to let this sit for a while and come back to it in a
few week's time. Is 'base' really the right name? It could just as
well be considered a conversion in the other direction.
>>>
>>>the same applies to hex and oct, of course.
>>
>>Right. And this is not a hypothetical issue either -- in Perl, hex and
>>oct *do* work the other way I believe. More reasons to get rid of
>>these in Python 3000. Perhaps we should also get rid of hex/oct
>>lterals?
>
>
> I'm not aware of anyone that would miss octal literals, but there are plenty
> of hardware weenies like me that would find "int("DEAD", 16)" less convenient
> than "0xDEAD". Python is a bit too heavyweight for a lot of embedded work,
> but
> its *great* for writing host-based test harnesses.
>
> I quite like the suggestion of using 'math.base' rather than a builtin, but
> there are still issues to be figured out there:
>- the math module is currently a thin wrapper around C's "math.h". Do we
> really want to change that by adding more methods?
>- is 'base' the right name?
>- should we allow a "digits" argument, or just the radix argument?
>
Another possibility, since Python 3 can break backward compatibility: we
could take a page out of Icon's book and use an "rN" suffix for
non-decimal literals.
23 == 27r8 == 17r16
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
Guido van Rossum wrote:
> On 1/19/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>>
>>> I think we ought to let this sit for a while and come back to it in a
>>> few week's time. Is 'base' really the right name? It could just as
>>> well be considered a conversion in the other direction.
>> the same applies to hex and oct, of course.
>
> Right. And this is not a hypothetical issue either -- in Perl, hex and
> oct *do* work the other way I believe. More reasons to get rid of
> these in Python 3000. Perhaps we should also get rid of hex/oct
> lterals?
I'm not aware of anyone that would miss octal literals, but there are plenty
of hardware weenies like me that would find "int("DEAD", 16)" less convenient
than "0xDEAD". Python is a bit too heavyweight for a lot of embedded work, but
its *great* for writing host-based test harnesses.
I quite like the suggestion of using 'math.base' rather than a builtin, but
there are still issues to be figured out there:
- the math module is currently a thin wrapper around C's "math.h". Do we
really want to change that by adding more methods?
- is 'base' the right name?
- should we allow a "digits" argument, or just the radix argument?
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
On Jan 19, 2006, at 11:12 AM, Guido van Rossum wrote:
> On 1/19/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>>
>>> I think we ought to let this sit for a while and come back to it
>>> in a
>>> few week's time. Is 'base' really the right name? It could just as
>>> well be considered a conversion in the other direction.
>>
>> the same applies to hex and oct, of course.
>
> Right. And this is not a hypothetical issue either -- in Perl, hex and
> oct *do* work the other way I believe. More reasons to get rid of
> these in Python 3000. Perhaps we should also get rid of hex/oct
> lterals?
In Perl, hex(n) is like int(n, 16) and oct(n) is like int(n, 8) --
but they "try very hard" to make sense out of the given scalar (e.g.
more like int(n, 0) with a suggestion for base).
$ perl -e 'print hex("12") . " " . oct("12") . " " . oct("0x12") . "
" . hex("fubar")'
18 10 18 15
If you notice, oct("0x12") gives the hexadecimal result, and the
functions will try and make a value even out of garbage data.
In Ruby, you have the optional radix argument to_s and to_i, where
to_i will just return 0 for invalid values. They will take any radix
from 2..36.
$ irb
irb(main):001:0> 12.to_s
=> "12"
irb(main):002:0> 12.to_s(16)
=> "c"
irb(main):003:0> 12.to_s(8)
=> "14"
irb(main):004:0> "12".to_i(8)
=> 10
irb(main):005:0> "12".to_i(16)
=> 18
irb(main):006:0> "0x12".to_i(16)
=> 18
irb(main):007:0> "0x12".to_i(8)
=> 0
irb(main):008:0> "0x12".to_i
=> 0
irb(main):009:0> "fubar".to_i
=> 0
irb(main):010:0> "fubar".to_i(36)
=> 26608563
-bob
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
On 1/19/06, Aahz <[EMAIL PROTECTED]> wrote: > On Thu, Jan 19, 2006, Jeremy Hylton wrote: > > > > I'm not sure I believe this should be a builtin. I think the > > threshold for new builtins ought to be nearly as high as the threshold > > for new keywords. Or the proposer ought to make an argument about > > what the function should not go in a module. > > The way I'd put it, any function that wants to go in builtins should > require a formal PEP. I'm suggesting a criterion for evaluating the choice of builtin vs. module, not making a suggestion about the process. Jeremy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
Raymond Hettinger wrote:
> That suggests that it would be better to simply add an int method:
> x.convert_to_base(7)
I'd suggest allowing:
x.convert_to_base('0123456')
Where the (str or unicode) argument is the list of digits in order.
This would allow easy converting to base-64 and other weird formats, as
well as providing decimal conversion into some unicode number ranges
outside the ASCII group.
--Scott David Daniels
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New PEP: Using ssize_t as the index type
Neal Norwitz wrote: > Other ideas? We could rename essential function symbols, like PyInitModule4 (to, say, PyInitModule4b). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
On Thu, Jan 19, 2006, Jeremy Hylton wrote: > > I'm not sure I believe this should be a builtin. I think the > threshold for new builtins ought to be nearly as high as the threshold > for new keywords. Or the proposer ought to make an argument about > what the function should not go in a module. The way I'd put it, any function that wants to go in builtins should require a formal PEP. And in case it isn't clear, I'm +1 on deprecating oct()/hex() (or moving them into another module as convenience functions for base() -- just to make conversion easier). -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "19. A language that doesn't affect the way you think about programming, is not worth knowing." --Alan Perlis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
On 1/19/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > > I think we ought to let this sit for a while and come back to it in a > > few week's time. Is 'base' really the right name? It could just as > > well be considered a conversion in the other direction. > > the same applies to hex and oct, of course. Right. And this is not a hypothetical issue either -- in Perl, hex and oct *do* work the other way I believe. More reasons to get rid of these in Python 3000. Perhaps we should also get rid of hex/oct lterals? > as for base itself, I'm more concerned about the google product place- > ment here. what's next? a froogle builtin? The default __import__ will use Google Code to locate an appropriate module to import instead of restricting itself to the boring and predictable sys.path. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
Guido van Rossum wrote: > I think we ought to let this sit for a while and come back to it in a > few week's time. Is 'base' really the right name? It could just as > well be considered a conversion in the other direction. the same applies to hex and oct, of course. as for base itself, I'm more concerned about the google product place- ment here. what's next? a froogle builtin? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Additions to the functional module
Hello, I just submitted patch #1410119, adding foldl and foldr functions to Modules/functionalmodule.c (plus docs and tests in the appropriate places). If there's interest from the higher-ups, I'm interested in adding numerous other functional programming tools to this module. In addition to C implementations, I would also provide documentation and further additions to test/test_functional.py to cover the new functions. Also, I've started a project to offer a pure-python implementation of the C-language functional module, which I plan to keep in sync with the module in the standard library. If there's any interest in including something like this in Demo/, I'd be keen to contribute it as well. Thanks, Collin Winter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
On Jan 19, 2006, at 10:31, Guido van Rossum wrote:
To keep it simple, the proposal is for the value to be any int or
long.
With an underlying __base__ method call, it wouldn't be hard for
someone
to build it out to support other numeric types if the need arises.
Let's not. What would 3.14 be expressed in base 3?
10.010210001
It turned out to be a fun aside, and I've attached my quick and dirty
script as a strawman.
For what it's worth, I don't like the name base() because it sounds
like something I would call on a class to get it's bases. Perhaps
nbase? And maybe fbase for the floating point one...
Thanks,
-Shane Holloway
#!/usr/bin/env python
#
#~ Imports
#
import math
#
#~ Definitions
#
def ibase(n, radix=2, maxlen=None):
r = []
while n:
n,p = divmod(n, radix)
r.append('%d' % p)
if maxlen and len(r) > maxlen:
break
r.reverse()
return ''.join(r)
def fbase(n, radix=2, maxlen=8):
r = []
f = math.modf(n)[0]
while f:
f, p = math.modf(f*radix)
r.append('%.0f' % p)
if maxlen and len(r) > maxlen:
break
return ''.join(r)
def base(n, radix, maxfloat=8):
if isinstance(n, float):
return ibase(n, radix)+'.'+fbase(n, radix, maxfloat)
elif isinstance(n, (str, unicode)):
n,f = n.split('.')
n = int(n, radix)
f = int(f, radix)/float(radix**len(f))
return n + f
else:
return ibase(n, radix)
#
#~ Main
#
if __name__=='__main__':
pi = 3.14
print 'pi:', pi, 'base 10'
piBase3 = base(pi, 3)
print 'pi:', piBase3, 'base 3'
piFromBase3 = base(piBase3, 3)
print 'pi:', piFromBase3, 'base 10 from base 3'
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
I'm not sure I believe this should be a builtin. I think the threshold for new builtins ought to be nearly as high as the threshold for new keywords. Or the proposer ought to make an argument about what the function should not go in a module. Jeremy On 1/19/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 1/18/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > Guido, we may be converging on a consensus for my proposal: > > > > base(value, radix=2) > > > > So far no one has shot at it, and it has gathered +1's from Steven, > > Alex, Brett, and Nick. > > I think we ought to let this sit for a while and come back to it in a > few week's time. Is 'base' really the right name? It could just as > well be considered a conversion in the other direction. In common > usage, 'base' and 'radix' are about synonymous (except no-one uses > radix). Pethaps the 2nd argument should not be a keyword argument? > > Also, this discussion made me wonder if conversions using other bases > than 10 should even be built-ins. A library module seems a more > appropriate place. The prevalence here of people who actually use hex > numbers on a regular basis is probably easily explained by a > combination of old-timers, language implementers, and super-geeks; > hardly the typical Python user. The desire of (bright) beginners to do > any kind of non-decimal conversion probably stems from a misguided > meme (dating back to the invention of computers) that in order to > learn about computers you ought to begin by learning about Boolean > algebra and binary numbers. That might be true long ago, but today, > binary, octal and hexadecimal numbers are mostly a curiosity used in > obscure low-level APIs like ioctl(). > > > To keep it simple, the proposal is for the value to be any int or long. > > With an underlying __base__ method call, it wouldn't be hard for someone > > to build it out to support other numeric types if the need arises. > > Let's not. What would 3.14 be expressed in base 3? > > > The output would have no prefixes. As Alex pointed out, it is easier > > and more direct to add those after the fact if needed. > > Agreed. > > > Care to pronounce on it? > > Rather not yet. > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/jeremy%40alum.mit.edu > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
On 1/18/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > Guido, we may be converging on a consensus for my proposal: > > base(value, radix=2) > > So far no one has shot at it, and it has gathered +1's from Steven, > Alex, Brett, and Nick. I think we ought to let this sit for a while and come back to it in a few week's time. Is 'base' really the right name? It could just as well be considered a conversion in the other direction. In common usage, 'base' and 'radix' are about synonymous (except no-one uses radix). Pethaps the 2nd argument should not be a keyword argument? Also, this discussion made me wonder if conversions using other bases than 10 should even be built-ins. A library module seems a more appropriate place. The prevalence here of people who actually use hex numbers on a regular basis is probably easily explained by a combination of old-timers, language implementers, and super-geeks; hardly the typical Python user. The desire of (bright) beginners to do any kind of non-decimal conversion probably stems from a misguided meme (dating back to the invention of computers) that in order to learn about computers you ought to begin by learning about Boolean algebra and binary numbers. That might be true long ago, but today, binary, octal and hexadecimal numbers are mostly a curiosity used in obscure low-level APIs like ioctl(). > To keep it simple, the proposal is for the value to be any int or long. > With an underlying __base__ method call, it wouldn't be hard for someone > to build it out to support other numeric types if the need arises. Let's not. What would 3.14 be expressed in base 3? > The output would have no prefixes. As Alex pointed out, it is easier > and more direct to add those after the fact if needed. Agreed. > Care to pronounce on it? Rather not yet. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
On Thursday 2006-01-19 11:15, Thomas Wouters wrote:
> On Thu, Jan 19, 2006 at 10:23:30AM +, Gareth McCaughan wrote:
...
> > Introducing a new builtin with a name that's a common, short
> > English word is a bit disagreeable.
>
> While I don't particularly mind the new function in either the builtin
> module or another, like math, I don't understand the problem with the name.
> Most builtin names are short and english-ish words. I like that, I'm glad
> they are that way, and the two names I dislike most are 'isinstance' and
> 'issubclass'.
"issubclass" is horrible because wordsjammedtogetherlikethisarehardtoread,
especially when they're misleading as to pronunciation ("iss-ubclass").
Short English words are nice because they're easy to type and
(at least sometimes) their meanings are immediately obvious.
For the same reason, they're useful as variable names. Of course
the world doesn't end if a builtin name is the same as a variable
name you'd like to use, but it's ... well, "a bit disagreeable"
probably expresses about the right degree of nuisance.
> > The other thing about the name "base" is that it's not entirely obvious
> > which way it converts: do you say
> >
> > base(123,5)
> >
> > to get a string representing 123 in base 5, or
> >
> > base("123",5)
> >
> > to get the integer whose base 5 representation is "123"?
>
> This is an argument for 'str(123, 5)', but I don't agree.
It's not (intended as) an argument *for* any particular form.
> Not _everything_
> has to be obvious at first glance. The very same could be said about hex(),
> oct(), dir(), even names like list() (what does it list?), str() (stripping
> something?), etc.
Actually, I happen to dislike hex() slightly -- I never use or see
oct(), so don't much care about that -- for exactly that reason.
> Having int() do it one way and base() the other makes fine
> sense to me, and I don't see it as any harder to explain than, say, why
> hex("123") doesn't return 291. I've personally never had to explain
> hex/oct's behaviour.
To me, base() is less obvious than hex(), which itself is just
ambiguous enough to cost me maybe one second per month. Not a big
deal at all, but not zero.
> While I think 'str' would be a slightly better name than 'base' (despite the
> specialcasing of numbers,) I don't mind either. I do mind names like
> 'to_base' or 'as_str' or 'shouldbestr' or other names that make me turn on
> autocompletion in my editor.
You need to turn off the Python Mind Control feature. :-)
I think math.base (apart from sounding like it ought to be a
variable that controls the base in which numbers are represented,
or something of the sort) is about as much typing as to_base,
so I'm not sure how the latter can be much worse in this respect.
> > Alternatively, a name like "to_base" that clarifies the intent and is less
> > likely to clash with variable names might be an improvement.
>
> Builtins aren't reserved names, so the clash is minimal.
Sure, it's not disabling. But in practice it's nice to be able
to avoid builtin names, and "base" is a word I'd rather not have
to take measures to avoid: too many meanings, some of them
quite common.
(I don't care much about this, and if base() gets introduced
I shan't complain.)
--
g
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
On Thu, Jan 19, 2006 at 10:23:30AM +, Gareth McCaughan wrote:
> > +1 on introducing base()
> Introducing a new builtin with a name that's a common, short
> English word is a bit disagreeable.
While I don't particularly mind the new function in either the builtin
module or another, like math, I don't understand the problem with the name.
Most builtin names are short and english-ish words. I like that, I'm glad
they are that way, and the two names I dislike most are 'isinstance' and
'issubclass'.
> The other thing about the name "base" is that it's not entirely obvious
> which way it converts: do you say
>
> base(123,5)
>
> to get a string representing 123 in base 5, or
>
> base("123",5)
>
> to get the integer whose base 5 representation is "123"?
This is an argument for 'str(123, 5)', but I don't agree. Not _everything_
has to be obvious at first glance. The very same could be said about hex(),
oct(), dir(), even names like list() (what does it list?), str() (stripping
something?), etc. Having int() do it one way and base() the other makes fine
sense to me, and I don't see it as any harder to explain than, say, why
hex("123") doesn't return 291. I've personally never had to explain
hex/oct's behaviour.
While I think 'str' would be a slightly better name than 'base' (despite the
specialcasing of numbers,) I don't mind either. I do mind names like
'to_base' or 'as_str' or 'shouldbestr' or other names that make me turn on
autocompletion in my editor.
> Alternatively, a name like "to_base" that clarifies the intent and is less
> likely to clash with variable names might be an improvement.
Builtins aren't reserved names, so the clash is minimal.
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
On Wednesday 2006-01-18 16:55, Steven Bethard wrote:
> [Raymond]
> > Perhaps introduce a single function, base(val, radix=10,
> > prefix=''), as a universal base converter that could replace
> > bin(), hex(), oct(), etc.
>
> +1 on introducing base()
Introducing a new builtin with a name that's a common, short
English word is a bit disagreeable. The other thing about the
name "base" is that it's not entirely obvious which way it
converts: do you say
base(123,5)
to get a string representing 123 in base 5, or
base("123",5)
to get the integer whose base 5 representation is "123"?
Well, one option would be to have both of those work :-).
(Some people may need to do some deep breathing while
reciting the mantra "practicality beats purity" in order
to contemplate that with equanimity.)
Alternatively, a name like "to_base" that clarifies the
intent and is less likely to clash with variable names
might be an improvement.
Or there's always %b, whether that ends up standing for
"binary" or "base". Or %b for binary and %r for radix,
not forgetting the modifiers to get numbers formatted
as Roman numerals.
--
Gareth McCaughan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python icon
Anthony Baxter wrote: > On Thursday 19 January 2006 08:53, [EMAIL PROTECTED] wrote: > >>Maybe I misread the directions. I thought I had to install some >>new library I'd never heard of (syck), Python bindings for the >>same, and maybe some other stuff. It clearly wasn't just "svn co >>..." and start editing. In any case, I couldn't tell what needed >>doing from the trac site. > > > We obviously need to get everything that's needed to use setuptools > and eggs so people can just have things "just work". Yay for PJE! > > :-D thats the plan!! only problem is getting zope interface to build as an egg :-( any ideas? Tim ___ Python-Dev mailing list Python-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] New PEP: Using ssize_t as the index type
Neal Norwitz wrote: > On 1/10/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: >> We'd also have to make sure that old extensions don't >> just import with a warning, since the change will introduce >> buffer overflows and seg faults in extensions that are not >> aware of the change. > > I agree that on 64-bit platforms we should prevent the import. In the > past we only provided a warning and the users were on their own. This > is different. > > If you read my massive checkin to check the return results of > Py_InitModule*(), you'll realize this isn't as simple as just failing > in Py_InitMethod*(). I was hoping to just modify Py_InitModule4() in > Python/modsupport.c to fail and return NULL. That doesn't seem > practical given that we didn't check return results. We will just > crash the interpreter with standard python 2.4 modules. > > ISTM we need to modify _PyImport_LoadDynamicModule() in > Python/importdl.c before calling the init function (line 56, (*p)()) > to check for some magic symbol that is defined only when compiling 2.5 > and above. For example we could add a static int _64_bit_clean = 1; > in modsupport.h. Without some trickery we will get this defined in > every .o file though, not just modules. > > Other ideas? We could explicitly break binary compatibility for Python 2.5 on 64-bit platforms, by changing the name of an often used API, e.g. the Py_InitModule*() APIs. This is how Unicode does it - we map the various APIs to either ...UCS2 or ...UCS4, so that you cannot import an extension compiled for e.g. UCS2 into a Python interpreter compiled for UCS4. If we didn't, you'd get seg faults and buffer overflows the same way you would with the ssize_t change on 64-bit platforms. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 19 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
