[Python-Dev] Unifying decimal numbers.

[winlinchu]

Now, Python unified ints and long ints.
For Python 3k, could be introduced a "Decimal" type
(yes, Decimal, the library module!) in place of the
actual float object. Of course, the Decimal type would
be rewritten in C.

Thanks.



___ 
Yahoo! Messenger: chiamate gratuite in tutto il mondo 
http://it.messenger.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

[Python-Dev] For Python 3k, drop default/implicit hash, and comparison

[Technical Support of Intercable Co]

Why 'identity' objects can't define:
def __getKey__(self):
 return Key(self, id(self))
Then they would act as usually, while value object can define
def __getKey__(self):
 return Key(self, self.i, self.j, self.a[1])

(Key is an abstraction to handle subclassing)

Of course, there should be a way to handle comparison off the class 
ierarhy (i think)
Today one can write:
 >>> class Boo(object):
def __init__(self,s=""):
   self.s=s
def __hash__(self):
   return hash(self.s)
def __cmp__(self,other):
   if type(self)==type(other):
  return cmp(self.s,other.s)
   if type(other)==str:
  return cmp(self.s,other)
 >>> a={}
 >>> a['s']=1
 >>> a[Boo('s')]
1
 >>> a[Boo('z')]=2
 >>> a['z']
2
It is confused and hardly usefull, but possible.

Excuse my english.

___
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] Unifying decimal numbers.

[Josiah Carlson]

winlinchu <[EMAIL PROTECTED]> wrote:
> Now, Python unified ints and long ints.
> For Python 3k, could be introduced a "Decimal" type
> (yes, Decimal, the library module!) in place of the
> actual float object. Of course, the Decimal type would
> be rewritten in C.

There is code which relies on standard IEEE 754 floating point math
(speed, behavior, rounding, etc.) that would break with the replacement
of floats with decimals.  Further, even if it were to be converted to C,
it would likely be hundreds of times slower than the processor-native
float operations.

This discussion has been had before use:
site:mail.python.org decimal replace float python
in google to discover such discussions.  For example:
http://mail.python.org/pipermail/python-dev/2005-June/054416.html


 - Josiah

___
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] Event loops, PyOS_InputHook, and Tkinter

[Michiel Jan Laurens de Hoon]

Dear Pythoneers,

I use Python heavily for scientific computing, originally for 
computational physics and nowadays for computational biology. One of the 
extension modules I support is pygist, a module for scientific 
visualization. For this (and similar) packages to work, it is important 
to have an event loop in Python.

Currently, event loops are available in Python via PyOS_InputHook, a 
pointer to a user-defined function that is called when Python is idle 
(waiting for user input). However, an event loop using PyOS_InputHook 
has some inherent limitations, so I am thinking about how to improve 
event loop support in Python.

As an example, consider the current implementation of Tkinter. What's 
nice about it is that events as well as user-typed Python commands are 
handled without having to call mainloop() explicitly (except on some 
platforms):
"import Tkinter; Tkinter.Tk()" causes a Tk window to pop up that remains 
responsive throughout. It works as follows (using Tkinter as an example; 
pygist works essentially the same):

1) Importing Tkinter causes PyOS_InputHook to be set to the EventHook 
function in _tkinter.c.
2) Before Python calls fgets to read the next Python command typed by 
the user, it checks PyOS_InputHook and calls it if it is not NULL.
3) The EventHook function in _tkinter runs the following loop:
 - Check if user input is present; if so, exit the loop
 - Handle a Tcl/Tk event, if present
 - Sleep for 20 milliseconds
4) Once the EventHook function returns, Python continues to read the 
next user command. After executing the command, return to 2).

