Re: [Python-Dev] basenumber redux

[Nick Coghlan]

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 into the nature of mappings), but why would we want this ability as 
a typecheck and not some form of interface check?

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.

Something like:

   def is_number(x):
   return hasattr(x, '__int__')

   def is_integer(x):
   return x == int(x)

Requiring inheritance from "basenumber" in order to make something behave like 
a real number seems antithetical to both duck-typing and the adaptation PEP.

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] basenumber redux

[Anthony Baxter]

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 something like:

  def __int__(self):
  raise TypeError("This type is not a number!")

I don't see a problem with defining basenumber. For the use cases, 
pretty much the same set as basesstring.



-- 
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
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]

"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 for any code that uses ctypes, as it
>> is usually trivial to cause core dumps with ctypes (I'd venture it's
>> hard to avoid them ;-).
>> 
>> I don't expect this to count against including ctypes; but I do want
>> it to be dealt with somehow!
>
> I think the strongest point *for* ctypes is the inclusion of dl
> in the source distribution, which has the very same flaws as
> ctypes in terms of crashability.
>
> So as for dealing with it "somehow": I would make ctypes a dynamically
> loaded module (ctypes.pyd), so administrators could remove it, and
> I could also make it a separate option in the Windows installer,
> so administrators could reject to install it.

It looks like we need a pronouncement now.

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

[Python-Dev] Names matter.

[Jim Fulton]

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 
>>that time).
>>
>>I then assumed a different name, partly to anonymize myself as others had 
>>advised.
>>When I came across Python, I instantly liked it, and since I had interest in
>>Open Source development in general, I wanted to try and contribute to the
>>development.
>>
>>And, as a matter of course, I used my different name for that. When I 
>>realized that
>>I liked the community and the development of Python very much, I decided to
>>"unveil" myself, but I could never overcome myself -- till now.
>>
>>I'm really sorry, and I hope you could at least partly understand what caused
>>me to act so irrational.
> 
> 
> It doesn't really matter, Georg:  by default, Python compares by
> object identity, not name.  If _you_ haven't changed, your name
> doesn't matter.

I realize that folks are, rightly, trying to encourage Georg.  I think
protection of the identity of a minor on the Internet is understandable
and justifiable.

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

-- 
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.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] Include ctypes into core Python?

[Ganesan Rajagopal]

> 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 architecture is ARM because of
lack of FFI support.

Ganesan

-- 
Ganesan Rajagopal (rganesan at debian.org) | GPG Key: 1024D/5D8C12EA
Web: http://employees.org/~rganesan| http://rganesan.blogspot.com


___
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] timeit module

[Connelly Barnes]

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 (the default is 1
million).  If the user optimizes his or her code, then
the number of iterations must be changed.  If the user
moves to a slower or faster computer, then the number
of iterations must be changed again.  This is
annoying.

Secondly, there should be a way to time a callable
directly.  That is, without finding the string name of
the callable and using a string "import X" statement. 
These contortions violate rules #1 and #3 of the Zen
of Python.

Yes, there is function call overhead in timing a
callable as opposed to a fragment of code.  However,
when I'm benchmarking code I am often timing
functions, so it seems logical to make this easy to
do.

I have three (mutually exclusive) ideas for improving
the current situation:

 * Add a time_callable() or time_func() function to
   the timeit module.  These would take the callable,
   args, kwargs, and maximum time* to spend timing the
   function as arguments.
 * Add a FuncTimer class (function/callable timer) to
the
   existing timeit module.  The constructor takes a
callable,
   args, kwargs as arguments.  The class has instance
methods  
   timeit(max_time=4.0) and repeat(repeat=3,
max_time=4.0).
 * Create a new timeit module (e.g. timeit2) which
uses
   geometric series to implement both code fragment
timing
   (which timeit does) and callable timing.

I have a simple implementation of geometric series
timing routines for callables and code fragments. 
This is recipe
440657.

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/440657

This recipe leaves the GC enabled.

Clearly, this is simple to implement.  If python-dev
likes the
idea of improving Python's timeit functionality, I
volunteer to
implement whichever interface is decided upon.

Opinions?

Thanks,
Connelly Barnes

* The maximum time will be exceeded only if a single
call to
  the callable takes more than max_time seconds.


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
___
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] os.path.getmtime on Windows

[Christian Tismer]

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: I assume
> you did not exit Python between step 2 and step 4, right?
> (please confirm whether this is the case).

No, I did not exit Python.
The problem only appeared when I changed time zone.
Changing the date had no effect.

-- 
Christian Tismer :^)   
tismerysoft GmbH : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A :*Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.com/

___
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] Names matter.

[Steve Holden]

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 etc (I was sixteen at 
>>>that time).
>>>
>>>I then assumed a different name, partly to anonymize myself as others had 
>>>advised.
>>>When I came across Python, I instantly liked it, and since I had interest in
>>>Open Source development in general, I wanted to try and contribute to the
>>>development.
>>>
>>>And, as a matter of course, I used my different name for that. When I 
>>>realized that
>>>I liked the community and the development of Python very much, I decided to
>>>"unveil" myself, but I could never overcome myself -- till now.
>>>
>>>I'm really sorry, and I hope you could at least partly understand what caused
>>>me to act so irrational.
>>
>>
>>It doesn't really matter, Georg:  by default, Python compares by
>>object identity, not name.  If _you_ haven't changed, your name
>>doesn't matter.
> 
> 
> I realize that folks are, rightly, trying to encourage Georg.  I think
> protection of the identity of a minor on the Internet is understandable
> and justifiable.
> 
> 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.
> 
In principle I think you are correct.

