Op 2005-01-17, John Lenton schreef <[EMAIL PROTECTED]>:
>
>
> --vni90+aGYgRvsTuO
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Mon, Jan 17, 2005 at 11:41:20AM +, Antoon Pardon
Op 2005-01-17, Just schreef <[EMAIL PROTECTED]>:
> In article <[EMAIL PROTECTED]>,
> Antoon Pardon <[EMAIL PROTECTED]> wrote:
>
>> >> I don't see a big difference between these principles
>> >> and the hash key principle,
>> >
>
Op 2005-01-17, Steve Holden schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
> Mostly, though, I was trying to say that I found your nitpicking
> insistence on terminological exactitude, even when giving advice to
> those new to the language, both inappropriate and t
#x27;t* mutate, though. I'll have to think some more to see
> if
> I can come up with any concrete ideas for you to shoot down :)
Something else I was thinking about. I think it would be nice if the
python compilor could figure out whether a genexp in a list or tuple
expression always generates the same list or tuple and then instead
of generating code would generate the list or tuple in place.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-01-18, Simon Brunning schreef <[EMAIL PROTECTED]>:
> On 18 Jan 2005 07:51:00 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>> 3 mutating an item in a sorted list *does* *always* cause problems
>
> No, it doesn't. It might cause the list no longer to be sort
Op 2005-01-18, Steve Holden schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>> Op 2005-01-18, Nick Coghlan schreef <[EMAIL PROTECTED]>:
>>
>>>Raymond Hettinger wrote:
>>>
>>>>[Delaney, Timothy C]
>>>>
>>>>
Op 2005-01-18, Nick Coghlan schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> More specific the Decimal class is mutable and usable as dict key.
>
> It's *meant* to be immutable though. The fact that we used __slots__ instead
> of
> __setattr__ to impleme
effects or not. If the compilor
then would store a code in the byte code for functions that are
guaranteed side-effect free and only pregenerated objects generated
by expressions with no side-effect, some common subexpression
elimination could be done even in a non-functional language.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-01-18, Steve Holden schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>> Op 2005-01-18, Nick Coghlan schreef <[EMAIL PROTECTED]>:
> [...]
>> But don't use mutable keys is not a general principle. It is a principle
>> introduced by t
ended up
writing a parser for some kind of game instead of just dumping the
structure in textual form and doing an eval of the file when reading
it in. But if I need a parser I could just as well used a static
language.
I'm beginning to guess the dynamic aspect of python is ove
Op 2005-01-18, David Bolen schreef <[EMAIL PROTECTED]>:
> Antoon Pardon <[EMAIL PROTECTED]> writes:
>
>> Op 2005-01-18, Simon Brunning schreef <[EMAIL PROTECTED]>:
>> > On 18 Jan 2005 07:51:00 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>> &g
Op 2005-01-18, Bengt Richter schreef <[EMAIL PROTECTED]>:
> On 18 Jan 2005 13:28:00 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>
>>I have implemented a hash table when I was a student and its
>>implementation allowed the use of 'mutable' objects as a k
Op 2005-01-18, Jeremy Bowers schreef <[EMAIL PROTECTED]>:
> On Tue, 18 Jan 2005 14:05:15 +0000, Antoon Pardon wrote:
>> I don't see how generating byte code for a = 9; when seeing the
>> expression a = 3 + 6, would be a problem for non-functional
>> languages.
Op 2005-01-18, Steve Holden schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>> Op 2005-01-18, Steve Holden schreef <[EMAIL PROTECTED]>:
>>
>>
>>>Python is *designed* as a dynamic language. I wish you would embrace
>>>this aspect rathe
Op 2005-01-19, Nick Coghlan schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> A rule of thumb is context sensitive. If circumstances change,
>> so do the rules of thumb. Principles have a broader field
>> of application.
>>
>> IMO there is nothing
Op 2005-01-19, Nick Coghlan schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
> > I can be wrong, but until now I have seen no indication that I was
>> using mutable and immutable differently than other people. AFAICT
>> we all refer to whether an object belong
Op 2005-01-19, Steve Holden schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>> Op 2005-01-18, Steve Holden schreef <[EMAIL PROTECTED]>:
> [...]
>>
>> But you do have a point that I have a tendency to put salt on
>> any snail. I'
at is better than nested.
>>>
> [incrdeibly secret PSU facts blurted out]
>>
>> And with that out of the way, one is left with "there's a balance
>> along the flat/nested dimension which is appropriate to any
>> given situation, so nest with moderation and o
Op 2005-01-20, Nick Coghlan schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Interesting idea. But I think you are wrong when you say that two lists
>> that compare equal at the time they are frozen, will get the same
>> dictionary entry. The problem is an object m
Op 2005-01-20, Nick Coghlan schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> I missed that you would use it with the idiom: dct[x.frozen()]
>
> The list itself isn't hashable with this approach, so you don't have much
> choice. I wasn't particularly
Op 2005-01-21, Bengt Richter schreef <[EMAIL PROTECTED]>:
> On 20 Jan 2005 14:07:57 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>
> Would you like a dictionary that acts as you want and takes care of all
> problems internally, and accepts keys and values of any type wit
I'm writing some utilty functions for use with gtk. But
in order to use them correctly I have to know whether
they are called in the gtk-thread or an other.
So my idea was to wrap the gtk.main function so that
it would registrate the thread_id that called it.
So I was thinking about doing somethi
ects don't have a name. Why is it a problem doing something
like:
f = lambda: None
But isn't it a problem doing something like
v = None.
Why don't we demand something like
Py> assign v: None
Py> v.obj_name
'v'
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
t2:st3:st4:st5".split(':',2)
["st1" , "st2" , "st3:st4:st5"]
This behaviour would remain but additionally we would have the
following.
>>> "st1:st2:st3:st4:st5".split(':',-2)
["st1:st2:st3" , "st4" , "st5"]
What do people think here?
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-01-28, Fredrik Lundh schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>> This behaviour would remain but additionally we would have the
>> following.
>>
>>>>> "st1:st2:st3:st4:st5".split(':',-2)
>> ["st1:st
if no exception was seen.
You equally can't test which branch of an if statement was taken or
which parameter was given to a helper function in order to get to
the desired result.
That you internally raise an exception and catches it, is an
implementation detail, that normally is of no concer
Op 2005-01-28, StepH schreef <[EMAIL PROTECTED]>:
> Antoon Pardon a écrit :
>> Op 2005-01-28, StepH schreef <[EMAIL PROTECTED]>:
>>
>>>Thanks for you answer.
>>>I'm new to Python (coming from C/C++).
>>>
>>>Do you say that i
e would be incorrect in other circumstances doesn't
make it invalid as it was used in a specific situation.
I have written code my self with an "if var is True" statement and
that is exactly what I wanted. Replacing it with "if var" would
have broken the the program.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
ean.
> Better is:
> result = [(lambda: true_expr), lambda: false_expr][not cond]()
How about the following:
result = (cond and (lambda: true_expr) or (lambda: false_expr))()
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
x27;s
> a language that makes TMTOWTDI a way of life.
There are always many ways to do things, and depending on circumstances
the best way to do something may differ every time.
So if python no longer allows multiple ways to do things, it won't help
the programmer. The programmer
itiple obvious ways,
which seems to be one of the goals here, will result in removing
the one obvious way for doing other things.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
ut sometimes I get the impression people want it to evolve
so it is only for mediocre programmers.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
ure will make my job more difficult.
3) I don't understand the merrits of the feature or I
have difficulty understanding what it does when I
encounter it.
IMO these are arguments if followed sufficiently will lead to
a language that is only usefull for mediocre programmers.
> Antoon
The if test is unnecessary. Should a be smaller than b, the two values
will be swapped by the while body.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
s it doesn't make
sense to talk about a gcd if not all numbers are positive.
I would be very interested if someone knows what the gcd
of 3 and -3 should/would be.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
t how it is
implemented in python, is that you only have access to module
scope and not to intermediate scopes.
I also think there is another possibility. Use a symbol to mark
the previous scope. e.g. x would be the variable in local scope.
@.x would be the variable one scope up. @[EMAIL PROTECTED] would be the
variable two scopes up etc.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
x27;t need it if
> you aren't rebinding the name.
This doesn't answer the question at the appropiate level IMO.
Why has one made a difference in search policy for finding a
variable based on whether the variable is rebound or not
in the first place.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-08-16, Peter Hansen schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Why has one made a difference in search policy for finding a
>> variable based on whether the variable is rebound or not
>> in the first place.
>
> Do you really not understand the
one - will test "false",
But '', {}, [] and () are not nothing. They are empty containers.
And 0 is not nothing either it is a number. Suppose I have
a variable that is either None if I'm not registered and a
registration number if I am. In this case 0 should be treated
as any other number.
Such possibilities, make me shy away from just using 'nothing'
as false and writing out my conditionals more explicitly.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-08-19, Donn Cave schreef <[EMAIL PROTECTED]>:
> In article <[EMAIL PROTECTED]>,
> Antoon Pardon <[EMAIL PROTECTED]> wrote:
> ...
>> But '', {}, [] and () are not nothing. They are empty containers.
>
> Oh come on, "empty" is
this a very poor reason for this decision.
Sure it is a hard to find bug. but that is not because the
assignment is also an expression but because the assigment operator
looks so much like an equality comparator. ':=' was already in use
as an assignment is a number of languages and using it woul
Op 2005-08-22, Steve Holden schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Op 2005-08-19, Donn Cave schreef <[EMAIL PROTECTED]>:
>>
>>>In article <[EMAIL PROTECTED]>,
>>> Antoon Pardon <[EMAIL PROTECTED]> wrote:
>>>
Op 2005-08-22, Magnus Lycka schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>>>Python doesn't guess. There are a range of values that will be treated,
>>>in a Boolean context (how perlish) as equivalent to False.
>>
>> Yes it does.
>
>
t
and PASCAL does have a real BOOLEAN type.
So where she gets the idea that "if var == True" is a symptom of a
language that has no real BOOLEAN type (as python now has IHO) is
beyond me.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-08-23, Magnus Lycka schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Following a well defined specification is not contradictory
>> to guessing. It may just mean that the guess was formalized
>> into the specification.
>
> If you want the behaviou
Op 2005-08-23, rafi schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>> In that case you wouldn't return an empty sequence if you wanted
>> a false value in a sequence context but would throw an exception.
>> So this would be fine by me, I just don't
Op 2005-08-23, Sybren Stuvel schreef <[EMAIL PROTECTED]>:
> Antoon Pardon enlightened us with:
>> The problem with interpreting empty as false is that empty just
>> means no data now. But no data now can mean no data yet or it can
>> mean no more data. The problem is
Op 2005-08-24, Magnus Lycka schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Such a PEP would have no chance of being accepted, since
>> it would break to much existing code.
>
> What's the point of this thread then?
I only hope to impress people that the
Op 2005-08-24, Magnus Lycka schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> I think he did, because both expression are not equivallent
>> unless some implicite constraints make them so. Values where
>> both expressions differ are:
>>
>> start1=67
Op 2005-08-25, Steve Holden schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Op 2005-08-24, Magnus Lycka schreef <[EMAIL PROTECTED]>:
>>
>>>Antoon Pardon wrote:
>>>
>>>>I think he did, because both expression are not equivallent
&
s" of python come together.
that create an awkward situation.
1) 0 is a false value, but indexes start at 0 so you can't
return 0 to indicate nothing was found.
2) -1 is returned, which is both a true value and a legal
index.
It probably is too late now, but I always felt, find
y implented find is better than an index.
If we only have index, Then asking for permission is no longer a
possibility. If we have a find that returns None, we can either
ask permission before we index or be forgiven by the exception
that is raised.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
of a program have to work together.
So what happens if you have a module that is collecting string-index
pair, colleted from various other parts. In one part you
want to select the last letter, so you pythonically choose -1 as
index. In an other part you get a result of find and are happy
with -1 a
Op 2005-08-29, Steve Holden schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Op 2005-08-27, Steve Holden schreef <[EMAIL PROTECTED]>:
>>
>>>>
>>>If you want an exception from your code when 'w' isn't in the string you
>>
Op 2005-08-29, Steven Bethard schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> I think a properly implented find is better than an index.
>
> See the current thread in python-dev[1], which proposes a new method,
> str.partition(). I believe that Raymond Hetting
ctionality.
Because I sometimes find it usefull to have a sequence start and
end at arbitrary indexes, I have written a table class. So I
can have a table that is indexed from e.g. -4 to +6. So how am
I supposed to easily get at that last value?
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
3], [4, 5]])
> A[$-1, $-1]
>
> The result of len(A) has nothing to do with the second $.
But that is irrelevant to the fact wether or not sane
programmes follow Bryan's stated rule. That the second
$ has nothing to do with len(A), doesn't contradict
__len__ has to be implemented nor that sane programers
already do.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-08-30, Steve Holden schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Op 2005-08-29, Steve Holden schreef <[EMAIL PROTECTED]>:
>>
>>>Antoon Pardon wrote:
>>>
>>>>Op 2005-08-27, Steve Holden schreef <[EMAIL PROTECTED]>:
Op 2005-08-30, Bengt Richter schreef <[EMAIL PROTECTED]>:
> On 30 Aug 2005 10:07:06 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>
>>Op 2005-08-30, Terry Reedy schreef <[EMAIL PROTECTED]>:
>>>
>>> "Paul Rubin" <"http://p
Op 2005-08-31, Bengt Richter schreef <[EMAIL PROTECTED]>:
> On 31 Aug 2005 07:26:48 GMT, Antoon Pardon <[EMAIL PROTECTED]> wrote:
>
>>Op 2005-08-30, Bengt Richter schreef <[EMAIL PROTECTED]>:
>>> On 30 Aug 2005 10:07:06 GMT, Antoon Pardon <[EMAIL PROTE
ed
and that got implemented.
A ternary operator (or suitable generalisation) would IMO
provide a greater improvement what readability is concerned
but is resisted all the way.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-09-08, Duncan Booth schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>> Which is why I don't understand the resistance against introducing
>> such a beast.
>
> The idea has already been discussed to death. Read PEP 308 to see what was
> pr
o create a new list.
The extend method could just have returned self. Just as sort and reverse could
have done so. This would have made it possible to do things like the following:
lst.sort().reverse()
instead of having to write:
lst.sort()
lst.reverse()
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-09-09, Christophe schreef <[EMAIL PROTECTED]>:
> Antoon Pardon a écrit :
>>>Because creating a new list is potentially very time-consuming and
>>>expensive of memory. Imagine you have a list of 100,000 large objects, and
>>>you want to add one more o
> return 0
>
>
> after i invoked
> t = thread.start_new_thread(foo,(12,))
> how to get the return value of `foo'?
>
> Thanks
>
Maybe you should have a look at the Future class
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/84317
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
, are done so to make a point. The example itself
may never been used in actual code, but code that is similar enough
in behaviour, may. Try to look at the argument one is trying to make
instead of looking at insignificant details.
> If you want to go and argue with Guido over this, go ahead. I'm all
> for a ternary operator.
>
> But IIRC, that parrot is dead. It's an ex-parrot.
Yes probably, but the fact that it is a dead parrot, doesn't make
the idea bad. I sometimes get the impression that just because
Guido declared a subject dead, some people feel obligated to
argue how bad it would have been anyway.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
expressing the different behaviour
as a change in round, suggest that the O.P. would be wise to
learn about floating point problems
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-09-14, Robert Kern schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Op 2005-09-13, Robert Kern schreef <[EMAIL PROTECTED]>:
>>
>>>Jeremy Sanders wrote:
>>>
>>>>Nils Grimsmo wrote:
>>>>
>>>>>Why d
ink of
how they could code some of their thought processes, which
would be a more fruitfull experience as programming this
with backtracking.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
e only way to solve arbitrary sudoku problems is to guess.
That is strange, in al the puzzles that I have solved untill now,
I never needed to guess, unless the puzzle had multiple solutions,
which personnally I find inferior.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
isely fit your
> nano-tube-narrow mindset.
I think this is unfair. The use of "slash" is a failing of the current
documentation. If his use is an indication of a nano-tube-narrow
mindset then so would be the use by the actual documentation writers.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-09-21, Tom Anderson schreef <[EMAIL PROTECTED]>:
> On Mon, 19 Sep 2005, Antoon Pardon wrote:
>
>> Op 2005-09-17, Tom Anderson schreef <[EMAIL PROTECTED]>:
>>> On Fri, 16 Sep 2005, Bas wrote:
>>>
>>>> -any ideas how to easily incorpo
gt;>
>> Assuming you mean threading.Thread, this is a native thread. It is not a
>> simulation. Something else is going wrong.
>
> Then I must have something locked. Here's what I do:
Yes you have locked the GIL. Take a look at the following
URL: http://docs.python.org/api/threads.html, hope it helps.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
such and that
methods had there own keyword. That would make the magic of
bound methods more explicit.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
on't slow down the code as the
checking will have been done during the compilation phase. It
may even speed up code like this, because the compilation
phase will have established that it is a rebinding and so
code for testing whether a new variable is created or not
is not necessarry here.
--
hy did
you use it? I find it odd that someone who prefers to use it in a
language where it is optional is argues that it shouldn't be included
as an option is an other language. I would think that if he thinks
it so bad he wouldn't use it in that other language in the first place.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-02-07, Nick Coghlan schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Op 2005-02-05, Nick Coghlan schreef <[EMAIL PROTECTED]>:
>>
>>
>>>[ ... ]
>>>
>>>With a rebinding operator, the intent of the last line can be mad
Op 2005-02-07, Alex Martelli schreef <[EMAIL PROTECTED]>:
> Antoon Pardon <[EMAIL PROTECTED]> wrote:
>
>> Op 2005-02-06, Alex Martelli schreef <[EMAIL PROTECTED]>:
>> >
>> >> Isn't that inconsistent?
>> >
>> > That Pyth
Op 2005-02-07, John Lenton schreef <[EMAIL PROTECTED]>:
>
>
> --cvVnyQ+4j833TQvp
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Mon, Feb 07, 2005 at 02:53:49PM +, Antoon Pardon wrot
Op 2005-02-07, Alex Martelli schreef <[EMAIL PROTECTED]>:
> Antoon Pardon <[EMAIL PROTECTED]> wrote:
>
>> Yes it is inconsistent with the rest of python. That you found
>> a subset in which it is consistent doesn't change that.
>>
>> An
Op 2005-02-08, Nick Coghlan schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:ons already existing.
>> The compilor might generate a RESTORE instruction.
>
> Whether it is done as a LOAD/STORE or a RESTORE, it has to perform the same
> work
> - check the name exists
Op 2005-02-08, Nick Coghlan schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> I have the impression you are looking at this too much from the view
>> of the current implementation where putting a an entry in
>> a directory is seen as an atomic operation.
>
>
then the current versions with a
callback.
So I was wondering, are such transformations in the pipeline
somewhere?
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
not,
is not a good way to remove such a stumbling block.
> Why don't you pick something that really bothers people and see if your
> skills (that I'm sure exist) can be of use there?
This did bother someone, it was a stumbling block for him understanding
what was going on.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
methought
I think I may understand why things go wrong, but I certainly
don't understand the result I got. I would think an error like:
TypeError: call() takes exactly 2 arguments (1 given)
would have been more appropiate.
Am I missing something?
Is it a bug?
Maybe both?
--
Antoon Pardo
use
> that try: except: of yours:
Ah, yes, the penny dropped. The try: except where there because
originally there were other statements I wanted to test and I
didn't want the raise exception by the inc(-2) stop the script.
I completely forget to consider it would also catch the
error I was expecting.
Thanks.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
without such notice is thread-safe?
I doubt it. There is no indication that the email package uses any
kind of locking. So multiple thread working on the same message
will probably screw things up.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-02-09, Roman Suzi schreef <[EMAIL PROTECTED]>:
> On Wed, 9 Feb 2005, Antoon Pardon wrote:
>
>> Op 2005-02-09, Roman Suzi schreef <[EMAIL PROTECTED]>:
>>>
>>> Just to be sure, is email package of Python 2.3 thread-safe or not
>>> (to use,
Op 2005-02-09, Delaney, Timothy C (Timothy) schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>
>> Ah, yes, the penny dropped. The try: except where there because
>> originally there were other statements I wanted to test and I
>> didn't want the raise excep
. That would make the declaration
explicit instead of being implicit now and explicit is better than
implicit.
Of course the other solution, simply removing the declarative effect from
assignments, could work too and might even be preferable but I fear
it would produce strange behaviour.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-02-09, Nick Coghlan schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Op 2005-02-08, Nick Coghlan schreef <[EMAIL PROTECTED]>:
>>>The CPython *_FAST opcodes relate to functions' local variables. Behind the
>>>scenes they are implemented as
Op 2005-02-10, Nick Coghlan schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Well it seems you have some fair points. I'll just stop here stating
>> that I would like to have it, even if it proved to be slower. Speed
>> is not that big a factor in the thin
rogram
> will stop. An alternative is to return an error flag in addition to y
> and z from function foo and check the value of the error flag in the
> calling program. This seems a bit awkward.
what about the following.
def foo(x):
# code setting y and z
return x,z
try
y,z = f
on't meet this behaviour or more specifically
floats don't guarantee this behaviour. It depends of course on
your implementation of f, but it is possible with floats to keep
incrementing and never reach a maximum.
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Try this:
def fA(input):
return input
def newFA(input, f= fA):
return f(input)
fA = newFA
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
ect.
I'm not so sure about that. Take the following code:
>>> class A:
... def m():
... pass
...
>>> a = A()
>>> u = a.m
>>> u is a.m
False
If bound methods were created at instance creation one would expect
a True result here instead of False.
g it in the objects
> dictionary is what happens.
>
No. What happens is that functions are descriptors. So if you
assign a function to a class attribute any access to this
attribute will call the __get__ method which will create a
bound method if the access was through an instance or an
u
te a *named* function.
So and if I have code like this:
f = lamda x:x
for g in some_iter:
f = compose(g,f)
Do you still think that one should use a named function in this case?
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
articular case yes. But not in general, what about
this:
>>> def F():
... l = []
... def pop():
... return l.pop()
... def push(e):
... l.append(e)
... return pop, push
...
>>> pop, push = F()
>>> push(1)
>>> pop()
1
>>> push(2)
>>> push(3)
>>> pop()
3
>>> pop()
2
--
Antoon Pardon
--
http://mail.python.org/mailman/listinfo/python-list
Op 2005-02-21, jfj schreef <[EMAIL PROTECTED]>:
> Antoon Pardon wrote:
>> Op 2005-02-19, jfj schreef <[EMAIL PROTECTED]>:
>>
>>>once foo() returns there is no way to modify 'x'!
>>>It becomes a kind of constant.
>>
>>
>
701 - 800 of 1820 matches
Mail list logo
