Re: [Python-Dev] str with base
Adam Olsen wrote:
> On 1/17/06, Bob Ippolito <[EMAIL PROTECTED]> wrote:
>
>>On Jan 17, 2006, at 4:09 PM, Adam Olsen wrote:
>>
>>
>>>On 1/17/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>>>
On 1/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
>>In-favour-of-%2b-ly y'rs,
>
>My only opposition to this is that the byte type may want to use it.
>I'd rather wait until byte is fully defined, implemented, and
>released
>in a python version before that option is taken away.
Has this been proposed? What would %b print?
>>>
>>>I don't believe it's been proposed and I don't know what it'd print.
>>>Perhaps it indicates the bytes should be passed through without
>>>conversion.
>>
>>That doesn't make any sense. What is "without conversion"? Does
>>that mean UTF-8, UCS-2, UCS-4, latin-1, Shift-JIS? You can't have
>>unicode without some kind of conversion.
>>
>>
>>>In any case I only advocate waiting until it's clear that bytes have
>>>no need for it before we use it for binary conversions.
>>
>>I don't see what business a byte type has mingling with string
>>formatters other than the normal str and repr coercions via %s and %r
>>respectively.
>
>
> Is the byte type intended to be involved in string formatters at all?
> Does byte("%i") % 3 have the obvious effect, or is it an error?
>
> Although upon further consideration I don't see any case where %s and
> %b would have different effects.. *shrug* I never said it did have a
> purpose, just that it *might* be given a purpose when byte was spec'd
> out.
>
I suppose we'd better reserve "%q" for 'quirky types we just invented',
too? ;-)
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
Adam Olsen wrote: > On 1/17/06, Bob Ippolito <[EMAIL PROTECTED]> wrote: > >>On Jan 17, 2006, at 3:38 PM, Adam Olsen wrote: >> >> >>>I dream of a day when str(3.25, base=2) == '11.01'. That is the >>>number a float really represents. It would be so much easier to >>>understand why floats behave the way they do if it were possible to >>>print them in binary. >> >>Actually if you wanted something that closely represents what a >>floating point number is then you would want to see this:: >> >>>>> str(3.25, base=2) >>'1.101e1' >>>>> str(0.25, base=2) >>'1.0e-10' >> >>Printing the bits without an exponent is nearly as misleading as >>printing them in decimal. > > > I disagree. The exponent is involved in rounding to fit in compact > storage but once that is complete the value can be represented exactly > without it. > Albeit with excessively long representations for the larger values one sometimes sees represented in float form. Personally I wouldn't even be interested in seeing 1.3407807929942597e+154 written in fixed point form *in decimal*, let alone in binary where the representation, though unambiguous, would have over 500 bits, most of them zeros. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Building on OS X 10.4 fails
On Wed, Jan 18, 2006 at 02:25:03PM +0900, Stephen J. Turnbull wrote: > Anthony> It sounds like configure needs to grow a test to detect > Anthony> that a "libreadline" it finds is actually the crackful > Anthony> "libedit" and refuse to use it if so. > FYI: Real libreadline is GPL, and rms made a point of forcing > (Aladdin-licensed) Ghostscript to remove stanzas from the Makefile > that allowed linking to it as a user option. Ie, this particular pain > in the neck is deliberate FSF policy, to encourage use of the GPL. [...] > As long as the link to fake libreadline succeeds and the resulting > program works identically to one linked to real libreadline, he has no > complaint. I don't think this applies to Python. The Aladdin license isn't GPL-compatible, but the current PSF license is (according to rms himself.) (Only, IIRC, 1.5.2-and-earlier, 2.0.1 and 2.1.1-and-later, not 1.6, 1.6.1[*], 2.0 or 2.1.) The Ghostscript check-for-readline is a case of "you are still linking with readline, even when you aren't actually linking" -- but this isn't a problem for (most versions of) Python, because rms said it isnt. As long as the resulting Python binary is only covered by the GPL-compatible PSF license, the GPL and no GPL-incompatible licenses, any form of linking is fine, even configure-time-not-building linking. [*] 1.6.1 is the release that contained the license change rms and his laywers wanted, but that itself doesn't make the license GPL-compatible. It apparently allows derived works from being GPL-compatible, though. 2.0 and 2.1 derive from 1.6, but 2.0.1 and 2.1.1 derive from 1.6.1. I'm sure it makes sense to someone. Go-figure'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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] subwcrev.exe
I just added svnversion support to the VC project files; subwcrev.exe is expected to be found in the Tortoise installation, if it cannot find tortoise in the registry, it falls back to not doing svnversion. If you find problems, please let me know. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
Steve Holden wrote: [...] > Personally I wouldn't even be interested in seeing > 1.3407807929942597e+154 written in fixed point form *in decimal*, let > alone in binary where the representation, though unambiguous, would have > over 500 bits, most of them zeros. > Well, shot myself in the foot there of course, since the number I meant was actually 2.0 ** 512 (or 13407807929942597099574024998205846127479365820592393377723561443721764030073546 976801874298166903427690031858186486050853753882811946569946433649006084096.0) rather than the decimal approximation above. But I'm sure you get the point that fixed-point representations aren't always appropriate. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Building on OS X 10.4 fails
On Wednesday 18 January 2006 16:25, Stephen J. Turnbull wrote: > Unless rms has changed his position on this, or there has been > relevant legislation or a court decision in the meantime, > explicitly requiring or checking for "real" libreadline, even as a > user option, risks rms's wrath. (Of course, Python could change > its license to GPL, which would undoubtedly flood Cambridge with > tears of joy). Python's license is GPL-compatible, so this isn't an issue. > As long as the link to fake libreadline succeeds and the resulting > program works identically to one linked to real libreadline, he has > no complaint. My "complaint" is that libedit _calls_ itself libreadline, when it's pretty clear that it's not actually a drop-in replacement (or the readline module would build). Hence my use of the word "crackful" Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] basenumber redux
Alex Martelli wrote: > On 1/17/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: >> Alex, I think you're missing a point here: what you are looking >> for is an interface, not a base class - simply because the > > I expect numbers to support arithmetic operators, &c -- no need for > basenumber to "spell this out", i.e., "be an itnerface". If at all, basenumber would be an abstract class. However, unlike for basestring, the interface (which methods it supports, including operator methods) would not be well- defined. >> If you look at the Python C API, you'll find that "a number" >> is actually never tested. > > There being no way to generically test for "a number", that's unsurprising. Hmm, I lost you there. If it's unsurprising that there's no check for "a number", then why would you want a basenumber ? >> The tests always ask for either >> integers or floats. > > But this doesn't apply to the Python Standard Library, for example see > line 1348 of imaplib.py: "if isinstance(date_time, (int, float)):". Why not use the functions I added to my previous mail ? >> The addition of a basenumber base class won't make these any >> simpler. > > Being able to change imaplib to use basenumber instead of (int, float) > won't make it SIMPLER, but it will surely make it BETTER -- why should > a long be rejected, or a Decimal, > for that matter? Similarly, on line 1352 it should use the existing > basestring, though it now uses str (this function IS weird -- if it > finds date_time to be of an unknown TYPE it raises a *ValueError* > rather than a *TypeError* -- ah well). Again, why not use floatnumber() instead, which takes care of all the details behind finding out whether an object should be considered a number and even converts it to a float for you ? Why try to introduce a low-level feature when a higher level solution is readily available and more usable. You will rarely really care for the type of an object if all you're interested in is the float value of an object (or the integer value). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 18 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
On Tue, 2006-01-17 at 16:38 -0700, Adam Olsen wrote: > On 1/17/06, Thomas Wouters <[EMAIL PROTECTED]> wrote: > > On Tue, Jan 17, 2006 at 09:23:29AM -0500, Jason Orendorff wrote: [...] > I dream of a day when str(3.25, base=2) == '11.01'. That is the > number a float really represents. It would be so much easier to > understand why floats behave the way they do if it were possible to > print them in binary. [...] Heh... that's pretty much why I used base16 float notation when doing fixed point stuff in assembler... uses less digits than binary, but easily visualised as bits. However, I do think that we could go overboard here... I don't know that we really need arbitrary base string formatting for all numeric types. I think this is a case of "very little gained for too much added complexity". If we really do, and someone is prepared to implement it, then I think adding "@base" is the best way to do it (see my half joking post earlier). If we only want arbitrary bases for integer types, the best way would be to leverage off the existing ".precision" so that it means ".base" for "%d". > > In-favour-of-%2b-ly y'rs, > > My only opposition to this is that the byte type may want to use it. > I'd rather wait until byte is fully defined, implemented, and released > in a python version before that option is taken away. There's always "B" for bytes and "b" for bits... though I can't imagine why byte would need it's own conversion type. I'm not entirely sure everyone is on the same page for "%b" here... it would only be a shorthand for "binary" in the same way that "%x" is for "hexidecimal". It would not support arbitrary bases, and thus "%2b" would mean a binary string with minimum length of 2 characters. -- Donovan Baarda <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
On Tue, 2006-01-17 at 20:25 -0800, Guido van Rossum wrote: > On 1/17/06, Bob Ippolito <[EMAIL PROTECTED]> wrote: > > There shouldn't be a %B for the same reason there isn't an %O or %D > > -- they're all just digits, so there's not a need for an uppercase [...] so %b is "binary", +1 > > The difference between hex() and oct() and the proposed binary() is > > I'd propose bin() to stay in line with the short abbreviated names. [...] +1 > The binary type should have a 0b prefix. [...] +1 For those who argue "who would ever use it?", I would :-) Note that this does not support and is independent of supporting arbitrary bases. I don't think we need to support arbitrary bases, but if we did I would vote for ".precision" to mean ".base" for "%d"... ie; "%3.3d" % 5 == " 12" I think supporting arbitrary bases for floats is way overkill and not worth considering. -- Donovan Baarda <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Building on OS X 10.4 fails
> "Anthony" == Anthony Baxter <[EMAIL PROTECTED]> writes: Anthony> Python's license is GPL-compatible, so this isn't an Anthony> issue. I'm sorry, but you seem to misunderstand what "GPL compatibility" means. It is a _one-way_ street. A license is GPL-compatible if its terms permit the code it covers to be redistributed under GPL. The GPL, however, is "compatible" in this sense only with itself: _the whole of any work_ derived from a GPL work must be licensed under the GPL. Not under a GPL-compatible license, under the GPL. The import of the Ghostscript case is that the FSF considers a Makefile stanza clearly intended to cause linkage to a GPL library, even if optional and supplied by the user, to create a work derived from that library. A "GNU readline"-enabled Python is derived from GNU readline, and must be distributed under the GPL or not distributed at all. I assume that the former is not acceptable to Python, and the latter is clearly undesirable. I assure you, Peter Deutsch was just as unbelieving as you are, but facing a potentially expensive lawsuit, he caved in. I can think of many reasons why the FSF might not come after Python, but the risk is real. Please ask a lawyer. -- 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python icon
[EMAIL PROTECTED] wrote: > Georg> Interesting, didn't even know a new page was in the making... Do > Georg> you know who is responsible for the new page? > > Tim Parkin is heading things up. Look here: > > http://beta.python.org/ I like the look of the new page, but it took a bit of digging to find anything about *how* it has been developed, or what needs to be done before the main URL can be switched to the new page (e.g. integrating the documentation properly). While it's in beta having that info prominent on the home page might be a good idea. Something like: "This is a beta of the redesigned www.python.org. If you have specific suggestions or display problems, submit them to the tracker . General questions or comments should be posted to comp.lang.python" I thought for a moment that this week's python-url was going to help me out, but it only linked the beta site without actually linking to any of the discussion it referenced in the relevant blurb. . . Appropriate enlightenment was eventually attained through Google: http://mail.python.org/pipermail/python-list/2006-January/319862.html Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] 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-checkins] r42090 - in python/trunk: Modules/getbuildinfo.c PCbuild/make_buildinfo.vcproj PCbuild/pcbuild.sln PCbuild/pythoncore.vcproj
[martin.v.loewis <[EMAIL PROTECTED]>] > Date: Wed Jan 18 10:13:51 2006 > New Revision: 42090 > > Added: >python/trunk/PCbuild/make_buildinfo.vcproj > Modified: >python/trunk/Modules/getbuildinfo.c >python/trunk/PCbuild/pcbuild.sln >python/trunk/PCbuild/pythoncore.vcproj > Log: > Generate getbuildinfo.o each time the linker is invoked; > try to generate SVNVERSION information if subwcrev.exe > can be found. Umm ... looks like I don't know how to build Python anymore. A batch build crapped out with: """ -- Build started: Project: pythoncore, Configuration: Debug Win32 -- generate buildinfo 'make_buildinfo.exe' is not recognized as an internal or external command, operable program or batch file. """ Adding the `make_buildinfo` project to the batch-build set craps out earlier: the `make_buildinfo` project lists make_buildinfo.c as an input file, but there is no such file: """ -- Build started: Project: make_buildinfo, Configuration: Debug Win32 -- Compiling... make_buildinfo.c c1 : fatal error C1083: Cannot open source file: '.\make_buildinfo.c': No such file or directory """ Did this checkin perhaps forget to add that file? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
On Tue, Jan 17, 2006, Guido van Rossum wrote: > On 1/17/06, Bob Ippolito <[EMAIL PROTECTED]> wrote: >> >> The difference between hex() and oct() and the proposed binary() is > > I'd propose bin() to stay in line with the short abbreviated names. There has been some previous discussion about removing hex()/oct() from builtins for Python 3.0, IIRC. I sure don't think bin() belongs there. > The binary type should have a 0b prefix. -0 on adding a new prefix; +1 on this syntax if we do. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "19. A language that doesn't affect the way you think about programming, is not worth knowing." --Alan Perlis ___ Python-Dev mailing list [email protected] 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
Nick Coghlan wrote: > [EMAIL PROTECTED] wrote: > >>Georg> Interesting, didn't even know a new page was in the making... Do >>Georg> you know who is responsible for the new page? >> >>Tim Parkin is heading things up. Look here: >> >>http://beta.python.org/ > > > I like the look of the new page, but it took a bit of digging to find > anything > about *how* it has been developed, or what needs to be done before the main > URL can be switched to the new page (e.g. integrating the documentation > properly). While it's in beta having that info prominent on the home page > might be a good idea. Something like: > > "This is a beta of the redesigned www.python.org. If you have specific > suggestions or display problems, submit them to the tracker . General > questions or comments should be posted to comp.lang.python" > > I thought for a moment that this week's python-url was going to help me out, > but it only linked the beta site without actually linking to any of the > discussion it referenced in the relevant blurb. . . > > Appropriate enlightenment was eventually attained through Google: > http://mail.python.org/pipermail/python-list/2006-January/319862.html > That's probably not a bad idea. We should also add script explaining how to download the beta site data and the generation software so people can play with it and get ready to be webmasters :-) 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 [email protected] 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
Steve Holden wrote: >Nick Coghlan wrote: > > >>[EMAIL PROTECTED] wrote: >> >> >> >>> Georg> Interesting, didn't even know a new page was in the making... Do >>> Georg> you know who is responsible for the new page? >>> >>>Tim Parkin is heading things up. Look here: >>> >>> http://beta.python.org/ >>> >>> >>I like the look of the new page, but it took a bit of digging to find >>anything >>about *how* it has been developed, or what needs to be done before the main >>URL can be switched to the new page (e.g. integrating the documentation >>properly). While it's in beta having that info prominent on the home page >>might be a good idea. Something like: >> >> "This is a beta of the redesigned www.python.org. If you have specific >>suggestions or display problems, submit them to the tracker . General >>questions or comments should be posted to comp.lang.python" >> >>I thought for a moment that this week's python-url was going to help me out, >>but it only linked the beta site without actually linking to any of the >>discussion it referenced in the relevant blurb. . . >> >>Appropriate enlightenment was eventually attained through Google: >>http://mail.python.org/pipermail/python-list/2006-January/319862.html >> >> >> >That's probably not a bad idea. We should also add script explaining how >to download the beta site data and the generation software so people can >play with it and get ready to be webmasters :-) > > > I'll try to change the home page content to have a comment about how the site is in beta and what to do to get the content and build software. I've also got to add a fix in on the current css.. If anybody needs the graphics, they can still be found on psf.pollenation.net in the resources folder (browser source > trunk > ...). Tim ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
> > I'd propose bin() to stay in line with the short abbreviated names. > > There has been some previous discussion about removing hex()/oct() from > builtins for Python 3.0, IIRC. I sure don't think bin() belongs there. Perhaps introduce a single function, base(val, radix=10, prefix=''), as a universal base converter that could replace bin(), hex(), oct(), etc. That would give us fewer builtins and provide an inverse for all the int() conversions (i.e. arbitrary bases). Also, it would allow an unprefixed output which is what I usually need. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
Raymond> Perhaps introduce a single function, base(val, radix=10, Raymond> prefix=''), as a universal base converter that could replace Raymond> bin(), hex(), oct(), etc. Would it (should it) work with floats, decimals, complexes? I presume it would work with ints and longs. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
On 1/18/06, Donovan Baarda <[EMAIL PROTECTED]> wrote: > I think supporting arbitrary bases for floats is way overkill and not > worth considering. If you mean actual base-3 floating-point arithmetic, I agree. That's outlandish. But if there were a stdlib function to format floats losslessly in hex or binary, Tim Peters would use it at least once every six weeks to illustrate the finer points of floating point arithmetic. <0.00390625 wink> +1.0 -j ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
[Raymond] > Perhaps introduce a single function, base(val, radix=10, > prefix=''), as a universal base converter that could replace > bin(), hex(), oct(), etc. +1 on introducing base() [Skip] > Would it (should it) work with floats, decimals, complexes? I presume it > would work with ints and longs. While support for floats, decimals, etc. might be nice (and I certainly wouldn't complain if someone wanted to supply the patch) I don't think those features should be necessary for base()'s initial introduction. If they're there, great, but if not, I don't think that should hold up the patch... STeVe -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Building on OS X 10.4 fails
On 1/17/06, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote: > > "Anthony" == Anthony Baxter <[EMAIL PROTECTED]> writes: > > Anthony> It sounds like configure needs to grow a test to detect > Anthony> that a "libreadline" it finds is actually the crackful > Anthony> "libedit" and refuse to use it if so. > > FYI: Real libreadline is GPL, and rms made a point of forcing > (Aladdin-licensed) Ghostscript to remove stanzas from the Makefile > that allowed linking to it as a user option. Ie, this particular pain > in the neck is deliberate FSF policy, to encourage use of the GPL. Can we just all agree that RMS is an asshole now? Bah. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
Jason Orendorff wrote: > On 1/18/06, Donovan Baarda <[EMAIL PROTECTED]> wrote: > >>I think supporting arbitrary bases for floats is way overkill and not >>worth considering. > > > If you mean actual base-3 floating-point arithmetic, I agree. That's > outlandish. > > But if there were a stdlib function to format floats losslessly in hex > or binary, Tim Peters would use it at least once every six weeks to > illustrate the finer points of floating point arithmetic. <0.00390625 > wink> > > +1.0 > Nah, Tim's got the chops to use the struct model to get his point across. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ ___ Python-Dev mailing list [email protected] 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
Steve> We should also add script explaining how to download the beta Steve> site data and the generation software so people can play with it Steve> and get ready to be webmasters :-) My first attempt ended almost immediately. Too much software to download and install for anything like casual use. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Building on OS X 10.4 fails
Anthony> It sounds like configure needs to grow a test to detect that a Anthony> "libreadline" it finds is actually the crackful "libedit" and Anthony> refuse to use it if so. >> FYI: Real libreadline is GPL, ... Didn't Python's readline module work with libedit once upon a time? I believe that's the readline semi-clone that Rich Salz quite awhile ago. I've forgotten the details of the difference (missing history capabilities perhaps). Is there some way we can make libedit palatable again? Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
On 1/18/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > > I'd propose bin() to stay in line with the short abbreviated names. > > > > There has been some previous discussion about removing hex()/oct() > from > > builtins for Python 3.0, IIRC. I sure don't think bin() belongs > there. > > Perhaps introduce a single function, base(val, radix=10, prefix=''), as > a universal base converter that could replace bin(), hex(), oct(), etc. > > That would give us fewer builtins and provide an inverse for all the > int() conversions (i.e. arbitrary bases). Also, it would allow an > unprefixed output which is what I usually need. > +1. Differs from Neal's format() function by not magically determining the prefix from the radix which I like. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Building on OS X 10.4 fails
On Jan 18, 2006, at 1:31 AM, Anthony Baxter wrote: > On Wednesday 18 January 2006 16:25, Stephen J. Turnbull wrote: >> Unless rms has changed his position on this, or there has been >> relevant legislation or a court decision in the meantime, >> explicitly requiring or checking for "real" libreadline, even as a >> user option, risks rms's wrath. (Of course, Python could change >> its license to GPL, which would undoubtedly flood Cambridge with >> tears of joy). > > Python's license is GPL-compatible, so this isn't an issue. > >> As long as the link to fake libreadline succeeds and the resulting >> program works identically to one linked to real libreadline, he has >> no complaint. > > My "complaint" is that libedit _calls_ itself libreadline, when it's > pretty clear that it's not actually a drop-in replacement (or the > readline module would build). Hence my use of the word "crackful" > That's just something stupid Apple did. Not libedit's fault. -bob ___ Python-Dev mailing list [email protected] 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-checkins] r42090 - in python/trunk: Modules/getbuildinfo.c PCbuild/make_buildinfo.vcproj PCbuild/pcbuild.sln PCbuild/pythoncore.vcproj
Tim Peters wrote: > Did this checkin perhaps forget to add that file? Oops, indeed - please try again. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] basenumber redux
On 1/17/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Alex Martelli wrote:
> > But this doesn't apply to the Python Standard Library, for example see
> > line 1348 of imaplib.py: "if isinstance(date_time, (int, float)):".
> [...]
> > Being able to change imaplib to use basenumber instead of (int, float)
> > won't make it SIMPLER, but it will surely make it BETTER -- why should
> > a long be rejected, or a Decimal, for that matter?
>
> Right. I think this function should read
>
> if isinstance(date_time, str) and \
> (date_time[0],date_time[-1]) == ('"','"'):
> return date_time# Assume in correct format
>
> if isinstance(date_time, (tuple, time.struct_time)):
> tt = date_time
> else:
> tt = time.localtime(date_time)
So... arbitrary number-like objects should work, but arbitrary
sequence-like objects should fail? Hmmm. Maybe that "if
isinstance()" line should say "if hasattr(date_time, '__getitem__'):".
Am I sure? No. The original author of imaplib apparently got it
wrong, and Martin got it wrong, and they're both smarter than me.
Really this is just further proof that type-checking is a royal pain
in Python. Or rather, it's not hard to cover the builtin and stdlib
types, but it's hard to support "duck typing" too. Are we going about
this the right way? Options:
1. Redesign the API so each parameter has a clearly defined set of
operations it must support, thus eliminating the need for
type-checking. Drawback: An annoying API might be worse than the
problem we're trying to solve.
2. Write a set of imprecise, general-purpose type-checking functions
(is_real_number(v), is_sequence(v), ...) and use those. (They are
imprecise because the requirements are vague and because it's not
really possible to pin them down.) Drawback: Error-prone, compounded
by deceptively clean appearance.
3. Write very specific custom type-checking code each time you need
it (the imaplib approach). Drawbacks: Error-prone (as we've seen),
precarious, tedious, unreadable.
4. Use the "better-to-ask-forgiveness-than-permission" idiom.
Drawback: Potential bad behavior on error, again potentially worse
than the original problem.
Yuck. Does anyone have the answer to this one? Or is the problem not
as bad as it looks?
-j
___
Python-Dev mailing list
[email protected]
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-checkins] r42090 - in python/trunk: Modules/getbuildinfo.c PCbuild/make_buildinfo.vcproj PCbuild/pcbuild.sln PCbuild/pythoncore.vcproj
[Tim] >> Did this checkin perhaps forget to add that file? [Martin] > Oops, indeed - please try again. It may ;-) be better now. Looks like the release build finished, but the debug build died: """ -- Build started: Project: pythoncore, Configuration: Debug Win32 -- generate buildinfo C:\Program Files\TortoiseSVN\bin\subwcrev.exe .. ..\Modules\getbuildinfo.c getbuildinfo2.c 'C:\Program' is not recognized as an internal or external command, operable program or batch file. cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -D_DEBUG -MDd getbuildinfo2.c -DSUBWCREV -Fogetbuildinfo.o -I..\Include -I..\PC Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86 Copyright (C) Microsoft Corporation 1984-2002. All rights reserved. getbuildinfo2.c c1 : fatal error C1083: Cannot open source file: 'getbuildinfo2.c': No such file or directory Linking... LINK : fatal error LNK1181: cannot open input file 'getbuildinfo.o' """ OK, I added code to getbuildinfo.c to quote the path to the executable before invoking system(), and that seemed to fix it. On my box. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] str with base
Jack wrote: > The arbitrary base case isn't even academic > or we would see homework questions about it > on c.l.py. No one asks about > hex or octal because they are there. I have wanted base-36 far more often than I've wanted base-8. I haven't needed any base (except 10) often enough to justify putting it in builtins rather than a stdlib module. I do like the idea of adding Raymond's def base(number, base, prefix) to the stdlib (possibly in math). -jJ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] basenumber redux
Jason Orendorff wrote:
> Really this is just further proof that type-checking is a royal pain
> in Python. Or rather, it's not hard to cover the builtin and stdlib
> types, but it's hard to support "duck typing" too. Are we going about
> this the right way?
It's not as bad. There is nothing wrong with restricting the set of
acceptable types if callers would have no problems to convert their
input into one of the acceptable types.
In the imaplib example, requesting that a broken-down time is passed
as a tuple or a time.struct_time is not too hard for a caller.
It will be formatted as
dt = time.strftime("%d-%b-%Y %H:%M:%S", tt)
so it needs to have the right number of fields. Callers having
other kinds of sequence can easily use tuple(L) to convert their
data into what the function accepts.
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python icon
[EMAIL PROTECTED] wrote: >Steve> We should also add script explaining how to download the beta >Steve> site data and the generation software so people can play with it >Steve> and get ready to be webmasters :-) > >My first attempt ended almost immediately. Too much software to download >and install for anything like casual use. > > > For casual use why not just edit the rest file? That was one of main points about creating a file based admin system... Most users can just edit the rest files or data files (one of the library dependences could have been avoided by using xml for the data files but I'm not sure this would have gone down well). Creating new pages is also mostly just writing rest content (if you want to do this but can't be bothered to install the software, send your work over to me and I'll add it). You only need to have all of the software if you are creating whole new sections, in which case it wouldn't really be casual use. I may be wrong in saying this, but I thought the main idea of having software libraries was to use them? I avoided writing specific modules because the software was out there that did things a lot better than I could rewrite. Is there a level of library use that is acceptable beyond which we should rewrite components or bundle libraries? I would have thought most applications that involved web site creation would have at least three or four external library dependencies (templating, data interface, web server/http module). Tim Parkin ___ Python-Dev mailing list [email protected] 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
>> My first attempt ended almost immediately. Too much software to download >> and install for anything like casual use. Tim> For casual use why not just edit the rest file? 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. I'll take another look when I have a chance. I would be happy to simple edit rest files if I knew what to edit. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python icon
[EMAIL PROTECTED] wrote: > >> My first attempt ended almost immediately. Too much software to > download > >> and install for anything like casual use. > > Tim> For casual use why not just edit the rest file? > > 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. > > I'll take another look when I have a chance. I would be happy to simple > edit rest files if I knew what to edit. To build all of the web pages, you need to have a yaml parser installed. As much as I'd like a pure python yaml parser, the syck c parser is currently the definitive implementation (and the pysyck wrapper at xitology the definitive python wrapper). The syck files are used to manage the data for the templates but 95% of the pages I've migrated have just been a simple nav yaml file with a rest file for the body of the content. The beta site is being rebuilt on commit so if you see any content missing, it needs generating. I've added a couple of tickets highlighting large areas that need work (the tickets on psf.pollenation.net with "CONTENT" as a prefix). If you want to proof content you can just go to the appropriate data directory (matching the url of the page in question) and edit the rest file. If you want to add new pages, it would be good to be able to build the site to check what you have added is working. However, as there aren't many people working on the site, I'd be more than happy to take whatever you can supply and integrate it into the site. At the moment I'm torn between making the software easier to use or making sure content is migrated. It should only take about 10 or 20 minutes to get the software installed (if it takes longer then please tell me what the problems are and I'll try to document any issues and streamline the process - I'd rather not optimise the install/docs until there are specific problems - I think my time is better spent getting some of the more complex content migrated, and ironing out the last problems with the css, and getting new images for the home page and writing new content for the 'for ...' sections and getting the success stories copied over, and getting wiki content integrated and getting the docs integrated into the site better, and ..well .. other stuff). I really want to make the website easier for people to work on and fully intend to provide some form of simple web based content management when enough content has been migrated to allow the site to go live. I hope that wasn't too much of a rant.. :-) Drop me an email if I can help in any way. Tim ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
Brett Cannon wrote: > On 1/18/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: I'd propose bin() to stay in line with the short abbreviated names. >>> There has been some previous discussion about removing hex()/oct() >> from >>> builtins for Python 3.0, IIRC. I sure don't think bin() belongs >> there. >> >> Perhaps introduce a single function, base(val, radix=10, prefix=''), as >> a universal base converter that could replace bin(), hex(), oct(), etc. >> >> That would give us fewer builtins and provide an inverse for all the >> int() conversions (i.e. arbitrary bases). Also, it would allow an >> unprefixed output which is what I usually need. >> > > +1. Differs from Neal's format() function by not magically > determining the prefix from the radix which I like. +1 here, too, particularly if hex/oct acquire Deprecation (or even just PendingDeprecation) warnings at the same time. I have my own reason for wanting to avoid the name format() - I'd still like to see it used one day to provide a builtin way to use string.Template syntax for arbitrary string formatting. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] 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
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! -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
On Jan 18, 2006, at 11:09 AM, Brett Cannon wrote: > On 1/18/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: I'd propose bin() to stay in line with the short abbreviated names. >>> >>> There has been some previous discussion about removing hex()/oct() >> from >>> builtins for Python 3.0, IIRC. I sure don't think bin() belongs >> there. >> >> Perhaps introduce a single function, base(val, radix=10, >> prefix=''), as >> a universal base converter that could replace bin(), hex(), oct(), >> etc. >> >> That would give us fewer builtins and provide an inverse for all the >> int() conversions (i.e. arbitrary bases). Also, it would allow an >> unprefixed output which is what I usually need. > > +1. Differs from Neal's format() function by not magically > determining the prefix from the radix which I like. I'm not sure I see the advantage of, say, print base(x, radix=2, prefix='0b') versus print '0b'+base(x, radix=2) IOW, if the prefix needs to be explicitly specified anyway, what's the advantage of specifying it as an argument to base, rather than just string-concatenating it? Apart from that quibble, the base function appears to cover all the use cases for my proposed str-with-base, so, since it appears to attract less arguments, I'm definitely +1 on it. Alex ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
On 1/18/06, Alex Martelli <[EMAIL PROTECTED]> wrote: > On Jan 18, 2006, at 11:09 AM, Brett Cannon wrote: > > > On 1/18/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > I'd propose bin() to stay in line with the short abbreviated names. > >>> > >>> There has been some previous discussion about removing hex()/oct() > >> from > >>> builtins for Python 3.0, IIRC. I sure don't think bin() belongs > >> there. > >> > >> Perhaps introduce a single function, base(val, radix=10, > >> prefix=''), as > >> a universal base converter that could replace bin(), hex(), oct(), > >> etc. > >> > >> That would give us fewer builtins and provide an inverse for all the > >> int() conversions (i.e. arbitrary bases). Also, it would allow an > >> unprefixed output which is what I usually need. > > > > +1. Differs from Neal's format() function by not magically > > determining the prefix from the radix which I like. > > I'm not sure I see the advantage of, say, > > print base(x, radix=2, prefix='0b') > > versus > > print '0b'+base(x, radix=2) > > IOW, if the prefix needs to be explicitly specified anyway, what's > the advantage of specifying it as an argument to base, rather than > just string-concatenating it? It collects the data that is expected to be used in the common case in a single location/operation. This would allow you to do something like ``base(x, **radix_and_prefix_dict)`` and have everythihng in a nice, neat package. Plus the operation would be faster if base() is written in C. =) The other option is to go with Neal's solution for automatically including the prefix for known prefix types, but instead of it being a boolean, let it be a string argument. That means if you want no prefix you would just set the argument to the empty string. Not setting it will just use the most sensible prefix or none if one is not known for the specified radix. Could have something somewhere, like string or math, where more radix/prefix pairs can be added by the user and have base() reference that for its prefix values. IOW I am +0 on prefix in one of these forms. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Building on OS X 10.4 fails
On Wed, Jan 18, 2006, Guido van Rossum wrote: > > Can we just all agree that RMS is an asshole now? Bah. "Citing RMS's insanity is a great way to get my blood steaming." --GvR -- 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Building on OS X 10.4 fails
On Jan 18, 2006, at 11:40 PM, Aahz wrote: > On Wed, Jan 18, 2006, Guido van Rossum wrote: >> >> Can we just all agree that RMS is an asshole now? Bah. > > "Citing RMS's insanity is a great way to get my blood steaming." -- > GvR Ya know, you don't *have* to use his software. For example, python could stop supporting readline and support libedit instead. James ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Building on OS X 10.4 fails
On Jan 18, 2006, at 8:47 PM, James Y Knight wrote: > > On Jan 18, 2006, at 11:40 PM, Aahz wrote: > >> On Wed, Jan 18, 2006, Guido van Rossum wrote: >>> >>> Can we just all agree that RMS is an asshole now? Bah. >> >> "Citing RMS's insanity is a great way to get my blood steaming." -- >> GvR > > Ya know, you don't *have* to use his software. For example, python > could stop supporting readline and support libedit instead. It'd probably be better to just use something like pyrepl , which builds on top of curses and termios. More Python code, less GPL mess. -bob ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Building on OS X 10.4 fails
On Jan 18, 2006, at 8:47 PM, James Y Knight wrote: > On Jan 18, 2006, at 11:40 PM, Aahz wrote: > >> On Wed, Jan 18, 2006, Guido van Rossum wrote: >>> >>> Can we just all agree that RMS is an asshole now? Bah. >> >> "Citing RMS's insanity is a great way to get my blood steaming." -- >> GvR > > Ya know, you don't *have* to use his software. For example, python > could stop supporting readline and support libedit instead. In Py3k this should indeed be considered; I don't think it can be within Python 2.*, since it would be a major and never fully backwards-compatible change. Alex ___ Python-Dev mailing list [email protected] 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
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? n ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] basenumber redux
> -Original Message- > From: [EMAIL PROTECTED] [mailto:python-dev- > [EMAIL PROTECTED] On Behalf Of Martin v. Löwis > Sent: Wednesday, January 18, 2006 3:36 PM > To: Jason Orendorff > Cc: [email protected] > Subject: Re: [Python-Dev] basenumber redux > > Jason Orendorff wrote: > > Really this is just further proof that type-checking is a royal pain > > in Python. Or rather, it's not hard to cover the builtin and stdlib > > types, but it's hard to support "duck typing" too. Are we going about > > this the right way? > > It's not as bad. There is nothing wrong with restricting the set of > acceptable types if callers would have no problems to convert their > input into one of the acceptable types. Somehow my earlier post on this thread didn't seem to take. There are problems for callers converting their inputs: * currently existing number-like objects would need be retro-fitted with a new base class and possibly change their behavior from old-style to new-style. * some useful classes (such as a symbolic type) already inherit from str. That prevents them from also being able to inherit from basenumber. I'm -1 on the proposal because the benefits are dubious (at best it simplifies just a handful of code fragments); it adds yet another API to learn and remember; it is darned inconvenient for existing code seeking to emulate number-like behavior; and it precludes number emulation for classes that already have a built-in base class. For the most part, functions that enforce type checking are up to no good and make life harder for their callers. If Python ultimately grows interfaces, I hope they remain optional; as soon as functions start insisting on interface checking, then it will spread like cancer. The basenumber proposal is essentially a step down that slippery slope. Raymond Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
Guido, we may be converging on a consensus for my proposal: base(value, radix=2) So far no one has shot at it, and it has gathered +1's from Steven, Alex, Brett, and Nick. To keep it simple, the proposal is for the value to be any int or long. With an underlying __base__ method call, it wouldn't be hard for someone to build it out to support other numeric types if the need arises. The output would have no prefixes. As Alex pointed out, it is easier and more direct to add those after the fact if needed. Care to pronounce on it? Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
On 1/18/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > Guido, we may be converging on a consensus for my proposal: > > base(value, radix=2) > > So far no one has shot at it, and it has gathered +1's from Steven, > Alex, Brett, and Nick. +1 for me too, but I'd also like to deprecate hex() and oct() and slate them for removal in 3k. To expand, valid radix values would be 2..36 (ie, same as for int). It was discussed putting base() in some module. Was there consensus about builtin vs a module? I'd prefer a module, but builtin is ok with me. > To keep it simple, the proposal is for the value to be any int or long. > With an underlying __base__ method call, it wouldn't be hard for someone > to build it out to support other numeric types if the need arises. > > The output would have no prefixes. As Alex pointed out, it is easier > and more direct to add those after the fact if needed. +1 > Care to pronounce on it? > > > Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str with base
On Jan 18, 2006, at 11:37 PM, Neal Norwitz wrote: > On 1/18/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: >> Guido, we may be converging on a consensus for my proposal: >> >> base(value, radix=2) >> >> So far no one has shot at it, and it has gathered +1's from Steven, >> Alex, Brett, and Nick. > > +1 for me too, but I'd also like to deprecate hex() and oct() and > slate them for removal in 3k. > > To expand, valid radix values would be 2..36 (ie, same as for int). > It was discussed putting base() in some module. Was there consensus > about builtin vs a module? I'd prefer a module, but builtin is ok > with me. I'd drop the default radix, or make it something common like 16... especially if hex and oct are to be py3k deprecated. +1 for: base(value, radix) +1 for: "%b" % (integer,) +0 for binary literals: 0b01101 -bob ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