In practice it's difficult to see how to nsure this without insistence 
on some digital certificate from an acceptable CA - by which I mean one 
that actually checks a driving license or passport before asserting a 
user's identity. Both CACert and Thawte have web-of-trust-like schemes 
to support this.

In the meantine what do we do? Ask for a signed statement that 
contributors are contributing under their own identities?

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] timeit module

[Steve Holden]

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
> specify the number of iterations (the default is 1

The provision of a default value generally seems to chop the legs from 
your argument that the number of iterations is required.

> million).  If the user optimizes his or her code, then
> the number of iterations must be changed.  If the user
> moves to a slower or faster computer, then the number
> of iterations must be changed again.  This is
> annoying.
> 
What? The purpose of timeit is to give an approximation to the length of 
time to run a specific piece ofcode.

Why must the number of iterations be changed when moving to a slower or 
faster computer?

> Secondly, there should be a way to time a callable
> directly.  That is, without finding the string name of
> the callable and using a string "import X" statement. 
> These contortions violate rules #1 and #3 of the Zen
> of Python.
> 
Presumably for benchmarking purposes the function call overhead would be 
present for all compaered techniques. Do you mean rules #0 and #2?

 > [...]
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] PEP 247 and hashlib

[A.M. Kuchling]

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
___
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] Names matter.

[Guido van Rossum]

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 acceptable to contribute to Python under a false name.

Agreed. Also, I find it difficult to exchange emails with someone who
is known by an alias only.

> In principle I think you are correct.
>
> In practice it's difficult to see how to nsure this without insistence
> on some digital certificate from an acceptable CA - by which I mean one
> that actually checks a driving license or passport before asserting a
> user's identity. Both CACert and Thawte have web-of-trust-like schemes
> to support this.
>
> In the meantine what do we do? Ask for a signed statement that
> contributors are contributing under their own identities?

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*.

--
--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] Include ctypes into core Python?

[Guido van Rossum]

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 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] basenumber redux

[Guido van Rossum]

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 of Python 2.3,
> apparently), so I'm back to pining for it.

As you already suspected, I think a PEP is needed. The intent of
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 -- not yet anyway).

Like other posters, I suspect that the best way of detecting numbers
might be some other kind of test, not necessarily a call to
isinstance().

It would also help to explain the user case more. ("I've been bitten"
doesn't convey a lot of information. :-)

--
--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] [Python-checkins] r42064 - python/trunk/Lib/logging/handlers.py

[Tim Peters]

[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):
r = (24 - currentHour) * 60 * 60 # number of hours in seconds
else:
r = (23 - currentHour) * 60 * 60
r = r + (59 - currentMinute) * 60 # plus the number of minutes (in secs)
r = r + (60 - currentSecond) # pl

for clarity I suggest this instead:

# A module-level constant
_MIDNIGHT = 24 * 60 * 60  # number of seconds in a day

r = _MIDNIGHT - ((currentHour * 60 + currentMinute) * 60 + currentSecond)

That's "obviously correct" instead of "huh?" .
___
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]

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 thread") when 
>>> using debug builds.
>>> We use both multiple interpreters and thread states.
>>
>>
>> I know you've said this to me in email already, but I have no idea how
>> you managed to get this to work with 2.4.1 :)
>>
>>
>>> I think the problem is that PyThreadState_Delete (which is used when I
>>> destroy thread states and interpreters) is not making the same clean up
>>> that PyThreadState_DeleteCurrent is doing (which is used when we 
>>> create threads from python code). If a thread id is reused (obviously 
>>> not between two running threads), and the previous thread used 
>>> PyThreadState_Delete instead of PyThreadState_DeleteCurrent, then an 
>>> old and invalid value for autoTLSkey is still stored, and that is
>>> triggering the Py_FatalError when a call to PyThreadState_Swap is made.
>>> If I add this code at the end of PyThreadState_Delete:
>>>
>>> if (autoTLSkey && PyThread_get_key_value(autoTLSkey) == tstate)
>>> PyThread_delete_key_value(autoTLSkey);
>>>
>>> then everything works fine.
>>
>>
>> I think I begin to understand the problem... but this is still
>> fragile: it relies on the fact that you delete a thread state from the
>> OS level thread that created it, but while a thread belonging to a
>> different *interpreter state* has the GIL (or at least: the
>> interpreter state of the thread state being deleted *doesn't* hold the
>> GIL).  Can you guarantee that?
> 
> Mmm... it doesn't have to do with a race condition or something. Let me 
> try to show you with an example (keep in mind that this relies on the 
> fact that at some moment the operating system gives you a thread with 
> the same id of another thread that allready finished executing):
> 
> // Initialize python.
> Py_Initialize();
> PyEval_InitThreads();
> PyThreadState* p_main =  PyThreadState_Swap(NULL);
> PyEval_ReleaseLock();
> 
> /*
> Asume this block is executed in a separate thread, and that has been 
> asigned thread id 10.
> It doesn't matter what the main thread (the thread that initialized 
> Python) is doing. Lets assume its waiting for this one to finish.
> */
> {
> PyEval_AcquireLock();
> PyThreadState_Swap(p_main);
> PyThreadState* p_child = PyThreadState_New(p_main->interp);
> 
> PyThreadState_Swap(p_child);
> PyRun_SimpleString("print 'mi vieja mula ya no es lo que era'");
> 
> PyThreadState_Clear(p_child);
> PyThreadState_Swap(NULL);
> PyThreadState_Delete(p_child);
> PyEval_ReleaseLock();
> // The os level thread exits here.
> }
> /*
> When this thread state gets deleted (using PyThreadState_Delete), the 
> autoTLSkey stored for thread id number 10 is not removed, because 
> PyThreadState_Delete doesn't have the necesary cleanup code (check 
> pystate.c):
> 
> if (autoTLSkey && PyThread_get_key_value(autoTLSkey) == tstate)
> PyThread_delete_key_value(autoTLSkey);
> 
> PyThreadState_DeleteCurrent behaves correctly because it does have this 
> code.
> I think that this code should be added to tstate_delete_common (I've 
> done this and everything worked just fine).
> If a new thread executes the same code, and that thread is assigned the 
> same thread id, you get the Py_FatalError I'm talking about.
> A workaround for this would be to use PyThreadState_DeleteCurrent 
> instead of PyThreadState_Delete.
> 
> If you use the following code instead of the one above, the you have no 
> way out to the Py_FatalError:
> */
> {
> PyEval_AcquireLock();
> PyThreadState* ret = Py_NewInterpreter();
> 
> PyRun_SimpleString("print 'mi vieja mula ya no es lo que era'");
> 
> Py_EndInterpreter(ret);
> PyThreadState_Swap(NULL);
> PyEval_ReleaseLock();
> }
> /*
> When this interpreter gets deleted (using Py_EndInterpreter), its thread 
> state gets deleted using PyThreadState_Delete, and you are back to the 
> beginning of the problem.
> */
> 
> I hope this helps to clarify the problem.
> Thanks a lot and have a nice day.
> 
>> It seems to me that to be robust, you need a way of saying "delete the
>> thread local value of autoTLSKey from thread $FOO".  But this is all
>> very confusing...
>>
>>
>>> Could you please confirm if this is a bug ?
>>
>>
>> Yes, I think it's a bug.
>>
>> Cheers,
>> mwh
>>
> 
> 

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);

