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(). Un
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
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 'cleanl
[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 t
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!
[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 issu
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
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
"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,
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
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 ot
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
>>> wel
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
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 ot
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
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.
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
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
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 im
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
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 PROTECTE
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
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 bu
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,
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
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 s
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
27 matches
Mail list logo
