Re: Documentation suggestions

ms" and fragments of BNF really better than calling them expressions and linking to CPython's Grammar file? -- Adam Olsen, aka Rhamphoryncus [0] Colors pulled off the top of my head -- http://mail.python.org/mailman/listinfo/python-list

Proposal for adding Shallow Threads and a Main Loop to Python

it. I've glossed over many details but they can be cleared up later. What I need to know now is how everybody else thinks about it. Is this something you would use? Does it seem like the right way to do it? And of course the all important one, can I get it in to python core? <0.5 wink> -- Adam Olsen, aka Rhamphoryncus -- http://mail.python.org/mailman/listinfo/python-list

Re: Proposal for adding Shallow Threads and a Main Loop to Python

est the point is the shallow threads, *not* the main loop and event notifiers. Otherwise I'd just use blocking calls in real threads, or maybe just twisted, and not bother creating anything new, ya know? -- Adam Olsen, aka Rhamphoryncus -- http://mail.python.org/mailman/listinfo/python-list

Re: Proposal for adding Shallow Threads and a Main Loop to Python

> by others (e.g. David Mertz if I recall corretly) - but to my view, it > _could_ be done in today python because we have generators. Or not? Go and compare the two get_and_save functions. Would you call that a "little bit more comfortable"? Now imagine the function was 20 lines to begin with, involving a couple loops and some list comprehensions. Then just for kicks, imagine it without generators, instead turning it into a state machine. Yes, you can *technically* do it using generators (and they're what make the implementation easy). But you could also do it using a state machine. Doesn't mean it's practical though. -- Adam Olsen, aka Rhamphoryncus -- http://mail.python.org/mailman/listinfo/python-list

Using weakrefs instead of __del__

aclass-fu is too weak to figure out something without that problem. * I've no idea what will happen when the interpreter exits, but I don't imagine it would matter much for most uses. -- Adam Olsen, aka Rhamphoryncus -- http://mail.python.org/mailman/listinfo/python-list

Re: do people really complain about significant whitespace?

Stephen Kellett wrote: > function() > loop1() > blah > blah > > loop2() > blah > > loop3() > blah > > blah3 > > otherloop() >

Re: Python share CPU time?

Yannick wrote: > Hi, > > I would like to program a small game in Python, kind of like robocode > (http://robocode.sourceforge.net/). > Problem is that I would have to share the CPU between all the robots, > and thus allocate a time period to each robot. However I couldn't find > any way to start a

istep() addition to itertool? (Was: Re: Printing n elements per line in a list)

unexpected wrote: > If have a list from 1 to 100, what's the easiest, most elegant way to > print them out, so that there are only n elements per line. I've run into this problem a few times, and although many solutions have been presented specifically for printing I would like to present a more g

Re: sum and strings

Bill Pursell wrote: > Georg Brandl wrote: > > Paul Rubin wrote: > > > Sybren Stuvel <[EMAIL PROTECTED]> writes: > > >> Because of "there should only be one way to do it, and that way should > > >> be obvious". There are already the str.join and unicode.join methods, > > > > > > Those are obvious???

Re: sum and strings

Paddy wrote: > Rhamphoryncus wrote: > > > > > It's worthwhile to note that the use of + as the concatenation operator > > is arbitrary. It could just have well been | or &, and has no > > relationship with mathematically addition. > > The effect

Re: Client-side TCP socket receiving "Address already in use" upon connect

nding multiple files (small ones especially!) you'll likely hit this. So yeah, bottom line, it IS faster and more efficient to reuse connections. If you're doing a protocol for sending files you'll want to do it. -- Adam Olsen, aka Rhamphoryncus -- http://mail.python.org/mailman/listinfo/python-list

Deleting from a list while iterating

h reverse iteration is somewhat faster at smaller sizes, a set is substantially faster at larger sizes, and I believe is more readable anyway. Copying shouldn't even be considered unless you know the size will always be trivial (< 1000). I'm sure there's a few other approaches that w

Re: Deleting from a list while iterating

r > "fast" approach for n=10. Sorry, I should have clarified that the original post assumed you needed info from the "do something" phase to determine if an element is removed or not. As you say, a list comprehension is superior if that is not necessary. -- Adam Olsen, aka Rhamphoryncus -- http://mail.python.org/mailman/listinfo/python-list

Re: Deleting from a list while iterating

Martin v. Löwis wrote: > Rhamphoryncus schrieb: > > setapproach = """\ > > def func(count): > > from random import random > > items = [random() for i in xrange(count)] > > remove = set() > > for index, x in enumerate(items):

Re: Thread-safety of dict

will stop. lookdict() needs the NULL slots to stop searching. As keys are added and removed from the table it will get filled with dummy slots, so when the total number of active+dummy slots exceeds 2/3rds it will trigger a resize (to the same size or even a smaller size!) so as to clear out al

Re: Python's handling of unicode surrogates

n would have no duplication and would not be slower. I like mine. ;) > BTW, I just implemented support for supplemental planes (surrogates, > 4 byte UTF-8 sequences) for Scintilla, a text editing component. I dream of a day when complete unicode support is universal. With enough effort we may get there some day. :) -- Adam Olsen, aka Rhamphoryncus -- http://mail.python.org/mailman/listinfo/python-list

Re: Python's handling of unicode surrogates

g properly. Some (ie random.choice(u'\U0010\u')) will fail explicitly (rather than silently). -- Adam Olsen, aka Rhamphoryncus -- http://mail.python.org/mailman/listinfo/python-list

Re: Python's handling of unicode surrogates

On Apr 20, 5:49 pm, Ross Ridge <[EMAIL PROTECTED]> wrote: > Rhamphoryncus <[EMAIL PROTECTED]> wrote: > >The only code that will be changed is that which doesn't handle > >surrogates properly. Some will start working properly. Some (ie > >random.choice(u&#x

Re: Python's handling of unicode surrogates

systems has a higher chance of finding acceptance (in comparison). I wish to write software that supports Unicode. Like it or not, Unicode goes beyond the BMP, so I'd be lying if I said I supported Unicode if I only handled the BMP. -- Adam Olsen, aka Rhamphoryncus -- http://mail.python.org/mailman/listinfo/python-list

Re: Decorating class member functions

date(self): > print "update()" > > s = Stupid() > s.update() > Stupid.update(s) I've been bitten by the "class instances as decorators won't get bound" bug many times. I had no idea there was a direct solution. Thanks! -- Adam Olsen, aka Rhamphoryncus -- http://mail.python.org/mailman/listinfo/python-list

Idea for joined() builtin

of these different ways of "combining" objects has different conceptual behaviour and different performance characteristics. Get them confused or attempt to over- generalize and you will be bitten. [1] Math/crypto has some exceptions. Stop mentally poking holes in my argument. :) -- Adam Olsen, aka Rhamphoryncus -- http://mail.python.org/mailman/listinfo/python-list

Re: Is LOAD_GLOBAL really that slow?

tions people attempt. If the speed gains were really that important you should rewrite in C, where you'd get far greater speed gains. So it only seems worthwhile when you really, *really* need to get a slight speedup on your box, you don't need to get any more speedup than that, and C i

Re: Is LOAD_GLOBAL really that slow?

On Aug 30, 12:04 pm, "Chris Mellon" <[EMAIL PROTECTED]> wrote: > On 8/30/07, Rhamphoryncus <[EMAIL PROTECTED]> wrote: > > > On Aug 29, 8:33 pm, Carsten Haese <[EMAIL PROTECTED]> wrote: > > > On Wed, 2007-08-29 at 19:23 -0600, Adam Olsen wrote

Re: concise code (beginner)

his lets you keep an overall O(n) performance, as well as avoiding the tricky semantics. -- Adam Olsen, aka Rhamphoryncus -- http://mail.python.org/mailman/listinfo/python-list

Re: threading and iterator crashing interpreter

On Mar 11, 8:35 am, "Janto Dreijer" <[EMAIL PROTECTED]> wrote: > On Mar 11, 3:27 pm, "Gabriel Genellina" <[EMAIL PROTECTED]> > wrote: > > At least, the problem of using the same generator from different threads > > still remains, if you don't use my modified code. In general, when using > > multipl

Re: threading and iterator crashing interpreter

On Mar 12, 4:47 pm, "Klaas" <[EMAIL PROTECTED]> wrote: > On Mar 12, 1:10 pm, "Rhamphoryncus" <[EMAIL PROTECTED]> wrote: > > >http://sourceforge.net/tracker/index.php?func=detail&aid=1579370&grou... > > > That refers to a generator crash.

Re: tuples, index method, Python's design

: byte ≤ code unit ≤ code point ≤ scalar value ≤ grapheme cluster ~ character ≤ syllable ≤ word ≤ sentence ≤ paragraph "12" in "123" allows you to handle bytes through scalar values the same way, glossing over the implementation details (such as UTF-32 on linux and UTF-16 on w

Re: tuples, index method, Python's design

On Apr 13, 11:05 pm, Paul Rubin <http://[EMAIL PROTECTED]> wrote: > "Rhamphoryncus" <[EMAIL PROTECTED]> writes: > > > i = s.index(e) => s[i] = e > > > Then this algorithm is no longer guaranteed to work with strings. > > It never worked co

Re: tuples, index method, Python's design

On Apr 14, 11:59 am, Paul Rubin <http://[EMAIL PROTECTED]> wrote: > "Rhamphoryncus" <[EMAIL PROTECTED]> writes: > > Nope, it's pretty fundamental to working with text, unicode only being > > an extreme example: there's a wide number of ways to break

Re: tuples, index method, Python's design

On Apr 15, 1:55 am, Paul Rubin <http://[EMAIL PROTECTED]> wrote: > "Rhamphoryncus" <[EMAIL PROTECTED]> writes: > > Indexing cost, memory efficiency, and canonical representation: pick > > two. You can't use a canonical representation (scalar values) w

Re: tuples, index method, Python's design

On Apr 15, 8:56 am, Roel Schroeven <[EMAIL PROTECTED]> wrote: > Paul Rubin schreef: > > > "Rhamphoryncus" <[EMAIL PROTECTED]> writes: > >> Indexing cost, memory efficiency, and canonical representation: pick > >> two. You can't use a canoni

Re: Using fractions instead of floats

sult in 0. ;) -- Adam Olsen, aka Rhamphoryncus -- http://mail.python.org/mailman/listinfo/python-list

Re: Python Interview Questions

m is so slow. The recent optimizations just make it more obscure. += shouldn't be an obvious choice for sequences. If it's mutable, use .append(). If it's immutable, build up in a mutable sequence, then convert. -- Adam Olsen, aka Rhamphoryncus -- http://mail.python.org/mailman/listinfo/python-list

Re: Maths error

Nick Maclaren wrote: > The problem with it is that it is an unrealistically pessimal model, > and there are huge classes of algorithm that it can't handle at all; > anything involving iterative convergence for a start. It has been > around for yonks (I first dabbled with it 30+ years ago), and it

Re: threading and multicores, pros and cons

e if they get reasonable performance using JIT. Then I can start hacking on it. -- Adam Olsen, aka Rhamphoryncus -- http://mail.python.org/mailman/listinfo/python-list

Re: Weird result returned from adding floats depending on order I add them

On Feb 20, 6:08 am, "John Machin" <[EMAIL PROTECTED]> wrote: > >>> for x in b: > > ...tot += x > ...print repr(x), repr(tot) > ... > 0.20001 0.20001 > 0.20001 0.40002 > 0.20001 0.60009 > 0.20001 0.80

Re: Populating huge data structures from disk

ed by Paul Rubin) seems like the cleanest way to ensure they stay "hot". One pass during startup is insufficient, as unused portions of a long-running program may get swapped out. Also note that poking need only touch 1 byte per page, much cheaper than copying the entire page (so long as the page is already loaded from disk.) -- Adam Olsen, aka Rhamphoryncus -- http://mail.python.org/mailman/listinfo/python-list

Re: Confused about closures and scoping rules

r needed to repeatedly modify closure variables. However, I may not set them until after the function is defined. A simple example is that of a recursive function: def foo(): def bar(): bar() # useful work omitted return bar Obviously, bar can't be set until after the function ob

Re: Using python as primary language

lower still! I've starting putting together a site explaining my approach to solving these problems: http://code.google.com/p/python-safethread/ -- Adam Olsen, aka Rhamphoryncus -- http://mail.python.org/mailman/listinfo/python-list

Re: Using python as primary language

eads. The bigger question is one of usability. We could make a usability/ performance tradeoff if we had more options, and there's a lot that can give good performance, but at this point they all offer poor to moderate usability, none having good usability. The crux of the "multicore c

Re: Using python as primary language

On Nov 12, 2:28 am, "Martin Vilcans" <[EMAIL PROTECTED]> wrote: > On Nov 10, 2007 12:48 AM, Rhamphoryncus <[EMAIL PROTECTED]> wrote: > > > On Nov 9, 1:45 pm, "Terry Reedy" <[EMAIL PROTECTED]> wrote: > > > 2. If micro-locked Python r

Re: Troubleshooting garbage collection issues

roblem would come about. Are you using threading at all? Do you see any pattern to the types that have the bogus pointers? -- Adam Olsen, aka Rhamphoryncus -- http://mail.python.org/mailman/listinfo/python-list

Re: removeall() in list

On Jan 12, 1:37 am, [EMAIL PROTECTED] wrote: > On Jan 11, 8:04 pm, Paul Rubin wrote: > > > > > [EMAIL PROTECTED] writes: > > > Could you: > > > > lockerA= Locker( listA, listB ) > > > lockerA.op( listB.reverse ) > > > lockerA.op( listA.pop ) > > > > Where lockerA ops acqu

Re: super, decorators and gettattribute

ed. Don't think of them as mappings. Think of them as a way for a class to hook into getattr's protocol, conveniently named similar to getattr (__getattr__ and __getattribute__). getattr() may call several methods, no methods at all, change the arguments, etc. Although len() may seem simple, many others are not so simple. -- Adam Olsen, aka Rhamphoryncus -- http://mail.python.org/mailman/listinfo/python-list

Re: Multiple interpreters retaining huge amounts of memory

On Feb 2, 10:32 pm, Graham Dumpleton <[EMAIL PROTECTED]> wrote: > The multi interpreter feature has some limitations, but if you know > what you are doing and your application can be run within those > limitations then it works fine. I've been wondering about this for a while. Given the severe li

Re: Article of interest: Python pros/cons for the enterprise

On Feb 23, 11:39 am, Nicola Musatti <[EMAIL PROTECTED]> wrote: > Paul Rubin wrote: > > Nicola Musatti <[EMAIL PROTECTED]> writes: > >>>a = [f(x) + g(y) for x,y in izip(m1, m2) if h(x,y).frob() == 7] > [...] > > There you replace one line of code with 40+ lines to get around the > > absence of G

Re: Implementing file reading in C/Python

On Jan 9, 2:14 pm, Marc 'BlackJack' Rintsch wrote: > On Fri, 09 Jan 2009 15:34:17 +, MRAB wrote: > > Marc 'BlackJack' Rintsch wrote: > > >> def iter_max_values(blocks, block_count): > >>     for i, block in enumerate(blocks): > >>         histogram = defaultdict(int) > >>         for byte in b

Re: Python 3 isinstance

On Jan 14, 3:14 pm, "Lambert, David W (S&T)" wrote: > Please, why isn't a set permitted as the second argument to isinstance? The real problem is it would be misleading. isinstance(a, myset) suggests implementation like type(a) in myset, but it's really any (isinstance(a, t) for t in myset). If

Re: Does Python really follow its philosophy of "Readability counts"?

On Jan 18, 12:51 pm, "Russ P." wrote: > And even if all your developers were excellent, data hiding would > still be a convenient mechanism to simplify their jobs so they can > focus on higher level problems -- and not have to rely on an ugly > naming convention. That's just it — the cost of main

Re: Does Python really follow its philosophy of "Readability counts"?

On Jan 20, 12:04 pm, "Russ P." wrote: Hey, if pylint can reliably detect private data access violations, > that's good news to me. I haven't used it, so I don't know. (I used > pychecker a while back, but I haven't used that for a while either.) > > If pylint can check access violations, then it

Re: what's the point of rpython?

On Jan 16, 5:37 pm, "Brendan Miller" wrote: > So I kind of wanted to ask this question on the pypy mailing list.. > but there's only a pypy-dev list, and I don't want to put noise on the > dev list. > > What's the point of RPython? By this, I don't mean "What is RPython"? > I get that. I mean, why

Re: what's the point of rpython?

On Jan 19, 9:00 pm, "Brendan Miller" wrote: > Maybe I'm missing something here but a lock free algorithm for > reference counting seems pretty trivial. As long as you can atomically > increment and decrement an integer without locking you are pretty much > done. "lock free" is largely meaningless

Re: what's the point of rpython?

On Jan 20, 2:39 pm, Paul Rubin <http://phr...@nospam.invalid> wrote: > Rhamphoryncus writes: > > "lock free" is largely meaningless.  What it really means is "we use > > small hardware locks rather than big software locks, thereby reducing > > (but not e

Re: what's the point of rpython?

On Jan 21, 12:57 pm, MRAB wrote: > I'm not sure whether multicore processors share a cache or, if not, have > some other on-chip mechanism. Multiprocessor machines, however, are a > different matter... They share some, but also have some exclusive. How much of which depends entirely on which CPU

Re: what's the point of rpython?

On Jan 21, 9:46 pm, Paul Rubin <http://phr...@nospam.invalid> wrote: > Rhamphoryncus writes: > > a) The contended case is the issue, not the uncontended case.  An > > uncontended lock is just constant overhead, not a barrier to > > scalability > > a1) Really what

Re: Does Python really follow its philosophy of "Readability counts"?

On Jan 22, 7:48 pm, Terry Reedy wrote: > Steven D'Aprano wrote: > > > Here's a thought experiment for you. You've suggested that the values > > returned by cmp() are allowed to change "at whim". Okay, let's do it: > > make a patch that changes cmp() to return -17, 0 or 53, and promise to > > suppo

Re: Why GIL? (was Re: what's the point of rpython?)

On Jan 22, 9:38 pm, Carl Banks wrote: > On Jan 22, 6:00 am, a...@pythoncraft.com (Aahz) wrote: > > > > > In article <7xd4ele060@ruckus.brouhaha.com>, > > Paul Rubin   wrote: > > > >alex23 writes: > > > >> Here's an article by Guido talking about the last attempt

Re: Why GIL? (was Re: what's the point of rpython?)

On Jan 22, 11:09 pm, Carl Banks wrote: > On Jan 22, 9:38 pm, Rhamphoryncus wrote: > > > > > On Jan 22, 9:38 pm, Carl Banks wrote: > > > > On Jan 22, 6:00 am, a...@pythoncraft.com (Aahz) wrote: > > > > > In article <7xd4ele060@rucku

Re: Pythonic list/tuple/dict layout?

d1 -- http://mail.python.org/mailman/listinfo/python-list

Re: Does Python really follow its philosophy of "Readability counts"?

On Jan 27, 12:13 pm, "Russ P." wrote: > On Jan 26, 6:09 am, Steve Holden wrote: > > > Quite. Python is a language "for consenting adults". It has perceived > > deficiencies for certain software engineering environments. Can we drop > > the subject now? This horse was flogged to death long ago, an

Re: Why GIL? (was Re: what's the point of rpython?)

On Jan 27, 12:47 pm, Steve Holden wrote: > Paul Rubin wrote: > > GIL-less Python (i.e. Jython) already exists and beats CPython in > > performance a lot of the time, including on single processors. > > Whether the GIL can be eliminated from CPython without massive rework > > to every extension mod

Re: Flattening lists

On Feb 5, 1:16 pm, Michele Simionato wrote: > On Feb 5, 7:24 pm, a...@pythoncraft.com (Aahz) wrote: > > > In article > > , > > Michele Simionato   wrote: > > > >Looks fine to me. In some situations you may also use hasattr(el, > > >'__iter__') instead of isinstance(el, list) (it depends if you wa

Re: Flattening lists

On Feb 6, 10:21 pm, rdmur...@bitdance.com wrote: > Quoth Mensanator : > > def flatten(listOfLists): > >     return list(chain.from_iterable(listOfLists)) > >     Python 2.6.1 (r261:67515, Jan  7 2009, 17:09:13) >     [GCC 4.3.2] on linux2 >     Type "help", "copyright", "credits" or "license" for m

Re: Flattening lists

On Feb 7, 1:39 pm, wrote: > On Sat, 7 Feb 2009 01:06:06 -0800 (PST) > Rhamphoryncus wrote: > > > What usecase do you have for such inconsistently structured data? > > I have a similar use case in pyspread, which is a Python spreadsheet > that employs numpy object arrays.

Re: Flattening lists

On Feb 7, 3:07 pm, wrote: > On Sat, 7 Feb 2009 12:50:22 -0800 (PST) > Rhamphoryncus wrote: > > Can you explain this in a little more detail? > > In the application, there is one main numpy array of type "O". > Each element of the array corresponds to one cell in

Re: can the sequence of entries in a dictionary be depended on?

On Nov 23, 6:43 pm, John Machin <[EMAIL PROTECTED]> wrote: > On Nov 24, 11:59 am, Carsten Haese <[EMAIL PROTECTED]> wrote: > > > Diez B. Roggisch wrote: > > > AFAIK the order is deterministic as long as you don't alter the dict > > > between > > > iterations. However, this is an implementation det

Re: Rich Comparisons Gotcha

On Dec 7, 4:20 pm, Steven D'Aprano <[EMAIL PROTECTED] cybersource.com.au> wrote: > On Sun, 07 Dec 2008 15:32:53 -0600, Robert Kern wrote: > > Rasmus Fogh wrote: > > >> Current behaviour is both inconsistent and counterintuitive, as these > >> examples show. > > > x = float('NaN') > > x == x

Re: Rich Comparisons Gotcha

On Dec 8, 11:54 am, Robert Kern <[EMAIL PROTECTED]> wrote: > Rhamphoryncus wrote: > > On Dec 7, 4:20 pm, Steven D'Aprano <[EMAIL PROTECTED] > > cybersource.com.au> wrote: > >> On Sun, 07 Dec 2008 15:32:53 -0600, Robert Kern wrote: > >>>

Re: Rich Comparisons Gotcha

On Dec 8, 1:04 pm, Robert Kern <[EMAIL PROTECTED]> wrote: > Rhamphoryncus wrote: > > On Dec 8, 11:54 am, Robert Kern <[EMAIL PROTECTED]> wrote: > >> Rhamphoryncus wrote: > >>> On Dec 7, 4:20 pm, Steven D'Aprano <[EMAIL PROTECTED] > >>>

Re: Rich Comparisons Gotcha

On Dec 8, 2:51 pm, Robert Kern <[EMAIL PROTECTED]> wrote: > Rhamphoryncus wrote: > > "We've always done it that way" is NOT a use case!  Certainly, it's a > > factor, but it seems quite weak compared to the sort use case. > > I didn't say it was

Re: Rich Comparisons Gotcha

On Dec 8, 7:44 pm, Steven D'Aprano <[EMAIL PROTECTED]> wrote: > On Mon, 08 Dec 2008 10:20:56 -0800, Rhamphoryncus wrote: > > On Dec 7, 4:20 pm, Steven D'Aprano <[EMAIL PROTECTED] > > cybersource.com.au> wrote: > >> On Sun, 07 Dec 2008 15:32:53 -060

Re: Rich Comparisons Gotcha

You grossly overvalue using the "in" operator on lists. It's far more common to use a dict or set for containment tests, due to O(1) performance rather than O(n). I doubt the numpy array supports hashing, so an error for misuse is all you should expect. In the rare case that you want to test for

Re: Rich Comparisons Gotcha

On Dec 10, 7:49 am, Rasmus Fogh <[EMAIL PROTECTED]> wrote: > Rhamphoryncus wrote: > > You grossly overvalue using the "in" operator on lists. > > Maybe. But there is more to it than just 'in'. If you do:>>> c = > numpy.zeros((2,)) > >>

Re: __future__ and compile: unrecognised flags

On Dec 13, 6:03 am, Steve Holden wrote: > Poor Yorick wrote: > > I have a future statement in a script which is intended to work in 2.6 and > > 3. > > Shouldn't compile flags in __future__ objects essentially be noops for > > versions > > that already support the feature? doctest is complaining

Re: Are python objects thread-safe?

On Dec 21, 11:51 am, RajNewbie wrote: > Say, I have two threads, updating the same dictionary object - but for > different parameters: > Please find an example below: > a = {file1Data : '', >        file2Data : ''} > > Now, I send it to two different threads, both of which are looping > infinitely

Re: 2.6, 3.0, and truly independent intepreters

On Oct 22, 10:32 am, Andy <[EMAIL PROTECTED]> wrote: > Dear Python dev community, > > I'm CTO at a small software company that makes music visualization > software (you can check us out atwww.soundspectrum.com).  About two > years ago we went with decision to use embedded python in a couple of > ou

Re: 2.6, 3.0, and truly independent intepreters

On Oct 22, 7:04 pm, Andy <[EMAIL PROTECTED]> wrote: > > What you describe, truly independent interpreters, is not threading at > > all: it is processes, emulated at the application level, with all the > > memory cost and none of the OS protections.  True threading would > > involve sharing most obj

Re: 2.6, 3.0, and truly independent intepreters

On Oct 22, 10:31 pm, Andy <[EMAIL PROTECTED]> wrote: > > You seem confused.  PEP 3121 is for isolated interpreters (ie emulated > > processes), not threading. > > Please reread my points--inherently isolated interpreters (ie. the top > level object) are indirectly linked to thread independence.  I

Re: 2.6, 3.0, and truly independent intepreters

On Oct 23, 11:30 am, Glenn Linderman <[EMAIL PROTECTED]> wrote: > On approximately 10/23/2008 12:24 AM, came the following characters from > the keyboard of Christian Heimes: > > > Andy wrote: > >> 2) Barriers to "free threading".  As Jesse describes, this is simply > >> just the GIL being in place

Re: 2.6, 3.0, and truly independent intepreters

On Oct 24, 1:02 pm, Glenn Linderman <[EMAIL PROTECTED]> wrote: > On approximately 10/24/2008 8:42 AM, came the following characters from > the keyboard of Andy O'Meara: > > > Glenn, great post and points! > > Thanks. I need to admit here that while I've got a fair bit of > professional programming

Re: 2.6, 3.0, and truly independent intepreters

On Oct 24, 2:59 pm, Glenn Linderman <[EMAIL PROTECTED]> wrote: > On approximately 10/24/2008 1:09 PM, came the following characters from > the keyboard of Rhamphoryncus: > > PyE: objects are reclassified as shareable or non-shareable, many > > types are now only allowed to

Re: 2.6, 3.0, and truly independent intepreters

On Oct 24, 3:02 pm, Glenn Linderman <[EMAIL PROTECTED]> wrote: > On approximately 10/23/2008 2:24 PM, came the following characters from the > keyboard of Rhamphoryncus: >> >> On Oct 23, 11:30 am, Glenn Linderman <[EMAIL PROTECTED]> wrote: >> >>> >&

Re: 2.6, 3.0, and truly independent intepreters

On Oct 25, 12:29 am, greg <[EMAIL PROTECTED]> wrote: > Rhamphoryncus wrote: > > A list > > is not shareable, so it can only be used within the monitor it's > > created within, but the list type object is shareable. > > Type objects contain dicts, which allow a

Re: 2.6, 3.0, and truly independent intepreters

On Oct 26, 6:57 pm, "Andy O'Meara" <[EMAIL PROTECTED]> wrote: > Grrr... I posted a ton of lengthy replies to you and other recent > posts here using Google and none of them made it, argh. Poof. There's > nothing that fires more up more than lost work,  so I'll have to > revert short and simple answ

Re: 2.6, 3.0, and truly independent intepreters

On Oct 28, 9:30 am, "Andy O'Meara" <[EMAIL PROTECTED]> wrote: > On Oct 25, 9:46 am, "M.-A. Lemburg" <[EMAIL PROTECTED]> wrote: > > > These discussion pop up every year or so and I think that most of them > > are not really all that necessary, since the GIL isn't all that bad. > > Thing is, if the t

Re: 2.6, 3.0, and truly independent intepreters

On Oct 29, 7:20 am, Paul Boddie <[EMAIL PROTECTED]> wrote: > On 28 Okt, 21:03, Rhamphoryncus <[EMAIL PROTECTED]> wrote: > > > * get a short-term bodge that works, like hacking the 3rd party > > library to use your shared-memory allocator.  Should be far less work &

Re: 2.6, 3.0, and truly independent intepreters

On Oct 30, 8:23 pm, "Patrick Stinson" <[EMAIL PROTECTED]> wrote: > Speaking of the big picture, is this how it normally works when > someone says "Here's some code and a problem and I'm willing to pay > for a solution?" I've never really walked that path with a project of > this complexity (I guess

Re: Python 3.0 - is this true?

On Nov 8, 10:14 pm, Kay Schluehr <[EMAIL PROTECTED]> wrote: > I guess building a multiset is a little more expensive than just O(n). > It is rather like building a dict from a list which is O(k*n) with a > constant but small factor k. The comparison is of the same order. To > enable the same behavi

Re: Python 3.0 - is this true?

On Nov 10, 8:16 am, Terry Reedy <[EMAIL PROTECTED]> wrote: > Duncan Grisby wrote: > > In article <[EMAIL PROTECTED]>, > >  Terry Reedy  <[EMAIL PROTECTED]> wrote: > > >> Have you written any Python code where you really wanted the old, > >> unpredictable behavior? > > > I have an object database wr

Re: Python 3.0 - is this true?

On Nov 10, 6:25 pm, Steven D'Aprano <[EMAIL PROTECTED]> wrote: > On Mon, 10 Nov 2008 11:43:59 -0800, Rhamphoryncus wrote: > > You might as well comment out the sort and call it good.  That's what > > you really had in 2.x.  It was close enough most of the time to *l

Re: Python 3.0 - is this true?

On Nov 10, 9:31 pm, Rhamphoryncus <[EMAIL PROTECTED]> wrote: > On Nov 10, 6:25 pm, Steven D'Aprano > > > > <[EMAIL PROTECTED]> wrote: > > On Mon, 10 Nov 2008 11:43:59 -0800, Rhamphoryncus wrote: > > > You might as well comment out the sort and call it

Re: threading - race condition?

On May 11, 10:16 am, skunkwerk <[EMAIL PROTECTED]> wrote: > On May 10, 1:31 pm, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote: > > > > > On Fri, 9 May 2008 08:40:38 -0700 (PDT),skunkwerk<[EMAIL PROTECTED]> > > declaimed the following in comp.lang.python: > > > Coming in late... > > > > On May

Re: threading - race condition?

On May 12, 1:31 pm, skunkwerk <[EMAIL PROTECTED]> wrote: > On May 12, 1:40 am, Rhamphoryncus <[EMAIL PROTECTED]> wrote: > > > > > On May 11, 10:16 am,skunkwerk<[EMAIL PROTECTED]> wrote: > > > > On May 10, 1:31 pm, Dennis Lee Bieber <[EMAIL PROTE

Re: waiting on an event blocks all signals

On May 18, 9:05 am, "Diez B. Roggisch" <[EMAIL PROTECTED]> wrote: > alan schrieb: > > > This ignores CTRL-C on every platform I've tested: > > > python -c "import threading; threading.Event().wait()" > > ^C^C^C^C > > > It looks to me like all signals are masked before entering wait(). Can > > someo

Re: Thread killing - I know I know!

On May 19, 11:31 am, "Chris Mellon" <[EMAIL PROTECTED]> wrote: > On Mon, May 19, 2008 at 11:36 AM, Roger Heathcote > > Fair point, but for sub processes that need to be in close contact with the > > original app, or very small functions that you'd like 100s or 1000s of it > > seems like a kludge ha

Re: conventions/requirements for 'is' vs '==', 'not vs '!=', etc

On May 20, 12:09 pm, "Terry Reedy" <[EMAIL PROTECTED]> wrote: > Intern() is gone in 3.0 But not gone far: >>> import sys >>> sys.intern -- http://mail.python.org/mailman/listinfo/python-list

Re: Threads and import

On May 28, 1:14 pm, [EMAIL PROTECTED] wrote: > Hi, > > I'm trying to work out some strange (to me) behaviour that I see when > running a python script in two different ways (I've inherited some > code that needs to be maintained and integrated with another lump of > code). The sample script is: > >

Re: ThreadPoolingMixIn

On May 30, 2:40 pm, [EMAIL PROTECTED] wrote: > Hi, everybody! > > I wrote a useful class ThreadPoolingMixIn which can be used to create > fast thread-based servers. This mix-in works much faster than > ThreadingMixIn because it doesn't create a new thread on each request. Do you have any benchmark

Re: ThreadPoolingMixIn

On May 31, 1:40 pm, "Giampaolo Rodola'" <[EMAIL PROTECTED]> wrote: > On 30 Mag, 22:40, [EMAIL PROTECTED] wrote: > > > > > Hi, everybody! > > > I wrote a useful class ThreadPoolingMixIn which can be used to create > > fast thread-based servers. This mix-in works much faster than > > ThreadingMixIn b

Re: How to kill a thread?

On Jun 6, 12:44 pm, The Pythonista <[EMAIL PROTECTED]> wrote: > It's always been my understanding that you can't forcibly kill a thread > in Python (at least not in a portable way). The best you can do is > politely ask it to die, IIRC. Inherently, the best you can do in most languages is ask the

  1   2   >