Thank you very much.

-- 


Gabriel Becedillas
Developer
CORE SECURITY TECHNOLOGIES

Florida 141 - 2º cuerpo - 7º piso
C1005AAC Buenos Aires - Argentina
Tel/Fax: (54 11) 5032-CORE (2673)
http://www.cores

Re: [Python-Dev] basenumber redux

[Alex Martelli]

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 run that
>> particular numeric code of mine since the time of Python 2.3,
>> apparently), so I'm back to pining for it.
>
> 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 -- not yet anyway).

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 be found e.g. in the standard library.

Implementing different kinds of numbers is more likely than  
implementing different kinds of strings, of course.

> Like other posters, I suspect that the best way of detecting numbers
> might be some other kind of test, not necessarily a call to
> isinstance().

I've tended to use a try/except around x+0 to detect if "x is a  
number".  But that's NOT how the standard library does it -- rather,  
it has isinstance tests (often forgetting long in the tuple of  
types), as I pointed out in my mails on the subject back in 2003  
(google for [basenumber site:python.org], there aren't many).  I will  
reproduce those in the PEP, of course, if I do write one.

The x+0 test has been criticized in the past because x COULD be an  
instance of a type which defines an __add__ which has side effects,  
or a very inclusive __add__ which happens to accept an int argument  
even though the type is NOT meant to be a number.  These could be  
seen as design defects of x's type, of course.

A second argument against the x+0 test is performance.

A third argument against it is asymmetry: why should I use completely  
different approaches to check if x is "some kind of string", vs  
checking if x is "some kind of number"?  Once upon a time I used x 
+'' (with try/except around it) to check for stringness, but the  
introduction of basestring strongly signaled that this was not the  
"one obvious way" any more.

>
> It would also help to explain the user case more. ("I've been bitten"
> doesn't convey a lot of information. :-)

isinstance with a tuple of number types, where the tuple did not  
include Decimal (because when I developed and tested that module,  
Decimal wasn't around yet).

That's the problem of using isinstance without a "flag class" like  
basestring: one is hardwiring a specific tuple of types as being  
"singled out" for different treatment.  If a new type comes up (be it  
for the standard library or some extension) there's no way to respect  
the "open-closed principle", leaving the affected module "closed to  
changes" yet "open for extension".  In this way, using isinstance  
with a "hardwired" tuple of types is open to the same objections as  
"type-switching": it produces code that is not extensible to new  
types beyond those specific ones it had considered at coding time.

I have the same issue in the C-coded extension gmpy: I want (e.g.) a  
gmpy.mpq to be able to be constructed by passing any number as the  
argument, but I have no good way to say "what's a number", so I use  
rather dirty tricks -- in particular, I've had to tweak things in a  
weird direction in the latest gmpy to accomodate Python 2.4  
(specifically Decimal).

Since "being a number" is a protocol (albeit, like "being a string",  
a rather peculiar one -- "the verb TO BE" is always fraught;-), other  
traditional possibilities for supporting it are introducing a special  
method or flag attribute such as "__isanumber__" (either callable, or  
flagging numberhood just by its presence).  But introducing flag- 
abstract-class basenumber is more consistent with what was done for  
strings and affords a simpler test via isinstance.  Of course _if_  
PEP 246 was accepted, anybody could add more types to the set of  
those which "can be adapted to being numbers", but an object to  
denote that protocol should still be there (since the standard  
library does need to test for numberhood in a few places).

If I do write the PEP, should it be just about basenumber, or should  
it include baseinteger as well?  The case for the latter is IMHO  
still good but a bit weaker; it would be nice to be able to code 'xy'  
* Z without having str.__rmul__  perform a hardcoded test on Z being  
specifically an int or a long, making "other kinds of integers" (e.g.  
gmpy.mpz instances) smoothly substitutable for ints everywhere  
(similarly for somelist[Z], of course).  Right now I have to pepper  
my code with int(Z) casts when Z is

Re: [Python-Dev] basenumber redux

[Fredrik Lundh]

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 -- not yet anyway).
>
> I can't find a PEP describing this restriction of basestring

that's how it's documented, at least:

http://effbot.org/lib/builtin.basestring

> Implementing different kinds of numbers is more likely than
> implementing different kinds of strings, of course.

indeed.  implementing a new string type is not a trivial task in today's
CPython.





___
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] Names matter.

[Steve Holden]

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 suffered from a smiley-deficiency. Clearly 
there is little point in a signed piece of paper saying "I am me, signed 
'me'".

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] basenumber redux

