Alex Martelli wrote:
I'll be happy to draft a PEP if needed (and just as happy to
eventually provide an implementation patch if the PEP's accepted),
but wanted to doublecheck on the general issue first!
I haven't really followed the earlier basenumber discussions (aside from the
sidetrack
On Monday 16 January 2006 20:05, Nick Coghlan wrote:
For example, what's wrong with hasattr(x, __int__)? That works
for all the builtin types, and, IMO, anyone defining a direct
conversion to an integer for a non-numeric type deserves whatever
happens to them.
What about something that's got
Martin v. Löwis [EMAIL PROTECTED] writes:
Guido van Rossum wrote:
On the other hand it breaks one of the most fundamental Python
guidelines: if you get a core dump (segfault etc.) it's a bug in
Python or in a 3rd party extension, not in *your* Python code. An
exception would have to be made
Tim Peters wrote:
[Georg Brandl -- or so he claimed on January 8]
today, when two Python developers here had approached me about the PSF, I
realized that it is time to correct a mistake which I had made over three
years
ago, when I discovered Linux, free software, Usenet etc (I was sixteen at
Thomas Heller [EMAIL PROTECTED] writes:
It looks like we need a pronouncement now.
+1
I am a lurker in this list. I maintain ctypes for Debian and I would love to
see it in core python. Debian now includes ctypes for 10 Linux architectures
and kFreeBSD. The only missing significant
Hi,
Perhaps I am the only one bothered by the timeit
module, but it seems poorly designed to me.
First of all, it should use a geometric series with a
timeout value to detect how many iterations it should
perform. Currently, the user is required to manually
specify the number of iterations
Martin v. Löwis wrote:
Christian Tismer wrote:
1. create a file
2. get it's os.path.getmtime()
3. change your time zone
4. get os.path.getmtime again
compare - the time stamps are different.
Change the time zone back, and they are identical, again.
Just to add an important detail here:
Jim Fulton wrote:
Tim Peters wrote:
[Georg Brandl -- or so he claimed on January 8]
today, when two Python developers here had approached me about the PSF, I
realized that it is time to correct a mistake which I had made over three
years
ago, when I discovered Linux, free software, Usenet
Connelly Barnes wrote:
Hi,
Perhaps I am the only one bothered by the timeit
module, but it seems poorly designed to me.
First of all, it should use a geometric series with a
timeout value to detect how many iterations it should
perform. Currently, the user is required to manually
On Mon, Jan 16, 2006 at 01:37:18PM +0900, Seo Sanghyeon wrote:
But hashlib.new() takes the algorithm name... Does PEP need an update?
The new() function in hashlib's interface doesn't conform to PEP 247;
that's all. I don't think the PEP needs to be updated.
--amk
On 1/16/06, Steve Holden [EMAIL PROTECTED] wrote:
Jim Fulton wrote:
In general though, for adults, truthfulness and non-anonymity *do*
matter. At least they matter to me, a *lot*. I don't think members
of the PSF should be allowed to hide their identity and certainly,
it should not be
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.
--
--Guido
On 1/15/06, Alex Martelli [EMAIL PROTECTED] wrote:
Now, today, I have _again_ been bit by the lack of basenumber (by a
bug of mine, fixed by adding decimal.Decimal to a long tuple of
classes to be passed to an isinstance call -- I hadn't run that
particular numeric code of mine since the time
[vinay]
Log:
Fixed bug in time-to-midnight calculation.
[Skip]
Is there some reason not to use datetime to do this?
PEP 291 says logging intends to be compatible with Python 1.5.2, which
leaves datetime out.
Vinay, rather than:
if (currentMinute == 0) and (currentSecond == 0):
Gabriel Becedillas wrote:
Michael Hudson wrote:
Gabriel Becedillas [EMAIL PROTECTED] writes:
Hi,
At the company I work for, we've embedded Python in C++ application
we develop. Since our upgrade to Python 2.4.2 from 2.4.1 we started
hitting Py_FatalError(Invalid thread state for this
On Jan 16, 2006, at 7:53 AM, Guido van Rossum wrote:
On 1/15/06, Alex Martelli [EMAIL PROTECTED] wrote:
Now, today, I have _again_ been bit by the lack of basenumber (by a
bug of mine, fixed by adding decimal.Decimal to a long tuple of
classes to be passed to an isinstance call -- I hadn't
Alex Martelli wrote:
As you already suspected, I think a PEP is needed. The intent of
I'll be happy to write it, if it stands any chance.
basestring was to *only* be used as the base class for *built-in*
string types. Clearly what you're proposing is different (Decimal is
not built-in
Guido van Rossum wrote:
[...]
I think that's unnecessary, and not any more effective than what we
already do -- ask for a signed contributor form. Someone who signs
that form Tim Peters won't be stopped by a clause asking them to use
their real name, *really*.
Sorry. My previous message
Alex Martelli wrote:
I can't find a PEP describing this restriction of basestring, and I
don't see why a coder who needs to implement another kind of
character string shouldn't subclass basestring, so that those
instances pass an isinstance test on basestring which is quite likely
to
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,
Jim Fulton wrote:
In general though, for adults, truthfulness and non-anonymity *do*
matter. At least they matter to me, a *lot*. I don't think members
of the PSF should be allowed to hide their identity and certainly,
it should not be acceptable to contribute to Python under a false name.
[Jim Fulton]
certainly, it should not be acceptable to contribute to Python
under a false name.
What do you mean contribute to Python? Do you mean become one of
the developers listed on sourceforge? Contribute any patches, even
simple documentation ones? Review, comment and test
On Mon, Jan 16, 2006, Jim Fulton wrote:
In general though, for adults, truthfulness and non-anonymity *do*
matter. At least they matter to me, a *lot*. I don't think members
of the PSF should be allowed to hide their identity and certainly, it
should not be acceptable to contribute to
On Jan 16, 2006, at 2:01 PM, Martin v. Löwis wrote:
Alex Martelli wrote:
I can't find a PEP describing this restriction of basestring, and I
don't see why a coder who needs to implement another kind of
character string shouldn't subclass basestring, so that those
instances pass an
On 1/16/06, Alex Martelli [EMAIL PROTECTED] wrote:
Nothing was said about different design intent for basestring, as I
recall (that discussion comes up among the few hits for [basestring
site:python.org] if you want to check the details).
Please. How many times do I have to say this. *I added
Is it finally time in Python 2.5 to allow the obvious use of, say,
str(5,2) to give '101', just the converse of the way int('101',1)
gives 5? I'm not sure why str has never allowed this obvious use --
any bright beginner assumes it's there and it's awkward to explain
why it's not!-).
On 1/16/06, Alex Martelli [EMAIL PROTECTED] wrote:
Is it finally time in Python 2.5 to allow the obvious use of, say,
str(5,2) to give '101', just the converse of the way int('101',1)
I think you mean ``int('101' 2)``. =)
gives 5? I'm not sure why str has never allowed this obvious use --
Is it finally time in Python 2.5 to allow the obvious use of, say,
str(5,2) to give '101', just the converse of the way int('101',2)
gives 5?
+1
The only downside is that like list.reverse(), it will deprive students
of being assigned to write the roll-your-own version.
Raymond
[Me]
Even if there were a performance edge, I suppose that the type
checking
is the time critical part of most scripts.
That should be: RARELY the time critical part of most scripts.
___
Python-Dev mailing list
Python-Dev@python.org
It never occured to me that str() would behave like int() for this
case. It makes complete sense to me that a factory for numbers would
ask about the base of the number. What would the base of a string be,
except in a few limited cases? str([1, 2], 4) doesn't make any sense.
You might argue
On 1/16/06, Alex Martelli [EMAIL PROTECTED] wrote:
Is it finally time in Python 2.5 to allow the obvious use of, say,
str(5,2) to give '101', just the converse of the way int('101',1)
[I'm sure you meant int('101', 2) here]
gives 5? I'm not sure why str has never allowed this obvious use --
On Mon, Jan 16, 2006 at 07:44:44PM -0800, Alex Martelli wrote:
Is it finally time in Python 2.5 to allow the obvious use of, say,
str(5,2) to give '101',
My reaction having read this far was huh?. It took some time (several
seconds) before it occurred to me what you wanted str(5,2) to mean,
I wish you had an argument better than every bright beginner assumes
it exists. :-)
But (unlike for some other things that bright beginners might assume)
I don't think there's a deep reason why this couldn't exist.
The only reasons I can come up with is because input and output are
On Mon, 16 Jan 2006 19:44:44 -0800, Alex Martelli [EMAIL PROTECTED] wrote:
Is it finally time in Python 2.5 to allow the obvious use of, say,
str(5,2) to give '101', just the converse of the way int('101',1)
gives 5? I'm not sure why str has never allowed this obvious use --
any bright beginner
On Tue, 2006-01-17 at 15:08 +1100, Andrew Bennetts wrote:
My reaction having read this far was huh?. It took some time (several
seconds) before it occurred to me what you wanted str(5,2) to mean, and why it
should give '101'.
If you'd proposed, say (5).as_binary() == '101', or
On Jan 16, 2006, at 8:03 PM, Jeremy Hylton wrote:
It never occured to me that str() would behave like int() for this
case. It makes complete sense to me that a factory for numbers would
ask about the base of the number. What would the base of a string be,
except in a few limited cases?
On 1/16/06, Alex Martelli [EMAIL PROTECTED] wrote:
On Jan 16, 2006, at 8:03 PM, Jeremy Hylton wrote:
I think it shouldn't be changed, because the second positional
argument only works for a small number of the panoply types that can
be passed to str().
Identically the same situation as
On Jan 16, 2006, at 8:18 PM, Barry Warsaw wrote:
On Tue, 2006-01-17 at 15:08 +1100, Andrew Bennetts wrote:
My reaction having read this far was huh?. It took some time
(several
seconds) before it occurred to me what you wanted str(5,2) to
mean, and why it
should give '101'.
If
[Jeremy Hylton]
The concept of base is closely related to ints, and the base argument
is useful for a large percentage of the types that int accepts. It is
not related to strings, in general, and applies to only one of the
types it accepts. In one case not a float, etc. applies to a very
On Mon, Jan 16, 2006 at 11:54:05PM -0500, Raymond Hettinger wrote:
[...]
That suggests that it would be better to simply add an int method:
x.convert_to_base(7)
This seems clear and simple to me. I like it. I strongly suspect the bright
beginners Alex is interested in would have no
On Jan 16, 2006, at 9:12 PM, Andrew Bennetts wrote:
On Mon, Jan 16, 2006 at 11:54:05PM -0500, Raymond Hettinger wrote:
[...]
That suggests that it would be better to simply add an int method:
x.convert_to_base(7)
This seems clear and simple to me. I like it. I strongly suspect
On Mon, Jan 16, 2006 at 09:28:10PM -0800, Bob Ippolito wrote:
On Jan 16, 2006, at 9:12 PM, Andrew Bennetts wrote:
[...]
x.convert_to_base(7)
This seems clear and simple to me. I like it. I strongly suspect
the bright
beginners Alex is interested in would have no trouble using it or
On Mon, 2006-01-16 at 20:49 -0800, Bob Ippolito wrote:
The only bases I've ever really had a good use for are 2, 8, 10, and
16. There are currently formatting codes for 8 (o), 10 (d, u), and
16 (x, X). Why not just add a string format code for unsigned
binary? The obvious choice is
On 1/16/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 1/16/06, Alex Martelli [EMAIL PROTECTED] wrote:
Is it finally time in Python 2.5 to allow the obvious use of, say,
str(5,2) to give '101', just the converse of the way int('101',1)
[I'm sure you meant int('101', 2) here]
gives 5?
Alex Martelli wrote:
As I suggested in a different message: Why are you doing that
in the first place?
Because isinstance is faster and handier than testing with try/except
around (say) x+0.
Nit: I think you should not test. Instead, you should starting you mean
to do if the test passes,
On 1/16/06, Bob Ippolito [EMAIL PROTECTED] wrote:
On Jan 16, 2006, at 9:12 PM, Andrew Bennetts wrote:
On Mon, Jan 16, 2006 at 11:54:05PM -0500, Raymond Hettinger wrote:
[...]
That suggests that it would be better to simply add an int method:
x.convert_to_base(7)
This seems
Raymond Hettinger wrote:
Are you sure? The former has two builtin lookups (which also entail two
failed global lookups), a function call, and a test/jump for the result.
The latter approach has no lookups (just a load constant), a try-block
setup, an add operation (optimized for integers, a
47 matches
Mail list logo
