amming style, e.g. using monads and
> so on.
>
I have the impression that you misunderstood me. I'm not after a
side-effect free language. I just think python could be nicer in
allowing some side-effects.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
limiting this feature in such a way?
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-02-28, Paul Rubin schreef :
> Antoon Pardon <[EMAIL PROTECTED]> writes:
>> Can anyone explain why descriptors only work when they are an attribute
>> to an object or class. I think a lot of interesting things one can
>> do with descriptors would be just as inte
Op 2005-02-28, Diez B. Roggisch schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>> Op 2005-02-28, Paul Rubin schreef :
>>> Antoon Pardon <[EMAIL PROTECTED]> writes:
>>>> Can anyone explain why descriptors only work when they are an attribute
Op 2005-02-28, Daniel Dittmar schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>>>>Can anyone explain why descriptors only work when they are an attribute
>>>>to an object or class. I think a lot of interesting things one can
>>>>do with descripto
Op 2005-02-28, Dima Dorfman schreef <[EMAIL PROTECTED]>:
> On 2005-02-28, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>> Op 2005-02-28, Diez B. Roggisch schreef <[EMAIL PROTECTED]>:
>>> I still don't see how that is supposed to work for "a lot of interes
an article to a comparative in french
turns it into a superlative. So instead of writing:
The more it changes, the more is stays the same
You wrote something like:
Most it changes, most it is the same thing.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
I'm not sure this confirms anything. IMO it is possible that echo
will translate to , giving you the
impression that you have provideded a newline on the command line
while in fact you have not.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
ile Nr > 1:
PyThreadState_SetAsyncExc(thread_id, NULL)
sleep(0.1)
Nr = PyThreadState_SetAsyncExc(thread_id, exception)
What this basically does is when a number greater than one
is returned go in a loop to cancel the effect wait a short
time and try again.
--
Antoon Pa
using print with it
various extentions.
For instance if I do the following
a = 1,
I have assigned a one element tuple to a.
But if I do
print 1,
It doesn't print a one element tuple.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
?
>
> There were lots of answers, but I'm not sure I saw the "why" addressed.
>
> Consider this:
>
> a = (3 + 5) * 5
>
> You really, really want (3 + 5) to be an integer, not a one-item tuple.
I sometimes do wonder if some impliciteness wouldn
es - but I
> can't find some on my keyboard.
Well I can't find braille on my keyboard, but if I wanted to, it
wouldn't be difficult to get it on my screen. So is it with
different parentheses. That python can't use these parentheses
is again a design decision.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
same time arguing in another thread that you'd like to
> have mutable keys for dicts that needed copying the very same keys - at
> much greater costs, per case and even more so in general as using dicts is
> common where pure constant arithmetic expressions aren't.
Well it see
't bear them.
Move on and look out for an other language. Newbees often enough
get the advise that with the mindset they currently have, python
is not the language they are looking for and they would be happier
programming in an other language. Well maybe that can happen to
experienced programmers too. Maybe the language will evolve so
it no longer fits there mindset. Well too bad, such things happen.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
>> Where did I express this dislike. I'm not denying it because I know I
>> forget such things, but I sure don't remember now.
>
> I showed the quote above - you wanted to have (8) behave as (8,) - so I
> concluded you either don't like typing that extra comma, or alternatively
> want introduce a new pair of parentheses to express tuples.
I was wondering about the merrits of (8) behaving as (8,) that is
not the same as wanting it. May be you shouldn't read thing that
are not there.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
bogus result, not a runtime error. A more common programming error I
> commit is passing a string where a list ist expected. And then I wonder
> why later operations work on one-character strings.
The standard answer to this seems to be to use unittesting.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-03-18, Daniel Dittmar schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>>>My peeve is about having operators added to standard types. This
>>>increases the chances that using an object the wrong way leads to a
>>>bogus result, not a runtime erro
d work exactly equivallent as the
above the following should work
a = 42
def f():
a = a + 1
print a
print a
And the result should be:
43
42
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Linux distribution.
Debian has muliple distributions. Only the stable distribution is
really conservative. The PostgreSQL version in the testing distribution
is 7.4.6-4, the download page of PostgreSQL gives 7.4.6 as the latest
version. That seems to be in order.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
> as a side effect of importing).
I don't see why starting a thread as a side effect of importing is
bad thread practice. Sure python doesn't cater for it, but IMO
that seems to be python failing.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2004-12-13, Tim Peters schreef <[EMAIL PROTECTED]>:
> [Antoon Pardon]
>> I don't see why starting a thread as a side effect of importing is
>> bad thread practice. Sure python doesn't cater for it, but IMO
>> that seems to be python failing.
>
> Obviou
Op 2004-12-14, Steve Holden schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>> Op 2004-12-13, Tim Peters schreef <[EMAIL PROTECTED]>:
>>
>>>[Antoon Pardon]
>>>
>>>>I don't see why starting a thread as a side effect of impor
sses, which will mean more copying than when a
copy of a key would have been made on key entry.
2) Simulate appends and pops by tuple operations which can also
require more copying than was gained by using tuples as key.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2004-12-15, Fredrik Lundh schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>>> how would you implement a dictionary where the keys could change, without
>>> any performance penalty compared to the current implementation?
>>
>> The performace gain
Op 2004-12-15, Roel Schroeven schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Op 2004-12-15, Fredrik Lundh schreef <[EMAIL PROTECTED]>:
>>>sorry, but I don't understand your reply at all. are you saying that
>>>dictionaries
>>>could sup
Op 2004-12-16, Jeff Shannon schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>>Demanding that users of dictioanaries somehow turn their mutable objects
>>into tuples when used as a key and back again when you retrieve the keys
>>and need the object [...]
&
Op 2004-12-15, Steve Holden schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>> Op 2004-12-15, Roel Schroeven schreef <[EMAIL PROTECTED]>:
>>
>>>Antoon Pardon wrote:
>>>
>>>>Op 2004-12-15, Fredrik Lundh schreef <[EMAIL PROTECT
Op 2004-12-16, Jeremy Bowers schreef <[EMAIL PROTECTED]>:
> On Wed, 15 Dec 2004 15:08:09 +0000, Antoon Pardon wrote:
>
>> And I think that is a stupid reason. There are enough other situations
>> were people work with mutable objects but don't wish to mutate specific
&
Op 2004-12-16, Fredrik Lundh schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>> That depends on whether the programmes wants value equality
>> or identity equality.
>>
>> In the first case the programmer shouldn't mutate a after
>> it was
Op 2004-12-16, Paul Rubin schreef :
> Antoon Pardon <[EMAIL PROTECTED]> writes:
>> Two guidelines can make it easier for a programmer to do this.
>>
>> 1) Put a copy in the dictionary, so that mutating the original
>>object won't affect what is in the di
Op 2004-12-16, Fredrik Lundh schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>>> how does the dictionary know if you want key value equality or key
>>> identity equality?
>>
>> By the __hash__ and __eq__ methods you provide on your object
> mutates a dict key then things will break), this will result in more
> bugs and more confusion over time. There is no way for Python to be
> able to behave consistently in the face of mutable dict keys, therefore
> ("In the face of ambiguity, refuse the temptation to guess.") Python
> declines the temptation of making it trivial to use mutable objects as
> dict keys.
As it turns out, python makes no difference in difficulty for making
either mutable or immutable objects usable as dictionary keys. The
only difference is that python only made its standard immutable
types hashable and not its standard mutable objects.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2004-12-17, Jeff Shannon schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>>Op 2004-12-16, Jeff Shannon schreef <[EMAIL PROTECTED]>:
>>
>>
>>
>>>nevermind the fact that I can't think of a case where I'm
>>>likely to
Op 2004-12-16, Max M schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>> Well IMO there are two sides in this argument. The first is whether
>> or not python allows mutable keys. The second is whether or not
>> limiting keys to immutables in dictionaries
there would be no need for tuples.
Not exactly. As I understood the OP only wanted
the various components to be mutable but not the
length of a tuple.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2004-12-17, Jeff Shannon schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>>Op 2004-12-17, Jeff Shannon schreef <[EMAIL PROTECTED]>:
>>
>>
>>
>>>(And I have to reiterate, here, that I have *never* felt it a hardship
>>>to be
Op 2004-12-18, Nick Coghlan schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Would you have us construct two related classes each time we find
>> ourselves in such a situation and copy an object from one
>> class to the other depending on the circumstances?
>
Op 2004-12-17, Jeff Shannon schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>>Op 2004-12-17, Jeff Shannon schreef <[EMAIL PROTECTED]>:
>>
>>
>>>To take another approach -- given some function that allows lists to
>>>(pretend to be) h
ash value must never change during it's lifetime
>
> Lists could achieve the former, but not the latter. Tuples can achieve both,
> by
> virtue of being immutable, with immutable contents. Ditto for sets &
> frozensets.
Yes they can. If you don't mutate a list it will never change during
it's lifetime.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
want? (all features not
> tested, none tested beyond what you see,
> and special methods like update and iterators will just work on the plain
> dict part if they work at all, unless
> you add the code ;-)
I don't expect anyting special. Python provides all that is needed. It
i
that these conditions are
met while the object is a key. If those things would change before
or after the object is a key, the dictionary wouldn't care about
it.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
se it.
If not it seems you don't object to anonymity.
And yes it sometimes is hard. Of course you can just name it f1, f2 etc,
but that is no improvement over anonymity and sometimes the best you
can do is describe what the function does, but the code does that
better.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2004-12-21, Nick Coghlan schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Why then doesn't python think the same about sorted lists. When I have a
>> sorted list and do operations on it that depend on it being sorted,
>> I can mess things up just as easil
Op 2004-12-21, Jeff Shannon schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>>Op 2004-12-21, Nick Coghlan schreef <[EMAIL PROTECTED]>:
>>
>>
>>>Antoon Pardon wrote:
>>>
>>>
>>>>Why then doesn't python think
ap by
not allowing the elements to be mutated.
So why should violating and repairing invariants be allowed to have a
performance inpact, except when it is done with dictioary keys.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2004-12-21, Jeff Shannon schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>>Op 2004-12-17, Jeff Shannon schreef <[EMAIL PROTECTED]>:
>>
>>
>>>Now, even if hash were made to equal id... suppose I then pass that dict
>>>to a functi
Op 2004-12-22, Fredrik Lundh schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>>> and to temporarily refer back to the top of this thread, do all this without
>>> any performance impact, compared to the current implementation.
>>>
>> Why should
Op 2004-12-22, Bengt Richter schreef <[EMAIL PROTECTED]>:
> On 21 Dec 2004 10:37:20 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>
>>Op 2004-12-18, Bengt Richter schreef <[EMAIL PROTECTED]>:
>>>>
>>>>As it turns out, python makes no dif
Op 2004-12-22, Fredrik Lundh schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>> But this was another subthread.
>
> oh, sorry, I was under the flawed assumption that the first few posts to a
> thread should be seen in the context of the original post.
So? In th
Op 2004-12-22, Jeff Shannon schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>>Op 2004-12-21, Jeff Shannon schreef <[EMAIL PROTECTED]>:
>>
>>
>>How does the dict know which value is associated with which key?
>>
>>
>>
>>
Op 2004-12-22, Jeff Shannon schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>>Op 2004-12-21, Jeff Shannon schreef <[EMAIL PROTECTED]>:
>>
>>
>>>Antoon Pardon wrote:
>>>
>>>
>>>So show us a dictionary (i.e. hash t
tested things out.
I don't think I would recommend adding hash methods to mutable builtins.
Storing keys by identity or value both can make sense for these kind
of objects. And since python prefers not to guess I think it is a good thing
there is no default hash for mutable objects.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
of that and doesn't warrant special
protection that is not available elsewhere in the language.
I don't understand why the ease of mutating an object that should remain
stable should cause more unease in a person just because the subject
is dictionary keys, except maybe because of custom.
But I'm obviously in the minority here.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
holds integer seem to work??
Because this only works with strings.
String is the only object in python which has an implied
equivallence between an element and a squence of one.
So one character is a string and a string is a sequence
of characters.
So 'a'[0] is again 'a
Op 2004-12-23, Ishwor schreef <[EMAIL PROTECTED]>:
> On 23 Dec 2004 14:28:37 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>> Op 2004-12-23, Ishwor schreef <[EMAIL PROTECTED]>:
>> > Hi all. Look at this snippet of code.
>> >
>> >>&
Op 2004-12-23, Scott David Daniels schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Op 2004-12-22, Jeff Shannon schreef <[EMAIL PROTECTED]>:
>>>The problem is that once the object has mutated, you *don't know* what
>>>bucket it used to sort in
Op 2005-03-18, Jeff Shannon schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Op 2005-03-16, Jeff Shannon schreef <[EMAIL PROTECTED]>:
>>
>>>Bruno Desthuilliers wrote:
>>>
>>>>- if x is a class attribute of class A and a is an instanc
a 'make' method.
dct.make(key, value) would be equivallent to dct[key] = value.
except that it would raise a KeyError if the key was
already in the dictionary.
What do other people think about this?
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
such.
Well you have my support for this. But I have the impression this
differs from the previous time you came up with a similar idea.
If IRC your previous proposal limited the search to the local
scope, making a := b equivallent to something like a; a = b.
I must say I like your current idea better.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-03-21, Robert Kern schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Well at least I find them missing.
>>
>> For the moment I frequently come across the following cases.
>>
>> 1) Two files, each with key-value pairs for the same dictionary.
Op 2005-03-21, Robert Kern schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>> I would say the same reason that we have get. There is no
>> reason to have a builtin get it is easily implemented
>> like this:
>>
>> def get(dct, key, default
Op 2005-03-21, Terry Reedy schreef <[EMAIL PROTECTED]>:
>
> "Antoon Pardon" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> For the moment I frequently come across the following cases.
>>
>> 1) Two files, each with key-value p
x,
your piece of code will then assign 0 to
z. Do you think that is what the original
code wanted?
> so where is the gain of using
> lambda or the mapping?
Is is usable as an argument.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-03-21, Jeff Shannon schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Op 2005-03-18, Jeff Shannon schreef <[EMAIL PROTECTED]>:
>>
>> I find it odd that you start by saying you still find them very
>> consistent and here state there is a slight
gt; > so where is the gain of using
>> > lambda or the mapping?
> Sorry, but I still can't see the advantage
> of lambda, at least not in this example.
The lambda would allow us to insert the
functionallity locally without the need
to an function that is define somewhere
else.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-03-22, Steve Holden schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Op 2005-03-21, Jeff Shannon schreef <[EMAIL PROTECTED]>:
>>
>>>Antoon Pardon wrote:
>>>
>>>>Op 2005-03-18, Jeff Shannon schreef <[EMAIL PROTECTED]>:
te, suddenly we should use short named functions.
Can someone who thinks this way, please explain why this is acceptable
[ x * x for x in some_iterator ]
But this is not
map(lambda x: x * x, some_iteraror)
and should be replaced with
def sqr(x): return x * x
map(sqr , some_iterator)
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-03-22, Bengt Richter schreef <[EMAIL PROTECTED]>:
> On 22 Mar 2005 07:40:50 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote:
> [...]
>>I also was under the impression that a particular part of
>>my program almost doubled in execution time once I replaced
>>
unction has been useful for me quite a few times,
> can't be replaced by listcomps, and frequently needs a callable consisting
> of only a single expression. So I'll continue to use lambdas there.
Then my question was not meant for you.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
This won't work of course, since n is int
>
> How do I send this msg + n?
Use string formatting:
msg = "Length is 0x%x" % n
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
the idea, but haven't worked anything out
since then.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-03-25, Paul Rubin schreef :
> Antoon Pardon <[EMAIL PROTECTED]> writes:
>> I started once, using the Timer class in the Threading Module to
>> break the lock. However the Timer class uses the same kind of
>> sleep-polling loop, to delay the exection and allow an
Op 2005-03-25, Paul Rubin schreef :
> Antoon Pardon <[EMAIL PROTECTED]> writes:
>> > I've never checked this code but it wouldn't have occurred to me that
>> > Queue uses any kind of timeout loop. Can't it work the obvious way
>> > with a sema
Op 2005-03-25, Paul Rubin schreef :
> Antoon Pardon <[EMAIL PROTECTED]> writes:
>> > I meant a semaphore to synchronize the queue when adding or removing
>> > objects.
>>
>> Last I looked there was a lock used for that.
>
> OK, that amounts to the sam
Op 2005-03-25, Tim Tyler schreef <[EMAIL PROTECTED]>:
> What do you guys think about Python's grouping of code via indentation?
>
> Is it good - perhaps because it saves space and eliminates keypresses?
I think it was a mistake, but I'm probably in the minority here.
-
Op 2005-03-25, John Roth schreef <[EMAIL PROTECTED]>:
>
> "Antoon Pardon" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> Op 2005-03-25, Tim Tyler schreef <[EMAIL PROTECTED]>:
>>> What do you guys think about Python's group
ore
> likely to easily follow the flow of the Python.
Not with my own code. The difference is not great but my C programs
have a slight edge here.
>> How would you have dealt with the issue of how to group statements?
>
> Having experienced Python, I can say pretty earnestly that, were I
> designing my own language, there is no other way I would do it.
> Grouping by indentation is a slam dunk for me.
Well to each his own.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
e
> liberal towards overriding builtins, which might appeal to you.
I have other problems with it. I have problems with all languages
currently available, so I use those which rub me wrong the least.
I think the indentation syntax of python was a mistake, but for
the most part it is a minor issue a
l the languages used either. Personnaly I find
difference in style a very minor issue compared to difference of
language or difference of development environment. If you so
much need the strict layout python imposes, I start to question
whether you are flexible enough for programming.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-03-25, Dennis Lee Bieber schreef <[EMAIL PROTECTED]>:
> On 25 Mar 2005 14:26:28 GMT, Antoon Pardon <[EMAIL PROTECTED]>
> declaimed the following in comp.lang.python:
>
>>
>> 1) It makes it hard to see how many levels are dedented at the end of
>
Op 2005-03-25, Terry Reedy schreef <[EMAIL PROTECTED]>:
>
> "Antoon Pardon" <[EMAIL PROTECTED]> wrote in message
>
>> 1) It makes it hard to see how many levels are dedented at the end of
>> a suite, and sometime makes it difficult to see where the end
Op 2005-03-25, Paul Rubin schreef :
> Antoon Pardon <[EMAIL PROTECTED]> writes:
>> Well maybe you could use an os.pipe as a timeout lock then. When the lock is
>> instantiated you put one byte in it. Aquiring the lock is implemented by
>> reading one byte, releasing
Op 2005-03-27, Joal Heagney schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>> So python choose a non-deterministic direction. To me (2,3) + (4,5)
>> equals (6,8). I don't dispute that having an operator to combine
>> (2,3) and (4,5) in (2,3,4,5) is
Op 2005-03-29, Paul Rubin schreef :
> Antoon Pardon <[EMAIL PROTECTED]> writes:
>> Well have a look at what I have written over the weekend. It uses
>> a seperate thread with one pipe for a wakeup mechanisme.
>
> Thanks, I'll look at it. Why don't you use us
Op 2005-03-29, Antoon Pardon schreef <[EMAIL PROTECTED]>:
> Op 2005-03-29, Paul Rubin schreef :
>> Antoon Pardon <[EMAIL PROTECTED]> writes:
>>> Well have a look at what I have written over the weekend. It uses
>>> a seperate thread with one pipe for a wakeup
Op 2005-03-29, Paul Rubin schreef :
> Antoon Pardon <[EMAIL PROTECTED]> writes:
>> I'm not going to call my solution simple, but it wastes very few
>> cycles. if no thread is blocked on a lock, the select will just
>> block until that changes. No need for some kin
Op 2005-03-29, Ville Vainio schreef <[EMAIL PROTECTED]>:
>>>>>> "Antoon" == Antoon Pardon <[EMAIL PROTECTED]> writes:
>
>Antoon> Op 2005-03-27, Joal Heagney schreef <[EMAIL PROTECTED]>:
> >> Antoon Pardon wrote:
> >&
urces
that are only available in a limited amount. Not usefull if you are
talking about thousands of threads.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
ents that the wrapper script was called by.
>>
>> Joal
>
> Aaaaggg. Too long since I've programmed in script. Plus it
> doesn't help changing your mind about implementation halfway through.
> The script should read something like this:
>
> ---
> #!/bin/sh
> if ! echo ${LD_LIBRARY_PATH} | /bin/fgrep -q "/path/to/your/library"
> then
> export LD_LIBRARY_PATH=$LD_LIBRARY_PATH":/path/to/your/library"
> fi
> $*
> ---
And you should change that last line to:
"$@"
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
just as
fine with network sockets. If someone want to rewrite the code
to do so and make the code more crossplatform, I'll happily
incorperate it. I'm just not familiar enough with sockets to do
it myself.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
ython development in this
area.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
there other things I have to
watch out for?
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-04-12, Steve Holden schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> I have made a module derived from the Queue module deliverd
>> with python 2.3. I would like to make this module (called
>> tube) available for other people. However it is not clear
&g
Op 2005-04-12, Robert Kern schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>> What licence can I use? Somewhere they say you can combine python
>> code with GPL code. Does that mean that the resulting code has
>> to have both the GPL license as the PSF license
Op 2005-04-13, Robert Kern schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Op 2005-04-12, Robert Kern schreef <[EMAIL PROTECTED]>:
>>
>>>Antoon Pardon wrote:
>>>
>>>
>>>>What licence can I use? Somewhere they say you
Op 2005-04-13, Robert Kern schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Op 2005-04-13, Robert Kern schreef <[EMAIL PROTECTED]>:
>
>>>Yes, the license text and the copyright notice must be attached. It
>>>doesn't mean that the PSF license i
Op 2005-04-13, Robert Kern schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Op 2005-04-13, Robert Kern schreef <[EMAIL PROTECTED]>:
>>
>>>Antoon Pardon wrote:
>>>
>>>>Op 2005-04-13, Robert Kern schreef <[EMAIL PROTECTED]>:
Op 2005-04-14, Robert Kern schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Op 2005-04-13, Robert Kern schreef <[EMAIL PROTECTED]>:
>>
>> I would do that if I were just writing code I thought others could
>> find usefull. I then would feel no problem &
Op 2005-04-14, Robert Kern schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Op 2005-04-14, Robert Kern schreef <[EMAIL PROTECTED]>:
>>
>>>Antoon Pardon wrote:
>>>
>>>>Op 2005-04-13, Robert Kern schreef <[EMAIL PROTECTED]>:
hings (write) on the queue or will get (read) things
from the queue (or both). Now what I want is that a thread that
opens the tube for read access will block until a thread opens
the same tube for write access.
The problem is how do I put such a requirement in a test case?
--
An
801 - 900 of 1820 matches
Mail list logo