[Martin v. Löwis]

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 be found e.g. in the standard library.

People could do that, but they would be on their own. basestring
could be interpreted as "immutable sequence of characterish things",
but it was really meant to be "union of str and unicode". There
is no PEP because it was introduced by BDFL pronouncement.

That it is not a generic base class for stringish types can be
seen by looking at UserString.UserString, which doesn't inherit
from basestring.

For most practical purposes, those two definitions actually
define the same thing - there simply aren't any stringish data
types in praxis: you always have Unicode, and if you don't,
you have bytes.

> Implementing different kinds of numbers is more likely than  
> implementing different kinds of strings, of course.

Right. That's why a PEP is needed here, but not for basestring.

> A third argument against it is asymmetry: why should I use completely  
> different approaches to check if x is "some kind of string", vs  
> checking if x is "some kind of number"?

I guess that's for practicality which beats purity. People often
support interfaces that either accept both an individual string
and a list of strings, and they need the test in that case.
It would be most natural to look for whether it is a sequence;
unfortunately, strings are also sequences.

> isinstance with a tuple of number types, where the tuple did not  
> include Decimal (because when I developed and tested that module,  
> Decimal wasn't around yet).

As I suggested in a different message: Why are you doing that
in the first place?

> I have the same issue in the C-coded extension gmpy: I want (e.g.) a  
> gmpy.mpq to be able to be constructed by passing any number as the  
> argument, but I have no good way to say "what's a number", so I use  
> rather dirty tricks -- in particular, I've had to tweak things in a  
> weird direction in the latest gmpy to accomodate Python 2.4  
> (specifically Decimal).

Not sure what a gmpy.mpq is, but I would expect that can only work
if the  parameter belongs to some algebraic ring homomorphic
with the real numbers, or some such. Are complex numbers also numbers?
Is it meaningful to construct gmpy.mpqs out of them? What about
Z/nZ?

> If I do write the PEP, should it be just about basenumber, or should  
> it include baseinteger as well?

I think it should only do the case you care about. If others have other
use cases, they might get integrated, or they might have to write
another PEP.

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]

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.

Ok. If Thomas checks in the code and the documentation, I'll do the
Windows/setup part of it.

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] Names matter.

[Martin v. Löwis]

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.

Absolutely right. The encouragement is not for the past pseudonym, but
for actually revealing his true identity when it mattered (i.e. when
asked to "officially join"). For contributors, we should really track
copyright forms more thoroughly (and indeed, Georg said he sent one
right after I asked him).

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] Names matter.

[Tony Meyer]

[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 patches?  Work  
on pydotorg?  Write python-dev summaries?  Give money to the PSF?   
(These, and many other things, are all contributing to Python, IMO).

I can understand that for legal purposes having some sort legally  
valid name might be required in some cases (e.g. contributing  
significant amounts of code), but wouldn't having that name known to  
the PSF suffice?  I don't see how a pseudonym hurts when dealing with  
the "public".

=Tony.Meyer
___
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] Names matter.

[Aahz]

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 Python under a false name.

And to me it's important for both political and personal reasons that
people be accepted -- nay, encouraged -- to use pseudonyms as they
please (or even choose to be anonymous).  I won't write a long screed on
this subject because it's off-topic here, but I will oppose any attempt
to limit access to the Python community from people who do not use their
legal names.  (See Alex's excellent post for more detail.)

One point where I do agree with you: I have little taste for morphing
aliases that refer to a single person.  If someone chooses to be
declaratively anonymous, that's fine; if someone chooses to use a stable
pseudonym (or a "real name" that happens to not be zir legal name),
that's fine, too.  But constantly changing identity does strike me as
abusing community.
-- 
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] basenumber redux

[Alex Martelli]

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 isinstance test on basestring which is quite likely
>> to be found e.g. in the standard library.
>
> People could do that, but they would be on their own. basestring
> could be interpreted as "immutable sequence of characterish things",
> but it was really meant to be "union of str and unicode". There
> is no PEP because it was introduced by BDFL pronouncement.

Unfortunately the lack of a PEP leaves this a bit underdocumented.

> That it is not a generic base class for stringish types can be
> seen by looking at UserString.UserString, which doesn't inherit
> from basestring.

Raymond Hettinger's reason for not wanting to add basestring as a  
base for UserString was: UserString is a legacy class, since today  
people can inherit from str directly, and it cannot be changed from a  
classic class to a new-style one without breaking backwards  
compatibility, which for a legacy class would be a big booboo.   
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).

> For most practical purposes, those two definitions actually
> define the same thing - there simply aren't any stringish data
> types in praxis: you always have Unicode, and if you don't,
> you have bytes.