However, this implementation has the following problems:
1) Essentially, the event loop is a busy-wait loop with a 20 ms sleep in 
between. An event loop using select() (or equivalent on Windows) will 
give better performance.
2) Since this event loop runs inside Tkinter, there is no way for other 
extension modules to get their messages handled. Hence, we cannot have 
more than one extension module that needs an event loop. As an example, 
it would be nice to have a Tkinter GUI to steer a simulation and a 
(non-Tk) graphics output window to visualize the simulation.
3) Whereas PyOS_InputHook is called when Python is waiting for user 
input, it is not called when Python is waiting for anything else, for 
example one thread waiting for another. For example, IDLE uses two 
threads, one handling the GUI and one handling the user commands. When 
the second thread is waiting for the first thread (when waiting for user 
input to become available), PyOS_InputHook is not being called, and no 
Tkinter events are being handled. Hence, "import Tkinter; Tkinter.Tk()" 
does nothing when executed from an IDLE window. Which means that our 
scientific visualization software can only be run from Python started 
from the command line, whereas many users (especially on Windows) will 
want to use IDLE.

Now the problem I'm facing is that because of its integration with Tcl, 
this cannot be fixed easily with Tkinter as the GUI toolkit for Python. 
If the events to be handled were purely graphical events (move a window, 
repaint a window, etc.), there would be no harm in handling these events 
when waiting for e.g. another thread. With Tkinter, however, we cannot 
enter EventHook while waiting for another thread:
a) because EventHook only returns if user input is available (it doesn't 
wait for threads);
b) because EventHook also runs Tcl/Tk commands, and we wouldn't want to 
run some Tcl commands in some thread while waiting for another thread.

Therefore, as far as I can tell, there is no way to set up a true event 
loop in Python that works nicely with Tkinter, and there is no way to 
have an event loop function from IDLE.

So I'd like to ask the following questions:
1) Did I miss something? Is there some way to get an event loop with 
Tkinter?
2) Will Tkinter always be the standard toolkit for Python, or are there 
plans to replace it at some point?

I realize that Tkinter has been an important part of Python for some 
time now, and I don't expect it to be ditched just because of my event 
loop problems. At the same time, event loop support could use some 
improvement, so I'd like to call your attention to this issue. Tcl 
actually has event loops implemented quite nicely, and may serve as an 
example of how event loops may work in Python.

--Michiel.

-- 
Michiel de Hoon
Center for Computational Biology and Bioinformatics
Columbia University
1150 St Nicholas Avenue
New York, NY 10032


___
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] Unifying decimal numbers.

[Bill Janssen]

Might be more interesting to think about replacing ints and Decimal
with implicit-denominator rational type.  In the HTTP-NG typing
proposal, we called this a "fixed-point" type.  See Section 4.5.1 of
http://www.w3.org/Protocols/HTTP-NG/1998/08/draft-frystyk-httpng-arch-00.txt
for details.

The current notion of "int" would be defined as a specific kind of
fixed-point type (a denominator of 1), but other fixed-point types
such as dollars (denominator of 100) or dozens (denominator of 1/12)
could also be defined.  The nice thing about type systems like this is
that they can accurately describe non-binary values, like 1/3.

Bill
___
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] Event loops, PyOS_InputHook, and Tkinter

[Martin v. Löwis]

Michiel Jan Laurens de Hoon wrote:
> 1) Did I miss something? Is there some way to get an event loop with 
> Tkinter?

Yes, and yes. You are missing multi-threading, which is the widely used
approach to doing things simultaneously in a single process. In one
thread, user interaction can occur; in another, computation. If you need
non-blocking interaction between the threads, use queues, or other
global variables. If you have other event sources, deal with them
in separate threads.

Yes, it is possible to get event loops with Tkinter. Atleast on Unix,
you can install a file handler into the Tk event loop (through
createfilehandler), which gives you callbacks whenever there is some
activity on the files.

Furthermore, it is possible to turn the event loop around, by doing
dooneevent explicitly.

In principle, it would also be possible to expose Tcl events and
notifications in Tkinter (i.e. the
Tcl_CreateEventSource/Tcl_WaitForEvent family of APIs). If you think
this would help in your case, then contributions are welcome.

> 2) Will Tkinter always be the standard toolkit for Python, or are there 
> plans to replace it at some point?

Python does not evolve along a grand master plan. Instead, individual
contributors propose specific modifications, e.g. through PEPs.

