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
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
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,
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
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
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
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
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
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
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
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
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.
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
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
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
[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.
[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
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'
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
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
20 matches
Mail list logo