But not necessarily in one big blob that's consecutive (==compact) in  
memory.  mmap instances are "almost" strings and could easily be made  
into a closer match, at least for the immutable variants, for  
example; other implementations such as SGI STL's "Rope" also come to  
mind.

In the context of a current struggle (a different and long story)  
between Python builds with 2-bytes Unicode and ones with 4-bytes  
Unicode, I've sometimes found myself dreaming of a string type that's  
GUARANTEED to be 2-bytes, say, and against which extension modules  
could be written that don't need recompilation to move among such  
different builds, for example.  It's not (yet) hurting enough to make  
me hunker down and write such an extension (presumably mostly by copy- 
past-edit from Python's own sources;-), but if somebody did it would  
sure be nice if they could have that type "assert it's a string" by  
inheriting from basestring, no?

>> Implementing different kinds of numbers is more likely than
>> implementing different kinds of strings, of course.
>
> Right. That's why a PEP is needed here, but not for basestring.

OK, I've mailed requesting a number.

>
>> A third argument against it is asymmetry: why should I use completely
>> different approaches to check if x is "some kind of string", vs
>> checking if x is "some kind of number"?
>
> I guess that's for practicality which beats purity. People often
> support interfaces that either accept both an individual string
> and a list of strings, and they need the test in that case.
> It would be most natural to look for whether it is a sequence;
> unfortunately, strings are also sequences.

Sure, isinstance-tests with basestring are a fast and handy way to  
typetest that.

But so would similar tests with basenumber be.

>
>> isinstance with a tuple of number types, where the tuple did not
>> include Decimal (because when I developed and tested that module,
>> Decimal wasn't around yet).
>
> 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".

As to why I want to distinguish numbers from non-numbers, let me  
quote from a message I sent in 2003 (one of the few you'll find by  
searching for [basestring site:python.org] as I have repeatedly  
recommended, but apparently there's no way to avoid just massively  
copying and pasting...):

"""
def __mul__(self, other):
 if isinstance(other, self.KnownNumberTypes):
 return self.__class__([ x*other for x in self.items ])
 else:
 # etc etc, various other multiplication cases

right now, that (class, actually) attribute KnownNumberTypes starts out
"knowing" about int, long, float, gmpy.mpz, etc, and may require user
customization (e.g by subclassing) if any other "kind of (scalar)  
number"
needs to be supported; besides, the isinstance check must walk linearly
down the tuple of known number types each time.  (I originally had
quite a different test structure:
 try: other + 0
 except TypeError:  # other is not a number
 # various other multiplication cases
 else:
 # other is a number, so...
 return self.__class__([ x*other for x in self.items ])
but the performance for typical benchmarks improved with the isinstance
test, so, reluctantly, that's 

Re: [Python-Dev] basenumber redux

[Guido van Rossum]

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 this with the
stated intent.* Maybe I didn't communicate that intent clearly. But my
intent was exactly as it is documented -- basestring == (str, unicode)
and nothing else.

Why this intent? Because I felt the need to be able to distinguish the
*built-in* string types from *anything* else; they have many special
properties and purposes.

Also note that basestring was introduced in 2.3, a whole release
*after* inheritance from str was made possible.
--
--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

[Python-Dev] str with base

[Alex Martelli]

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!-).  I'll be happy to propose a patch if the BDFL  
blesses this, but I don't even think it's worth a PEP... it's an  
inexplicable though long-standing omission (given the argumentative  
nature of this crowd I know I'll get pushback, but I still hope the  
BDFL can Pronounce about it anyway;-).


Alex

___
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] basenumber redux

[Raymond Hettinger]

> Because isinstance is faster and handier than testing with try/except
> around (say) "x+0".

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 fast slot lookup
otherwise), and a block end.

Even if there were a performance edge, I suppose that the type checking
is the time critical part of most scripts.



> If an abstract
> basetype
> 'basenumber' caught many useful cases, I'd put it right at the start
of
> the KnownNumberTypes tuple, omit all subclasses thereof from it, get
> better performance, AND be able to document very simply what the user
> must do to ensure his own custom type is known to me as "a number".

So, this would essentially become a required API?  It would no longer be
enough to duck-type a number, you would also have to subclass from
basenumber?

Wouldn't this preclude custom number types that also need to derive from
another builtin such as str?  For instance, somewhere I have
Gram-Schmidt orthogonalization transformation code for computing
orthonormal bases and the only requirement for the input basis is that
it be an inner-product space -- accordingly, the inputs can be
functions, symbols (a subclass of str), or vectors (pretty-much anything
supporting multiplication and subtraction).

Similar conflicts arise for any pure computation function -- I should be
able to supply either numbers or symbolic inputs (a subclass of str)
that act like numbers.



> in  Python/bltinmodule.c , function builtin_sum uses C-coded
> typechecking
> to single out strings as an error case:
> 
>   /* reject string values for 'start' parameter */
>   if (PyObject_TypeCheck(result, &PyBaseString_Type)) {
>   PyErr_SetString(PyExc_TypeError,
>   "sum() can't sum strings [use
''.join(seq) instea
> 
> [etc].  Now, what builtin_sum really "wants" to do is to accept
numbers,
> only -- it's _documented_ as being meant for "numbers": it uses +, NOT
> +=, so its performance on sequences, matrix and array-ish things, etc,
> is not going to be good.  But -- it can't easily _test_ whether
> something
> "is a number".  If we had a PyBaseNumber_Type to use here, it would
> be smooth, easy, and fast to check for it.
> """

I think this a really a counter-example.  We wanted to preclude
sequences so that sum() didn't become a low performance synonym for
''.join().  However, there's no reason to preclude user-defined matrix
or vector classes.

And, if you're suggesting that the type-check should have been written
with as instance(result, basenumber), one consequence would be that
existing number-like classes would start to fail unless retro-fitted
with a basenumber superclass.  Besides being a PITA, retro-fitting
existing, working code could also entail changing from an old to
new-style class (possibly changing the semantics of the class).


> A fast rational number type, see http://gmpy.sourceforge.net for
> details (gmpy wraps LGPL'd library GMP, and gets a lot of speed and
> functionality thereby).
> 
> > if the  parameter belongs to some algebraic ring homomorphic
> > with the real numbers, or some such. Are complex numbers also
numbers?
> > Is it meaningful to construct gmpy.mpqs out of them? What about
> > Z/nZ?
> 
> If I could easily detect "this is a number" about an argument x, I'd
> then ask x to change itself into a float, so complex would be easily
> rejected (while decimals would mostly work fine, although a bit
> slowly without some specialcasing, due to the Stern-Brocot-tree
> algorithm I use to build gmpy.mpq's from floats).  I can't JUST ask x
> to "make itself into a float" (without checking for x's "being a
> number") because that would wrongfully succeed for many cases such as
> strings.

Part of the rationale for basestring was convenience of writing
isinstance(x,basestring) instead of isinstance(x,(str,unicode)).  No
existing code needed to be changed for this to work.

This proposal, on the other hand, is different.  To get the purported
benefits, everyone has to play along.  All existing number-look-a-like
classes would have to be changed in order to work with functions testing
for basenumber.

That would be too bad for existing, work code.  Likewise, it would be
impossible for symbolic code which already subclassed from str (as
discussed above).


> >> If I do write the PEP, should it be just about basenumber, or
should
> >> it include baseinteger as well?


Introducing a baseinteger type is likely to create confusion because all
integers are real, but baseintegers are not a subclass of floats.

I don't see a way around creating an integer recognition tool that
doesn't conflate its terminology with broadly-held, pre-existing math
knowledge: complex is a superset of reals, reals include rationals and
irrationals s

Re: [Python-Dev] str with base

[Brett Cannon]

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 --
> any bright beginner assumes it's there and it's awkward to explain
> why it's not!-).  I'll be happy to propose a patch if the BDFL
> blesses this, but I don't even think it's worth a PEP... it's an
> inexplicable though long-standing omission (given the argumentative
> nature of this crowd I know I'll get pushback, but I still hope the
> BDFL can Pronounce about it anyway;-).
>

I'm +0.  Not a big thing for me, but having the symmetry seems reasonable.

-Brett
___
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]

> 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
___
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] basenumber redux

[Raymond Hettinger]

[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
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

[Jeremy Hylton]

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 that I wasn't all that bright as a beginner <0.5
wink>.

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().  It would be fine to have a function for this
hiding somewhere, perhaps even as a method on numbers, but str() is
too generic.

Jeremy

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)
> 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!-).  I'll be happy to propose a patch if the BDFL
> blesses this, but I don't even think it's worth a PEP... it's an
> inexplicable though long-standing omission (given the argumentative
> nature of this crowd I know I'll get pushback, but I still hope the
> BDFL can Pronounce about it anyway;-).
>
>
> Alex
>
> ___
> 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

[Guido van Rossum]

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 --
> any bright beginner assumes it's there and it's awkward to explain
> why it's not!-).  I'll be happy to propose a patch if the BDFL
> blesses this, but I don't even think it's worth a PEP... it's an
> inexplicable though long-standing omission (given the argumentative
> nature of this crowd I know I'll get pushback, but I still hope the
> BDFL can Pronounce about it anyway;-).

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
notoriously asymmetric in Python" and "because nobody submitted a
patch". :-)

There are some corner cases to consider though.

- Should repr() support the same convention? I think not.
- Should str(3.1, n) be allowed? I think not.
- Should str(x, n) call x.__str__(n)? Neither.
- Should bases other than 2..36 be considered? I don't think so.

Unfortunately this doesn't obsolete oct() and hex() -- oct(10) returns
'012', while str(10, 8) soulc return '12'; hex(10) returns '0xa' while
str(10, 16) would return 'a'.

I do think that before we add this end-user nicety, it's more
important to implement __index__() in Python 2.5. This behaves like
__int__() for integral types, but is not defined for float or Decimal.
Operations that intrinsically require an integral argument, like
indexing and slicing, should call __index__() on their argument rather
than __int__(), so as to support non-built-in integral arguments while
still complaining about float arguments. This is currently implemented
by explicitly checking for float in a few places, which I find
repulsing. __index__() won't be requested by bright beginners, but it
is important e.g. to the Numeric Python folks, who like to implement
their own integral types but are suffering from that their integers
aren't usable everywhere.

--
--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

[Andrew Bennetts]

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, and why it
should give '101'.

If you'd proposed, say (5).as_binary() == '101', or "5".encode("base2"), I
wouldn't have been as baffled.  Or perhaps even str(5, base=2), but frankly the
idea of the string type doing numeric base conversions seems weird to me, rather
than symmetric.

I wouldn't mind seeing arbitrary base encoding of integers included somewhere,
but as a method of str -- let alone the constructor! -- it feels quite wrong.

-Andrew.

___
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]

