Ok, seems like we have @decorators. It's a nice tribute to Intercal. But
I'd prefer #decorators.
We have metaclasses for pleasure brain-melting. We have generators,
new-style classes and old-style classes. Lambdas are wonderful.
We do need real interfaces, not abused classes. Python still needs to have
inlined functions, macros and templates. Operator overloading is not enough,
one should be able to introduce new ones freely. There's a heavy demand for
terciary comparisons. Why don't we have a 'case' statement and 'do... repeat
()'?
We cannot do without general closures, of course. Hm, automatic garbage
collection is sometimes fine but explicite memory allocation/deallocation is
really unavoidable for efficient programs.
Wait, pointers are a must! Static typing should have been introduced a long
time ago. You just cannot do without absolute address variables.
Yes, I'm thorougly annoyed with creeping featurism.
Miklós
Jul 18 '05
65  3047 
Jarek Zgoda wrote: G. S. Hayes <sj*******@yahoo.com> pisze:
What really hurts is that I can't honestly tell Java programmers that
Python is a slam dunk compared to Java & the JVM. Java has no GIL,
Java has drunk the threads Kool-Aid, and Java programmers are very
likely to be thread-crazy because of the lack of a select equivalent
(until recently) and the lack of good access to processes via fork or
similar. Luckily, it's usually pretty easy to convince people of the
benefits of NOT overusing threads once they've made that mistake once.
Try GUI programming without using threads.
I've done this plenty of times. Threads seem to only be essential when
long-running background tasks are involved. There's a large set of GUI
programs where this is not an issue. I've also never had GIL problems
with multithreaded GUI apps. Then again, I'm not writing for
multiprocessor machines.
As I understand it, the GIL only becomes a real "problem" in the case of
a multiprocessor machine running multithreaded code, and the "problem"
is only that you get less-than-optimal efficiency. I would submit that
the vast majority of Python applications run on single-processor
machines, and that for many of the apps that *are* run on SMP it's not
essential to run at theoretical-optimum efficiency. Multithreaded,
multiprocessor applications where peak efficiency is necessary, threads
can't be replaced by processes, and the use of C extensions (which don't
suffer from GIL issues) is impractical make up a rather small section of
the Python usage-base, and it's only those applications that see
significant negative impacts from the GIL. Yes, it'd be great if the
GIL wasn't necessary, but if eliminating it makes *my* single-proc,
single-thread apps run significantly slower then the change is a net loss.
Jeff Shannon
Technician/Programmer
Credit International
On Mon, 9 Aug 2004 20:34:36 +0000 (UTC),
Jarek Zgoda <jz****@gazeta.usun.pl> wrote: G. S. Hayes <sj*******@yahoo.com> pisze:
What really hurts is that I can't honestly tell Java programmers that
Python is a slam dunk compared to Java & the JVM. Java has no GIL,
Java has drunk the threads Kool-Aid, and Java programmers are very
likely to be thread-crazy because of the lack of a select equivalent
(until recently) and the lack of good access to processes via fork or
similar. Luckily, it's usually pretty easy to convince people of the
benefits of NOT overusing threads once they've made that mistake once.
Try GUI programming without using threads.
Right this minute I'm writing a GUI program which creates a long lasting
tcp connection, and at times less long lasting udp "connections".
No threads.
Well I guess one thread... :)
--
Sam Holden
Jarek Zgoda <jz****@gazeta.usun.pl> wrote in message news:<cf**********@atlantis.news.tpi.pl>...
Try GUI programming without using threads.
For the GUI tasks that I've done (mostly data visualization stuff for
doing sophisticated views and edits on SQL databases and music
visualization software for doing realtime FFT/spectrum
analyzer/oscilloscope kinds of things that move with the music) it's
been absolutely no problem to use real processes for GUI work. Why
exactly do you not want protected memory for these things?
Lots of big, sophisticated GUIs are implemented without threads (e.g.
Netscape Navigator/Communicator). It almost always winds up being
easier on the programmer and more responsive for the user in the long
run.
Threads often seem simple at the outset, but most of the time they
wind up being far more complex to program and debug than judicious use
of state machines and processes. The major exception is libraries
(especially matrix-math kinds of things) where the internals are so
deeply entwined that it's not easy to figure out well-segmented subset
to put in shared memory. Often (but not always) the amount of work it
takes to figure out all the locking issues is a lot higher than what
it would've taken to seperate the data structures out cleanly. And
sometimes you have legitimate real-world needs that require threads
(most often libraries designed around that model or the two MAJOR
platforms, Java and Windows, without good multiprocess support, but
sometimes problem domains where you really NEED all kinds of crazy
shared memory data structures and segmenting them out doesn't buy you
much).
Jeff Shannon <je**@ccvcorp.com> wrote in message news:<10*************@corp.supernews.com>... Threads seem to only be essential when
long-running background tasks are involved. There's a large set of GUI
programs where this is not an issue.
Threads aren't essential even there; processes are not only acceptable
but preferrable in most cases.
The rest of your post was spot-on, exactly the points I've been trying
to convey.
state machines and processes [and inter-process
communication/coordination]? It sounds like you're saying the alternative
to threads is "home brewed" threads. I don't follow.
Until recently linux implemented threads as processes. I'm really not
concerned with how the threads are implemented in the thread library. I
just don't want a language to prevent me from accessing the thread
library.
Threads often seem simple at the outset, but most of the time they
wind up being far more complex to program and debug than judicious use
of state machines and processes.
Istvan> I think one of the latent messages of this thread was that
Istvan> adding new "gratuitous" features to the core language is a bad
Istvan> thing.
Istvan> Just because someone sits down and codes it does not mean it
Istvan> should be added to the language. Features are forever, you
Istvan> cannot just can't eliminate them in the next version.
...
Istvan> Python is said to come with the batteries included, then
Istvan> that's where new features should go, to the battery level
Istvan> not into the wiring.
The notion of decorated functions has been in Python since (at least)
staticmethod and classmethod were added as builtins. At that time it was
presumed some syntax would be developed in the future to make their use less
clunky (few people like that the "declaration" of a static method occurs at
the end of its body) if it turned out they were useful. They have been
found to be useful. We are now in the throes of the effort to define a
suitable syntax for such a construct.
Decorators are not theorhetical features with no proven use. They are used
today and will likely be used more widely once it is easier to do so.
Skip
Anthony> As far as "fixing" the GIL - well, no-one on Python-Dev has
Anthony> obviously found it to be a problem for them.
I wouldn't state the case that strongly. There appear to be bigger fish for
the python-dev gang to fry up to this point. Perhaps if more of us were
scientific computation types the GIL would be seen as a more important
barrier to be removed. That a fairly bright guy (Greg Stein) removed it
once and found performance to be disappointing doesn't advocate strongly for
removal of the GIL either.
Skip
In article <ma**************************************@python.o rg>,
Skip Montanaro <sk**@pobox.com> wrote:
Anthony> As far as "fixing" the GIL - well, no-one on Python-Dev has
Anthony> obviously found it to be a problem for them.
I wouldn't state the case that strongly. There appear to be bigger fish for
the python-dev gang to fry up to this point. Perhaps if more of us were
scientific computation types the GIL would be seen as a more important
barrier to be removed. That a fairly bright guy (Greg Stein) removed it
once and found performance to be disappointing doesn't advocate strongly for
removal of the GIL either.
Skip
So, what we really want to do is to remove the GIL, and keep it.
Ignoring trivialities like practical implementation, we can do this, since
the moment we start running our program, we will be able to find out
if we are running in an environment were we have access to multiple
processors (and if the program has the ability to use them (at least most
of the time)). If we can use multi-processing, we invoke a Python
interpreter with fine grained locking, otherwise we stick with the
GIL.
It is not really reasonable to have 2 different sets of source code
to maintain the 2 versions of the interpreter, but it might be possible
to make an abstraction of the locking that allows the source code
to compile into 2 different interpreters with different locking
strategies.
Practical implementation would probably be a very big project. Especially in
the case of the standard Python implementation.
Jacob Hallén
--
On 10 Aug 2004, Jacob Hallen wrote: That a fairly bright guy (Greg Stein) removed it once and found
performance to be disappointing doesn't advocate strongly for removal
of the GIL either.
So, what we really want to do is to remove the GIL, and keep it.
Ignoring trivialities like practical implementation, we can do this, since
the moment we start running our program, we will be able to find out
if we are running in an environment were we have access to multiple
processors (and if the program has the ability to use them (at least most
of the time)). If we can use multi-processing, we invoke a Python
interpreter with fine grained locking, otherwise we stick with the
GIL.
The real reason behind the GIL is that the Python interpreter is not
re-entrant; it keeps internal state in a global structure which must be
switched out (and stored somewhere) on thread changes. The real solution
to this problem is to make the interpreter stateless, thus obviating the
need for the GIL entirely. I think this task would be much easier to do
in Stackless than in CPython, but I may be wrong.
Christopher T King wrote: The real reason behind the GIL is that the Python interpreter is not
re-entrant; it keeps internal state in a global structure which must be
switched out (and stored somewhere) on thread changes. The real solution
to this problem is to make the interpreter stateless, thus obviating the
need for the GIL entirely. I think this task would be much easier to do
in Stackless than in CPython, but I may be wrong.
Another reason is reference counting, which must be synchronized.
Daniel
On Tue, 10 Aug 2004, Daniel Dittmar wrote: Christopher T King wrote: The real reason behind the GIL is that the Python interpreter is not
re-entrant; it keeps internal state in a global structure
Another reason is reference counting, which must be synchronized.
Forgot about that; a global reference count lock might work well, but this
could negatively impact performance in the case of things like argument
tuples. Perhaps internal objects that are guaranteed to be thread-local
can skip the reference-count-locking step, but I'm not sure how many (if
any) objects can guarantee this.
In article <Pi*************************************@ccc2.wpi. edu>,
Christopher T King <sq******@WPI.EDU> wrote:
The real reason behind the GIL is that the Python interpreter is not
re-entrant; it keeps internal state in a global structure which must be
switched out (and stored somewhere) on thread changes. The real solution
to this problem is to make the interpreter stateless, thus obviating the
need for the GIL entirely. I think this task would be much easier to do
in Stackless than in CPython, but I may be wrong.
There's no "the" real reason. Another critical reason is that it's a
design goal of CPython to be a useful glue language for C libraries.
Many libraries use internal static variables....
Until a good API exists on all standard platforms for determining
whether a library call needs a GIL around it, we can't seriously discuss
removing the GIL. Currently, any library designed to work with Python's
GIL can easily unlock the GIL while it's running "standalone" (no calls
back into Python).
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/
"To me vi is Zen. To use vi is to practice zen. Every command is a
koan. Profound to the user, unintelligible to the uninitiated. You
discover truth everytime you use it." --*****@lion.austin.ibm.com mu**@vex.net wrote in message news:<ma**************************************@pyt hon.org>... state machines and processes [and inter-process
communication/coordination]? It sounds like you're saying the alternative
to threads is "home brewed" threads.
No. I'm using alternative multiprocessing/event-driven programming
methods that are much less error prone (ie easier to program and
maintain) and easier to get good performance out of than using
threads. The core difference between threads and processes is that
threads share all their memory while processes have protected memory.
That difference _should_ be the deciding factor in whether you use
processes or threads in an application, although as I've said
throughout this thread two major platforms (Windows{see * below} and
Java) don't give you the tools to make that possible; thankfully,
Python does on OSes where it's possible.
I'll repeat: On platforms with sane process implementations, the
deciding factor between using threads or using processes should be
whether you want all your memory (including the code) shared or not.
Because THAT is the fundamental difference between the two.
99% of the time, throwing out protected memory is the wrong thing to
do; it is extremely error prone, difficult to debug, and while it
often seems easy to design a multithreaded program up front it almost
always winds up being more work than using events and processes where
needed. In many cases it'll run dramatically slower than a multiple
process implementation as well.
Note that I'm not alone in this belief; since you seem particularly
interested in the GUI side of things, you might consider reading John
Ousterhout's famous paper "Threads Considered Harmful" (he's the
author of Tcl/Tk and knows a thing or two about programming GUI apps).
Until recently linux implemented threads as processes.
This is not true for any reasonable definition of "recently". What
has recently changed is how the threads are shown by tools like ps and
top, and the threading library has changed from LinuxThreads to a more
efficient implementation (NPTL) that uses faster mutexes. But the
core COE implementation hasn't changed in nearly a decade (since 1996
at least):
Linux implements arbitrary "contexts of execution" in a way similar to
Plan 9. Traditional processes and threads are just two kinds of COE;
COEs can share various attributes. A traditional thread is akin to a
COE that shares memory, whereas traditional processes don't. But
other attributes (e.g. signal handlers or even the filesystem
namespace) can be private or shared. "thread" and "processes" are
only two instances of a much more flexible object.
Various other OSes (e.g. Irix, BSD) do similar things (often using the
name "sproc" or "rfork" instead of "clone).
I'm really not concerned with how the threads are implemented in the
thread library. I just don't want a language to prevent me from
accessing the thread library.
I agree, though I'd much rather use a language like Python that hides
the thread library than a language like Java that hides the much more
useful process library.
*Windows has an excellent I/O Completion Port mechanism for
event-driven programming that can build very efficient multiplexed I/O
(e.g scalable network servers); Linux's queued realtime signals were
based in part on that mechanism.
In article <96**************************@posting.google.com >, sj*******@yahoo.com (G. S. Hayes) wrote: mu**@vex.net wrote in message
news:<ma**************************************@pyt hon.org>...
.... I'm really not concerned with how the threads are implemented in the
thread library. I just don't want a language to prevent me from
accessing the thread library.
I agree, though I'd much rather use a language like Python that hides
the thread library than a language like Java that hides the much more
useful process library.
May have missed some of the context here, I suspect there's
a particular language that's preventing some particular type
of access to the thread library, but the details seem to be
missing.
In more general terms, note that some languages implement
threads on their own, rather than integrating with the OS
thread system. That doesn't work for me, but for some
applications it's said to be much more efficient and robust.
Erlang is probably a good example, the great "microthreads"
stackless add-on of yore probably a more interesting one.
It would be interesting to get someone to revive microthreads,
and someone else to restore the free threading patches, and
then try both on the same compute intensive pure Python
problem on a 4-way Xeon. Microthreads would of course be
limited to one processor, but I wouldn't bet a dime on the
outcome.
Donn Cave, do**@u.washington.edu sj*******@yahoo.com (G. S. Hayes) writes:
[...] No. I'm using alternative multiprocessing/event-driven programming
methods that are much less error prone (ie easier to program and
maintain) and easier to get good performance out of than using
threads. The core difference between threads and processes is that
threads share all their memory while processes have protected memory.
That difference _should_ be the deciding factor in whether you use
processes or threads in an application, although as I've said
throughout this thread two major platforms (Windows{see * below} and
Java) don't give you the tools to make that possible; thankfully,
Python does on OSes where it's possible.
[...]
....although Java 1.4 does provide a select()-workalike -- see Alan
Kennedy's recent post on implementing socket, select and asyncore for
Jython.
John
On Wed, 11 Aug 2004 11:05:06 -0700, Donn Cave <do**@u.washington.edu> wrote: May have missed some of the context here, I suspect there's
a particular language that's preventing some particular type
of access to the thread library, but the details seem to be
missing.
One other point on Python's thread library - it tries to offer a consistent
set of functions and methods and behaviour across all platforms where
threading exists. It also implements it in terms of the platform's native
threads libraries, rather than implementing it's own. This, in theory, makes
Python more portable, and it's threads more robust.
And then there's HP/UX. Oh well, nice theory. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: julio |
last post by:
Sorry but there is no another way, c# .net and mono are going to rip
python, not because python is a bad lenguage, but because is to darn old
and it refuses to innovate things, to fix wrong things,...
|
by: Fresh Air Rider |
last post by:
Hi
I understand that ASP.net 2.0 (Whidbey) is going to reduce coding by
70%.
Surely this is going to de-skill or dumb down the developer's task and
open up the task of web development to less...
|
by: nospam |
last post by:
HtmlSelect has a method called OnServerChange that supposed to detect
whether the control (select) has changed on a postback.
This is not all that useful.
It should be like the asp.net...
|
by: Rod |
last post by:
In Dino Esposito's book, "Programming Microsoft ASP.NET", there is a chapter
titled, "ASP.NET State Management". There is a section in there discussing
session state sometimes going away. He...
|
by: needin4mation |
last post by:
Is the framework going to change so that on sorting it will have some
way of letting you sort two ways, asc or desc?
Is the framework's paging going to change so that it does not bring
back the...
|
by: Rob R. Ainscough |
last post by:
I keep hearing persistant rumors (along with my own experience) that .NET is
going to be abandon by Microsoft due to performance & security issues? I
realize no one from Microsoft is likely to...
|
by: Jeff |
last post by:
Looking for your highly subjective opinions (from those of you who have been
working extensively with VS 2005).
I have a client that needs/wants a complete rewrite of an existing
application. I...
|
by: MikeY |
last post by:
Hi everyone,
I posted a question very early today, but maybe I wasn't articulate enough.
Hopefully this will illicit a response
I've created a windows form and a User Control. This is a...
|
by: Bigeloww |
last post by:
Dollar is going to rise!
Good news for US
http://my.usatodays.us/money/myusatoday.html
----------------------------------
http://community.ihostasp.net
ASP.NET Developer Community
|
by: Rickster66 |
last post by:
As Instructed this is a new thread regarding my original post: "Select Only 10 Columns Going Back"
I'm sorry for the late response. I've been gathering up information and carefully with as much...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
| |
