I'm getting a compiler warning from your checkin:
C:\py25\Objects\floatobject.c(1430) : warning C4244: 'initializing' :
conversion from 'double ' to 'float ', possible loss of data
There are some very serious problems with threads today. Events are
often proposed as a solution to these problems, but they have their own
issues. A detailed analysis of the two options and some solutions
(most of which are used in my proposal) can be found in Why Events Are
A Bad Idea [0]. I'm going to skip the event aspects and sum up the
thread problems here:
* Expensive (resident memory, address space, time to create and to
switch between)
* Finely-grained atomicity (python is coarser than C, but still finer
than we need)
* Unpredictable (switching between them is not deterministic)
* Uninterruptible (no way to kill them, instead you must set a flag and
make sure they check it regularly)
* Fail silently (if they die with an exception it gets printed to the
console but the rest of the program is left uninformed)
To resolve these problems I propose adding lightweight cooperative
threads to Python. They can be built around a Frame object, suspending
and resuming like generators do.
That much is quite easy. Avoiding the C stack is a bit harder.
However, it can be done if we introduce a new operator for threaded
calls (which I refer to as non-atomic calls), which I propose be
"func@()". As a bonus this prevents any operation which doesn't use
the non-atomic call syntax from triggering a thread switch accidentally.
After that you need a way of creating new threads. I propose we use a
"sibling func@()" statement (note that the "@()" would be parsed as
part of the statement itself, and not as an expression). It would
create a new thread and run func in it, but more importantly it would
also "prejoin" the new thread to the current function. This means that
for the current function to return to its parent, all of the threads it
created must first return themselves. It also means that an exception
in any of them will be propagated to the parent of the creator, after
interrupting all of its siblings (with an Interrupted exception) so
that it is permitted to return.
Now for an example of how this would work in practice, using an echo
server. Note that I am assuming a "con" module (short for concurrent)
that would contain standard functions to support these python-native
threads.
from con import bootstrap, tcplisten, ipv6addr, ipv4addr
def main():
main_s = tcplisten@(ipv6addr('::1', 6839), ipv4addr('127.0.0.1', 6839))
while 1:
sibling echo@(main_s.accept@())
def echo(s):
try:
try:
while 1:
s.write@(s.read@())
except (EOFError, IOError):
pass
finally:
s.close()
if __name__ == '__main__':
try:
bootstrap(main)
except KeyboardInterrupt:
pass
And here is a diagram of the resulting cactus stack, assuming three
clients, two of which are reading and the other is writing.
bootstrap - main - accept
|
echo - read
|
echo - read
|
echo - write
Some notes:
* An idle@() function would be used for all thread switches. I/O
functions such as read@() and write@() would use it internally, and
idle would internally call a function to do poll() on all file
descriptors.
* idle is the function that will raise Interrupted
* It should be illegal to attempt a non-atomic call once your thread is
in an interrupted state. This ensures you cannot get "interrupted
twice", by having something further up the call stack fail and
interrupt you while you are already handling an interruption.
* Being a cooperative system, it does not allow you to use multiple
CPUs simultaneously. I don't regard this as a significant problem,
and in any case there are better ways use multiple CPUs if you need to.
References:
[0] http://www.usenix.org/events/hotos03/tech/full_papers/vonbehren/vonbehren_h…
--
Adam Olsen, aka Rhamphoryncus
Fredrik Johansson writes:
> In either case, compatibility can be ensured by allowing both n-digit
> decimal and hardware binary precision for floats, settable via a float
> context.
Perhaps you can show me a design (or working code) that proves me
wrong, but I don't believe that such a design could be made compatible
with the existing Decimal module... certainly while continuing to
maintain compatibility with the Cowlinshaw specification.
> There is the alternative of providing decimal literals by using
> separate decimal and binary float base types
If, by this, you mean adding a "binary float context" modeled after
the Decimal float context and providing access to the underlying FP
flags and traps and generally enhancing the use of binary FP, then
I think it's a great idea. It's probably impossible to write in a
cross-platform manner (because C supplies support for binary FP but
does not offer access to the flags and traps), but this is one of those
few cases where it's worth using platform-and-compiler specific code.
Of course, someone still has to step forward and offer to code it.
-- Michael Chermside
Maybe this has already been answered somewhere (although I don't recall
seeing it, and it's not in the sourceforge tracker) but has anyone asked
Jason Orendorff what his opinion about this (including the module in the
stdlib) is?
If someone has, or if he posted it somewhere other than here, could someone
provide a link to it?
=Tony.Meyer
Hello,
I'm using Python for about 2 years, and I would like to go further in
python developement. So that's why I've subscribed to python-dev. And
since I'm not very good in C, I think I will try to help and to submit
patchs in pure python.
--
Fabien SCHWOB (and sorry for my english but it's not my mother tongue)
Hi all,
Please CC: me on any replies as I am not subscribed to this list. I
am the lead maintainer for the ntlmaps project
(http://ntlmaps.sourceforge.net). Recently a bugreport logged against
ntlmaps has brought an issue to my attention (see:
https://sourceforge.net/tracker/index.php?func=detail&aid=1224877&group_id=…). The getpass() function in module getpass does not accept extended characters on Windows. On Windows, the getpass() source uses the msvcrt module to capture one character at a time from stdin via the _getch() function defined in conio.h. Microsoft support capturing extended characters via _getch (see: http://support.microsoft.com/default.aspx?scid=kb;en-us;57888), but it requires making a second call to getch() if one of the 'magic' returns is encountered in the first call (0x00 or 0xE0).
The relevant chunk of code in Python that would probably need to be
changed to support this appears to be in msvcrtmodule.c:
static PyObject *
msvcrt_getch(PyObject *self, PyObject *args)
{
int ch;
char s[1];
if (!PyArg_ParseTuple(args, ":getch"))
return NULL;
Py_BEGIN_ALLOW_THREADS
ch = _getch();
Py_END_ALLOW_THREADS
s[0] = ch;
return PyString_FromStringAndSize(s, 1);
}
It would seem that it could be made to support extended characters by changing it to:
static PyObject *
msvcrt_getch(PyObject *self, PyObject *args)
{
int ch;
char s[1];
if (!PyArg_ParseTuple(args, ":getch"))
return NULL;
Py_BEGIN_ALLOW_THREADS
ch = _getch();
+ if (ch == 0x00 || ch == 0XE0)
+ ch = _getch();
Py_END_ALLOW_THREADS
s[0] = ch;
return PyString_FromStringAndSize(s, 1);
}
I haven't yet read the code for PyString_FromStringAndSize(), but presumably it can coerce unicode/extended results out of the int (or could be made to)?
What are the chances of modifying msvcrt_getch() to support extended chars?
The unix_getpass() seems to already work OK with extended characters, so this would ~seem~ to be a logical extension to the Windows version.
Thoughts?
--
Darryl Dixon <esrever_otua(a)pythonhacker.is-a-geek.net>
Hi, all,
I just made an initial Python binding for SWT library from IBM's Eclipse
project using GCJ + SIP. you can find some information here:
http://www.cs.nyu.edu/zilin/pyswt/pmwiki.php
The basic idea is as follows:
1. use GCJ compile SWT source codes
2. use gcjh to generate C++ header files for SWT
3. I modified SIP's code generator to generate C++ wrapper codes.
It is still in very early stage, but most widgets are usable now. Hope
I can get more time work on this.
Weclome any feedbacks, and feel free to forward this annocement to
any place you want@
thanks!
Zilin
> From: Guido van Rossum [mailto:gvanrossum@gmail.com]
>
> >>> datetime.datetime.utcfromtimestamp(time.time()) - datetime.datetime.utcnow()
> datetime.timedelta(0)
I overlooked the utcfromtimestamp method, sorry.
> Your bug is similar to comparing centimeters to inches, or speed to
> acceleration, or any number of similar mistakes.
Quite so, and that is exactly the point. time.time() unambiguously
identifies a point in time. A datetime object does not. At least not
unless a tzinfo object is included, and even then there is a corner
case at the end of DST that cannot possibly be handled.
If ctime/mtime/atime were to return datetime objects, that would
pretty much have to be UTC to not lose information in the DST
transition. I doubt that's what Walter wanted though, as that would
leave users with the job of converting from UTC datetime to local
datetime; - unless perhaps I've overlooked a convenient UTC->local
conversion method?
- Anders
> I wrote:
>
> > Alas datetime objects do not unambiguously identify a point in time.
> > datetime objects are not timestamps: They represent the related but
> > different concept of _local time_, which can be good for
> presentation,
> > but shouldn't be allowed anywhere near a persistent store.
>
GvR replied:
> You misunderstand the datetime module! You can have a datetime object
> whose timezone is UTC; or you can have a convention in your API that
> datetime objects without timezone represent UTC.
I can do a lot of things in my own code, and I'm sure the datetime
module provides tools that I can build on to do so, but that doesn't
help in interfacing with other people's code -- such as the standard
library.
Try saving a pickle of datetime.now() and reading it on a computer set
to a different time zone. The repr will then show the local time on
the _originating_ computer, and figuring out the absolute time this
corresponds to requires knowledge of time zone and DST settings on the
originating computer.
How about datetime.utcnow(), then? Just use UTC for datetime
timestamps? But that goes against the grain of the datetime module:
Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime, time
>>> datetime.datetime.fromtimestamp(time.time()) - datetime.datetime.now()
datetime.timedelta(0)
>>> datetime.datetime.fromtimestamp(time.time()) - datetime.datetime.utcnow()
datetime.timedelta(0, 7200)
It seems when I subtract the present time from the present time,
there's a two hour difference.
- Anders