> 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
> notoriously asymmetric in Python" and "because nobody submitted a
> patch". :-)

My reason is that I've rolled-my-own more times than I can count but
infrequently enough to where it was easier to re-write than to search
for the previous use.

Another quick thought:  I presume that only the str() builtin would
change and that the underlying __str__ slot would continue to be
hard-wired to the (reprfunc) signature.


Raymond

___
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

[Jean-Paul Calderone]

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 assumes it's there and it's awkward to explain
>why it's not!-).  I'll be happy to propose a patch if the BDFL
>blesses this, but I don't even think it's worth a PEP... it's an
>inexplicable though long-standing omission (given the argumentative
>nature of this crowd I know I'll get pushback, but I still hope the
>BDFL can Pronounce about it anyway;-).
>

-1.  Confusing and non-obvious.  The functionality may be valuable but 
it is mis-placed as a feature of str() or a method of the str type.  I 
work with a lot of Python beginners too, and while they occassionally 
ask for this functionality, I've never heard anyone wonder why str() 
didn't provide it or suggest that it should.

Jean-Paul
___
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

[Barry Warsaw]

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 "5".encode("base2"), I
> wouldn't have been as baffled.  Or perhaps even str(5, base=2), but frankly 
> the
> idea of the string type doing numeric base conversions seems weird to me, 
> rather
> than symmetric.
> 
> I wouldn't mind seeing arbitrary base encoding of integers included somewhere,
> but as a method of str -- let alone the constructor! -- it feels quite wrong.