I personally have no plan to replace Tkinter.

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] PEP submission broken?

[David Goodger]

[Bryan Olson]
> Though I tried to submit a (pre-) PEP in the proper form through the
> proper channels, it has disappeared into the ether.

Indeed, it has; I can't find it in my mailbox.  Could you re-send the
latest text?  I'll review it right away.

> From what I can tell, We need to address fixing the
> PEP process before there is any point in working on PEP's,

Email is imperfect; just send it again.

And "[EMAIL PROTECTED]" doesn't help ;-)

--
David Goodger 


signature.asc
Description: OpenPGP digital signature
___
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 submission broken?

[David Goodger]

[Nick Coghlan]
> Would it be worth having a PEP category on the RFE tracker, rather than
> submitting pre-PEP's directly to the PEP editors?

Couldn't hurt.

--
David Goodger 


signature.asc
Description: OpenPGP digital signature
___
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] Inconsistent behaviour in import/zipimport hooks

[Osvaldo Santana Neto]

Hi,

I'm working on Python[1] port for Maemo Platform[2] and I've found a
inconsistent behavior in zipimport and import hook with '.pyc' and
'.pyo' files. The shell section below show this problem using a
'module_c.pyc', 'module_o.pyo' and 'modules.zip' (with module_c and
module_o inside):

$ ls
module_c.pyc  module_o.pyo  modules.zip

$ python
>>> import module_c
>>> import module_o
ImportError: No module named module_o

$ python -O
>>> import module_c
ImportError: No module named module_c
>>> import module_o

$ rm *.pyc *.pyo
$ PYTHONPATH=modules.zip python
>>> import module_c
module_c
>>> import module_o
module_o

$ PYTHONPATH=modules.zip python -O
>>> import module_c
module_c
>>> import module_o
module_o

I've create a patch suggestion to remove this inconsistency[3] (*I* think
zipimport behaviour is better).

[1] http://pymaemo.sf.net/
[2] http://www.maemo.org/
[3] http://python.org/sf/1346572

-- 
Osvaldo Santana Neto (aCiDBaSe)
icq, url = (11287184, "http://www.pythonbrasil.com.br";)
___
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] Inconsistent behaviour in import/zipimport hooks

[Guido van Rossum]

You didn't show us what's in the zip file.  Can you show a zipinfo output?

My intention with import was always that without -O, *.pyo files are
entirely ignored; and with -O, *.pyc files are entirely ignored.

It sounds like you're saying that you want to change this so that .pyc
and .pyo are always honored (with .pyc preferred if -O is not present
and .pyo preferred if -O is present). I'm not sure that I like that
better. If that's how zipimport works, I think it's broken!

--Guido

On 11/8/05, Osvaldo Santana Neto <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm working on Python[1] port for Maemo Platform[2] and I've found a
> inconsistent behavior in zipimport and import hook with '.pyc' and
> '.pyo' files. The shell section below show this problem using a
> 'module_c.pyc', 'module_o.pyo' and 'modules.zip' (with module_c and
> module_o inside):
>
> $ ls
> module_c.pyc  module_o.pyo  modules.zip
>
> $ python
> >>> import module_c
> >>> import module_o
> ImportError: No module named module_o
>
> $ python -O
> >>> import module_c
> ImportError: No module named module_c
> >>> import module_o
>
> $ rm *.pyc *.pyo
> $ PYTHONPATH=modules.zip python
> >>> import module_c
> module_c
> >>> import module_o
> module_o
>
> $ PYTHONPATH=modules.zip python -O
> >>> import module_c
> module_c
> >>> import module_o
> module_o
>
> I've create a patch suggestion to remove this inconsistency[3] (*I* think
> zipimport behaviour is better).
>
> [1] http://pymaemo.sf.net/
> [2] http://www.maemo.org/
> [3] http://python.org/sf/1346572
>
> --
> Osvaldo Santana Neto (aCiDBaSe)
> icq, url = (11287184, "http://www.pythonbrasil.com.br";)
> ___
> 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/guido%40python.org
>


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