Hear, hear.  I was similarly perplexed when I first read that!

-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

Re: [Python-Dev] str with base

[Alex Martelli]

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? str([1, 2], 4) doesn't make any sense.
> You might argue that I wasn't all that bright as a beginner <0.5
> wink>.
>
> 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 for int: the base argument is only  
accepted if the first argument is a str (not a float, etc).  Just the  
same way, the base argument to str will only be accepted if the first  
argument is an int (not a float, etc).


Alex

___
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

[Jeremy Hylton]

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 for int: the base argument is only
> accepted if the first argument is a str (not a float, etc).  Just the
> same way, the base argument to str will only be accepted if the first
> argument is an int (not a float, etc).

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
limited set of types, in the other case it applies to every
conceivable type (except int).

If str() were to take two argument, the analogy with int suggests it
should be an encoding, where the second argument describes how to
interpret the representation of the first (it's base 7 or it's utf-8).

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

[Bob Ippolito]

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 you'd proposed, say (5).as_binary() == '101', or "5".encode 
>> ("base2"), I
>> wouldn't have been as baffled.  Or perhaps even str(5, base=2),  
>> but frankly the
>> idea of the string type doing numeric base conversions seems weird  
>> to me, rather
>> than symmetric.
>>
>> I wouldn't mind seeing arbitrary base encoding of integers  
>> included somewhere,
>> but as a method of str -- let alone the constructor! -- it feels  
>> quite wrong.
>
> Hear, hear.  I was similarly perplexed when I first read that!

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 probably "b".

For example:

 >>> '%08b' % (12)
'1100'
 >>> '%b' % (12)
'1100'

I'd probably expect "5".encode("base2") to return '00110101', because  
"5".encode("hex") returns '35'

-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

[Raymond Hettinger]

[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
> limited set of types, in the other case it applies to every
> conceivable type (except int).


That suggests that it would be better to simply add an int method:

 x.convert_to_base(7)


Raymond

___
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

[Andrew Bennetts]

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 trouble using it or finding it.

-Andrew.

___
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

[Bob Ippolito]

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  
> the "bright
> beginners" Alex is interested in would have no trouble using it or  
> finding it.

I don't know about that, all of the methods that int and long  
currently have are __special__.  They'd really need to start with  
Python 2.5 (assuming int/long grow "public methods" in 2.5) to even  
think to look there.  A format code or a built-in would be more  
likely to be found, since that's how you convert integers to hex and  
oct string representations with current Python.

 >>> [name for name in dir(0)+dir(0L) if not name.startswith('__')]
[]

-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

[Andrew Bennetts]

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  
> >finding it.
> 
> I don't know about that, all of the methods that int and long  
> currently have are __special__.  They'd really need to start with  
> Python 2.5 (assuming int/long grow "public methods" in 2.5) to even  
> think to look there.  A format code or a built-in would be more  
> likely to be found, since that's how you convert integers to hex and  
> oct string representations with current Python.
> 
> >>> [name for name in dir(0)+dir(0L) if not name.startswith('__')]
> []

I should have said, I'm equally happy with the format code as well (although it
doesn't allow arbitary base conversions, I've never had need for that, so I'm
not too worried about that case).  Either option is better than making the str
constructor do relatively rarely used mathematics!

-Andrew.

___
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

[Barry Warsaw]

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 probably "b".
> 
> For example:
> 
>  >>> '%08b' % (12)
> '1100'
>  >>> '%b' % (12)
> '1100'

+1

-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

Re: [Python-Dev] str with base

[Brett Cannon]

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?  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!-).  I'll be happy to propose a patch if the BDFL
> > blesses this, but I don't even think it's worth a PEP... it's an
> > inexplicable though long-standing omission (given the argumentative
> > nature of this crowd I know I'll get pushback, but I still hope the
> > BDFL can Pronounce about it anyway;-).
>
> 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
> notoriously asymmetric in Python" and "because nobody submitted a
> patch". :-)
>
> There are some corner cases to consider though.
>
> - Should repr() support the same convention? I think not.
> - Should str(3.1, n) be allowed? I think not.
> - Should str(x, n) call x.__str__(n)? Neither.
> - Should bases other than 2..36 be considered? I don't think so.
>
> Unfortunately this doesn't obsolete oct() and hex() -- oct(10) returns
> '012', while str(10, 8) soulc return '12'; hex(10) returns '0xa' while
> str(10, 16) would return 'a'.
>
> I do think that before we add this end-user nicety, it's more
> important to implement __index__() in Python 2.5. This behaves like
> __int__() for integral types, but is not defined for float or Decimal.
> Operations that intrinsically require an integral argument, like
> indexing and slicing, should call __index__() on their argument rather
> than __int__(), so as to support non-built-in integral arguments while
> still complaining about float arguments. This is currently implemented
> by explicitly checking for float in a few places, which I find
> repulsing. __index__() won't be requested by bright beginners, but it
> is important e.g. to the Numeric Python folks, who like to implement
> their own integral types but are suffering from that their integers
> aren't usable everywhere.
>

+1 from me (feel like this has come up before, but not totally sure). 
Be nice to add an abstraction for indexing.

Added to the PyCon wiki as a possible sprint topic.

-Brett
___
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] basenumber redux

[Martin v. Löwis]

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, and then expect TypeErrors from doing so.

> As to why I want to distinguish numbers from non-numbers, let me  quote
> from a message I sent in 2003 (one of the few you'll find by  searching
> for [basestring site:python.org] as I have repeatedly  recommended, but
> apparently there's no way to avoid just massively  copying and pasting...):

As I said in that other message, I found this one, and still don't
understand what the use case is, because the example you give still
reads hypothetical (I'm sure there is an actual example behind it, but
you don't say what that is).

> """
> def __mul__(self, other):
> if isinstance(other, self.KnownNumberTypes):
> return self.__class__([ x*other for x in self.items ])
> else:
> # etc etc, various other multiplication cases

So what *are* the "various other multiplication cases"?

You just shouldn't be doing that: multiplication shouldn't mean
"item multiplication" sometimes, and various other things if it
can't mean item multiplication.

> in  Python/bltinmodule.c , function builtin_sum uses C-coded  typechecking
> to single out strings as an error case:
> 
> /* reject string values for 'start' parameter */
> if (PyObject_TypeCheck(result, &PyBaseString_Type)) {
> PyErr_SetString(PyExc_TypeError,
> "sum() can't sum strings [use ''.join(seq) instea

This is indeed confusing: why is it again that sum refuses to sum
up strings?

> [etc].  Now, what builtin_sum really "wants" to do is to accept numbers,
> only -- it's _documented_ as being meant for "numbers": it uses +, NOT
> +=, so its performance on sequences, matrix and array-ish things, etc,
> is not going to be good.  But -- it can't easily _test_ whether  something
> "is a number".  If we had a PyBaseNumber_Type to use here, it would
> be smooth, easy, and fast to check for it.

There shouldn't be a check at all. It should just start doing the
summing, and it will "work" if PyNumber_Add works for the individual
items. Of course, there is an education value of ruling out string
addition, since there is a better way to do that, and there should
be only one obvious way.

I see nothing wrong in summing up sequences, matrices, and arrayish
things, using sum.

> A fast rational number type, see http://gmpy.sourceforge.net for 
> details (gmpy wraps LGPL'd library GMP, and gets a lot of speed and 
> functionality thereby).

Ok, so mpq are rational numbers.

>> if the  parameter belongs to some algebraic ring homomorphic
>> with the real numbers, or some such. Are complex numbers also numbers?
>> Is it meaningful to construct gmpy.mpqs out of them? What about
>> Z/nZ?
> 
> 
> If I could easily detect "this is a number" about an argument x, I'd 
> then ask x to change itself into a float, so complex would be easily 
> rejected (while decimals would mostly work fine, although a bit  slowly
> without some specialcasing, due to the Stern-Brocot-tree  algorithm I
> use to build gmpy.mpq's from floats).  I can't JUST ask x  to "make
> itself into a float" (without checking for x's "being a  number")
> because that would wrongfully succeed for many cases such as  strings.

Hmm. If you want to do the generic conversion from numbers to rationals
by going through float, then this is what you should do. Convert to
float, and don't bother with checking whether it will succeed. Instead,
if the type conversion gives an error, just return that to the caller.

However, it also sounds odd that you are trying to do the
to-rational-with-arbitrary-precision conversion by going through
floats. Instead, if the argument is decimal, you really should
do the division by the approprate base of 10, no?

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

[Brett Cannon]

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 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
> > finding it.
>
> I don't know about that, all of the methods that int and long
> currently have are __special__.  They'd really need to start with
> Python 2.5 (assuming int/long grow "public methods" in 2.5) to even
> think to look there.  A format code or a built-in would be more
> likely to be found, since that's how you convert integers to hex and
> oct string representations with current Python.
>
>  >>> [name for name in dir(0)+dir(0L) if not name.startswith('__')]

If a method is the best solution, then fine, 2.5 is the beginning of
methods on int/long.  We could do a static method like
int.from_str("101", 2) and str.from_int(5, 2) if people don't like the
overloading of the constructors.  Otherwise add methods like
'101'.to_int(2) or 5 .to_str(2) .

-Brett
___
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] basenumber redux

[Martin v. Löwis]

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 fast slot lookup
> otherwise), and a block end.
> 
> Even if there were a performance edge, I suppose that the type checking
> is the time critical part of most scripts.

My guess is that it depends on the common case. If the common case is
that the type test fails (i.e. element-wise operations are the
exception), then you also have the exception creation and storing
in the exception approach, compared to returning only existing objects
in the type test case. If the common case is that x+0 succeeds, x+0
may or may not create new objects.

However, I have long ago learned not to guess about performance, so
I won't do further guessing until I see the actual code.

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