many uses of Perl
|> What exactly did you "hear" of several "uses"? Which
|> application? Academia, Business, ...?
Mainly academic research, but that still covers many fields.
However, I am not and never have been a 'pure' academic, and
am as interested in oth
hat is going on.
Any pointers appreciated, to more-or-less anything.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
mprove the reliability. Well, it could also
be one where failure becomes LESS likely the longer the server stays up
(i.e. the "settling down" problem).
No problem is as hard to find as one where you are firmly convinced that
it is somewhere other than where it is.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
is fine but "it can't
|> theoretically be fixed" is no solution.
I suggest that you do invest in a little learning and look up Poisson
processes.
|> Keep your eye on the goal and your more likely to score!
And, if you have your eye on the wrong goal, you would generally be
b
^^
|> before its likely to go down doesn't take too long, compared to your
|> exploration of the problem, and, of course, you have to be able to
|> afford the glitch in availability.
Consider the marked phrase in the context of a Poisson pr
o the square of the
activity, sometimes a higher power.
Virtually nothing involved does any routine logging, or even has
options to log relevant events.
The first means that the strategy of restarting doesn't help. All
three mean that current logs are almost never any use.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
;t live in one. Until you have identified the cause,
you can't tell if threading has anything to do with the failure - given
what we know, it seems likely, but what Aahz says is how to tackle the
problem WHATEVER the cause.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
on defects and flaws in the
standards are likely to show up in very obscure ways; ones due to
programmer error tend to be much simpler.
If you want to contact me by Email, and can describe technically
what you are doing and (most importantly) what you are assuming, I
may be able to give some hints. But no promises.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
are flawed, not that the threads underneath you
|> are buggy.
I suggest that you find out rather more about the ill-definition of
POSIX threading memory model, to name one of the better documented
aspects. A Web search should provide you with more information on
the ghastly mess t
|> safe or unsafe?
Unsafe. They are built on top of unsafe primitives (POSIX, Microsoft
etc.) Python will shield you from some problems, but not all.
There is precious little that you can do, because the root cause is
that the standards and specifications are hopelessly flawed.
Regards,
Nick Mac
the bottom. Rather
like an appendix. But top-posting when you are responding to Email
is as discourteous as top-posting when you are responding to newsgroups.
|> So I concede the point, and I'm bottom-posting like a good citizen. =20
Excellent!
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
lready deprecated.
And top posting is only more convenient if you are merely adding a
"me, too" or equivalent, and not responding in detail.
But you have been told both of those before.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
d find something, because the vulnerability
|> is so well known for ages.
Not really. There are LOTS of vulnerabilities that have been known
for ages and are still legion. The reason that this is unlikely is
that it is both easy to spot and trivial to fix.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
_CREAT). I can't
remember which - perhaps AIX or OSF/1 (not DEC).
But I was referring to a different problem. Some remote and parallel
filing systems handle such things very badly, and it is often possible
to create a file even if it exists and O_CREAT|O_EXCL is set. A similar
remark appl
nyone who used
MVS (which are NOT the ones claimed by the Unix brigade, which are mostly
bogus) :-)
Under Linux, you can do something with fuser, and I am pretty certain that
modern Macintoshes (i.e. BSD) will have an equivalent. It can't be made
reliable (unlike under MVS), but might reduce the number of problems.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
't be 100% reliable on all
systems.
Sorry. But that is the situation :-(
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
nging instances. From a practical point of view I would
|> say: "Just redefine it". But that is not very helpful. Specially if you are
|> mucking about in C, as your title suggests...
Thanks. As someone else posted, the answer is PyDict_SetItemString
immediately after PyType_Ready.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
very easily provide
the latter.
Is there any documentation on the coercion function (nb_coerce)? It
seems to have unusual properties.
Thanks for any hints.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
ance...
Oh, one of the first two - I am not bonkers! Changing a class after
instance creation is guaranteed to cause confusion, if nothing else.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
Hmm. The extensions documentation describes how to add instance
members to a class (PyMemberDef), but I want to add a class member.
Yes, this is constant for all instances of the class.
Any pointers?
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
oth the problem and global
optimisation.
This is why the "statistical" methods (so disliked by Kahan) are used.
In a fair number of cases, they give reasonable estimates of the error.
In others, they give a false sense of security :-(
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
t; past an experiment.
As the same is true for what plenty of people have done, despite them
having good backgrounds in mathematics, don't feel inferior!
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
applications. In 30 years, it
has got almost nowhere.
Don't confuse interval methods with interval arithmetic, because you
don't need the latter for the former, despite the claims that you do.
|> For people just getting into it, it can be shocking to realize just how
|> wide the
an exception if a 1 ULP change in the floating-
point number would give a different answer; this is needed to make
certain operations reliable.
The default formatting does the obvious thing :-)
Er, that's about it
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
cent encapsulation.
The decimal floating-point brigade grossly exaggerate the difficulty of
doing that, in order to persuade people that their solution is better.
If they admitted the difficulties of using decimal floating-point, and
merely said "but, overall, we think it is a better solution
tware and throw a switch
selecting between the two rounding rules.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
t of the base.
So, at a wild guesstimate, 64-bit decimal will deliver a precision
comparable to about 56-bit binary, and will cause significant numerical
problems to a FEW applications. Hence people will have to convert to
the much more expensive 128-bit decimal format for such work.
Bloatware rules. All your bits are belong to us.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
width). Python could, probably.
However, that isn't what the Decimal module does anyway. People will
specify more digits than they possibly need, not realising that they
need to specify many MORE if they are going to support multiplication.
Coming back to the start, is fixing that little
it was used on the old, discrete-logic, machines.
I have been told by hardware people that implementing IEEE 754 rounding
and denormalised numbers needs a horrific amount of logic - which is
why only IBM do it all in hardware. And the decimal formats are
significantly more complicated.
What
ow!".
Oh, because it's not a proper data type! The data type is an expression,
and is held in a structured form, of which such powers may be one level.
This is better regarded as an optimisation of a common case than a true
data type. Now, there MAY be such a language that supports such
ATING-point
helps with providing that, but that claim is extremely dubious.
I can explain the problem in as much detail as you want, but would
very much rather not.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
anipulated appropriately.
Yes, I know that's "cheating" :-)
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
her one can replace the other,
So far, so good. With reservations, I agree.
|> but there are more use
|> cases for Decimal than for Rational.
That is dubious, but let's not start that one again.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
In article <[EMAIL PROTECTED]>,
Carsten Haese <[EMAIL PROTECTED]> writes:
|> On Thu, 2007-01-11 at 23:47 +, Nick Maclaren wrote:
|> > In article <[EMAIL PROTECTED]>,
|> > Facundo Batista <[EMAIL PROTECTED]> writes:
|> > |> Noud Aldenhoven wrote
st enough for real work by someone who
is not deeply into developing Grid software, I will be amazed.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
e the last
bit to 1. An old, cheap approximation to rounding.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
- like rational,
it would be straightforward to add to Python as an extension type.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
reasons why what seems to be a more heavyweight mechanism (message
passing) can be faster than an apparently lightweight one (data sharing)
are both subtle and complicated.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
n primitives, and
threading models like OpenMP and BSP have explicit control.
Also, MPI has asynchronous (non-blocking) communication.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
and others forcing "consistency" (which is
not actually defined, and there are many possible, incompatible,
interpretations). It leaves all language aspects (including allowed
code movement) to C.
There are no concepts in common between C's and POSIX's consistency
specifica
for a couple of decades. Indeed, a lot of
modern programmers regard having to distort simple expressions in that
way as anathema.
It isn't a major issue, because our experience from then is that it is
both teachable and practical, but it IS a way in which any base above
2 is significantly worse than base 2.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
HPC system in UK academia for a decade,
ending less than a year ago, incidentally, and was and am fairly well
in touch with what is going on in HPC world-wide.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
ONCEPTS in common between
POSIX and C's memory consistency 'specifications' is perhaps the worst.
That is why many POSIX threads programs work until the genuinely
shared memory accesses become frequent enough that you get some to the
same location in a single machine cycle.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
e.
They use it for the communication, but don't expose it to the
programmer. It is therefore easy to put the processes on different
CPUs, and get the memory consistency right.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
ith difficulty). Debugging
and tuning OpenMP and POSIX threads are beyond anyone except the most
extreme experts; I am only on the borderline of being able to.
The ASCI bunch favour Co-array Fortran, and its model matches Python
like a steam turbine is a match for a heart transplant.
[*] They are worth looking up, if you don't know about them.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
ded programs. Yes, I know
that it is a bit Irish for the best way to use a shared memory system
to be to not share memory, but that's how it is.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
reak
b = c
else :
if c == a :
break
a = c
That works in binary, but in no base above 2 (assuming that I haven't
made a stupid error writing it down). In THAT case, it is easy to fix
for decimal, but there are ways that it can show up that can be quite
tricky to fix.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
tr(some_float) and repr(some_float) and why str(some_tuple) uses the repr()
of
|> its elements.
Precisely. And it also applies to strings, which I had failed to
notice:
>>> print ("1","2")
('1', '2')
>>> print "1", "2"
1 2
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
2.0) are necessarily within the range
(x,y) in decimal, even for the most respectable values of x and y.
This was a MAJOR "gotcha" in the days before binary became standard,
and will clearly return with decimal.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
atter entirely, and will merely
confuse you. I have a course on computer arithmetic, and am just
now writing one on Python numerics, and confused people may contact
me - though I don't guarantee to help.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
uot;, "de f,", "gh), i")
|>
|> would be extremely confusing if the current behaviour was changed. See
|> http://www.python.org/sf/1534769
|> for details.
Well, I wasn't complaining - merely querying.
If this approach is taken, it would be better to document
ay".
Not at all. "Precision" has been used to indicate the number of digits
after the decimal point for at least 60 years, probably 100; in 40 years
of IT and using dozens of programming languages, I have never seen
"display" used for that purpose.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
olved in a religious
war over - I was merely puzzled as to the odd behaviour, because I have
to teach it, and it is the sort of thing that can confuse naive users.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
In article <[EMAIL PROTECTED]>, Fredrik Lundh <[EMAIL PROTECTED]> writes:
|> Nick Maclaren wrote:
|>
|> > The use of different precisions for the two cases is not, however,
|> > and it is that I was and am referring to.
|>
|> that's by design, of course
In article <[EMAIL PROTECTED]>,
Bjoern Schliessmann <[EMAIL PROTECTED]> writes:
|> Nick Maclaren wrote:
|>
|> > Ah! That explains it. I would call that reason intermediate
|> > between rational and an artifact of the way the code has evolved!
|>
|> Whi
rational and an artifact of the way the code has evolved!
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
x = (1.234567890125, 1.2345678901255)
print x
print x[0], x[1]
>>> (1.234567890124, 1.2345678901254999)
>>> 1.23456789012 1.23456789013
Is there a rational reason, or is that simply an artifact of the way
that the code has evolved? It is clearly not a bug :-)
Rega
In article <[EMAIL PROTECTED]>,
"Hendrik van Rooyen" <[EMAIL PROTECTED]> writes:
|> "Nick Maclaren" <[EMAIL PROTECTED]> wrote:
|>
|> > Not at all. I didn't say that they came in pairs. Consider:
|> >
|> > [str1, str2, ag
ing to the mind of anyone who sees the terms, most
especially if they are familiar with their use in other areas of computing
and mathematics.
But, given that meaning, I now understand your point.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
3, agent2, agent3, agent4, str4, ...]
See Algol 68 for an example of this.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
;t have all the
|> features you want.
Which is tantamount to saying that Python doesn't support mutable
heterogeneous sequences, even though they are not locked out. That
is more than just odd - it is almost unbelievable. They are a very
basic data structure, after all!
Regards,
Nick Mac
you. Just as you can use a string as a list. We
|> don't have to be rigid to appreciate the difference. :)
Nope. That is DEFINITELY wrong. If you write code that abuses a
language construct in a way that is discouraged but just happens to
work, a couple of decades down the line it wi
type the "lists are intended to
be homogenous" people use to implement mutable heterogenous sequences,
or whether they claim that wanting such a feature is heresy :-)
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
In article <[EMAIL PROTECTED]>,
greg <[EMAIL PROTECTED]> writes:
|> Nick Maclaren wrote:
|>
|> > Unfortunately, you are confusing the issue, because there are far
|> > more extraneous aspects than relevant ones, and your view of the
|> > similarities req
n analogy between.
Unfortunately, you are confusing the issue, because there are far
more extraneous aspects than relevant ones, and your view of the
similarities requires looking at the issue in a very strange way.
I think that I can see what you mean, but only just.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
in Python terms, because
|> Python doesn't formally embody the concept. But that
|> doesn't mean the concept isn't real.
Of course the concept is real, but the point is that Python doesn't
embody the concept of homogeneity in lists, formally or informally,
as far as I kno
f course then we would have
|> to define necessary...
It's not necessary :-) Lists, in Python, are no more homogeneous than
tuples in any sense that I have located. As I posted earlier, if
anyone knows of one, please tell me.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
cantly. Python has chosen
not to do that.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
ple. If a heterogeneous list
just happens to have objects that are all similar, does it remain
heterogeneous?
Loose guidelines are very useful, but should almost always come with
the rider "Follow these unless you have good reasons to ignore them,
but do make sure that you understand the rules fir
with that. I consider the difficulty of adding a reliable
immutable attribute in most languages to be a serious piece of
misdesign, but there isn't a huge amount of point unless it is done
properly. Unreliable safety devices are as likely to increase
errors as reduce them, at least in the han
ll.
[ Incidentally, my use was in argument decoding, where the Python layer
holds the arguments as strings, and I need to pass them as an index to C
(so they DO form a respectable tuple even in Guido's sense, being fixed
in number and value and just happening to be homogeneous). ]
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
of entities where
there is no definable concept of equivalence between entities, and
Python has no such entities as far as I know.
Guido's response is fine - we didn't because we didn't think that it
was worth doing. One can dissent, but it makes perfect sense.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
lace you put the subscription method, clearly. I really
don't see the problem. I can see that it has not been done because
Guido and others felt that it wasn't worth doing, but not that it is
hard to do.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
rom the horse's mouth, will clear
|> things up once and for all...
|>
|> http://www.python.org/search/hypermail/python-1992/0285.html
Wonderful! Thanks. Yes, that does. It makes perfect sense. I did
say that I thought it would be a rarely used feature :-)
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
In article <[EMAIL PROTECTED]>,
"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
|> Nick Maclaren wrote:
|>
|> > If lists are intended to be homogeneous, then they should be checked
|> > for that, and an exception raised when an attempt is to make them
|>
dum
on Usenet.
The point is that an index method makes sense on ANY data structure that
can be subscripted by an integer value but, for reasons that aren't at
all clear, is not defined for Python tuples. There is no technical or
mathematical reason why it shouldn't be.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
have dual properties - and are true duals if you
include the constraint of no duplicate elements.
I remain baffled. I accept the explanations, but what I am now
confused by is the reason for the explanations
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
ove or add things to tuples is an even
|> bizarrer restriction!
Eh? Why?
My understanding of the difference between a tuple and a list is
PRECISELY that the former is immutable and the latter mutable.
But an index method makes precisely as much sense on an immutable
sequence as it does on a mutabl
Why doesn't the tuple type have an index method? It seems such a
bizarre restriction that there must be some reason for it. Yes,
I know it's a fairly rare requirement.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
In article <[EMAIL PROTECTED]>,
"Michele Simionato" <[EMAIL PROTECTED]> writes:
|> Nick Maclaren wrote:
|> > It would be much cleaner not to have to fiddle with static
|> > members after the class is initialised.
|>
|> You can hide the fiddling,
x27; of class (A).
There are several ways of doing this in Python, but I can't find
any that are as transparent to the user as I would really like.
There is method in my madness :-)
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
r the class is initialised.
|> Alternatively you can play tricks with metaclasses for a similar effect.
Well, I am already doing that, and regretting the fact that Python
doesn't seem to allow a class instantiation to return a new class :-)
What I am trying to do is very simple, but is s
t won't
be used until after the class has been created properly. Actually,
it won't be used except to test for class equivalence, but I may
want to extend later.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
s a Bessel function?;)
Some people use them all the time; there are specific physical problems
where they are fundamental. I have never used them, in 40 years of
wide-ranging experience in the scientific computing arena!
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
ress are worth pursuing. One of the main reasons that
'program proving' has never taken off outside its cabal is that it
uses bizarre notations unlike anything else on earth that can't be
edited in a normal fashion.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
always do.
|> I wasn't talking about FIFOs. Even if I was, they _are_ still subject to
|> regular file permissions (on Linux, at least).
They aren't on most Unices - Linux is not UNIX, you know :-)
I shall not respond further on this.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
t ones), and
excluding the systems that are not based on or largely cloned from
Unix. You should look at the POSIX facilities, but don't rely on
them without checking.
Also think very carefully whether you want to separate by user or
job - the latter is trickier under Unix.
Regards,
Nick Macla
gree, and depend on the system, configuration and program that
is listening on that port.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
; "" as the second argument to compile:
|>
|> http://pyref.infogami.com/compile
And the reason that it does that is because it is using one of the standard
conventions for naming stdin. Python didn't INVENT that convention, you
know.
The bug isn't in passing an information string "" but in using
that string (which is not meant to represent a real file) to perform a
file search.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
In article <[EMAIL PROTECTED]>,
Fredrik Lundh <[EMAIL PROTECTED]> writes:
|> Nick Maclaren wrote:
|>
|> > It's definitely worth fixing, but not as a high priority. Invoking a
|> > file spuriously is potentially serious, with very low probability.
|>
|>
x27;fred'. strace
or equivalent shows up clearly what the bug is.
|> I don't know whether this is worth fixing.
It's definitely worth fixing, but not as a high priority. Invoking a
file spuriously is potentially serious, with very low probability.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
In article <[EMAIL PROTECTED]>,
"Simon Forman" <[EMAIL PROTECTED]> writes:
|> Nick Maclaren wrote:
|> ...
|> > Create a file called '' in your current directory containing
|> > 'print "Oh, yeah?\n"' and then import a modul
here for a while.
Create a file called '' in your current directory containing
'print "Oh, yeah?\n"' and then import a module that doesn't exist.
Don't include the single quotes.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
I was using a decorator and defining an attribute directly.
But no matter - it is clear I had completely misunderstood the intent.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
ut
it is compatible with a good many other interpretations, too. Until and
unless you know what it means, you can't extract its meaning from its
words.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
oe within fred, I assumed that it referred to getting
joe from fred. That certainly doesn't appear to be the case, and I don't
see how it helps with my original request if not.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
def joe (self) :
print "Inside /joe\n"
a = fred()
a.joe()
I get:
Inside pete
Inside joe
Traceback (most recent call last):
File "crap.py", line 14, in
a.joe()
TypeError: 'NoneType' object is not callable
VERY weird - I could understand it if I
like to consider adding the information you perceive to be
|> lacking.
Consider it considered, but I have to start by understanding what is
supposed to happen and what does happen, precisely and in detail.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
it is so ambiguous
as to be almost totally useless - and it is THAT information that needs to
be in the reference manual, but is only in whatsnew2.2.
Regards,
Nick Maclaren.
--
http://mail.python.org/mailman/listinfo/python-list
In article <[EMAIL PROTECTED]>,
Robert Kern <[EMAIL PROTECTED]> writes:
|> Nick Maclaren wrote:
|> > The way that I read it, Python allows only values (and hence types)
|> > to be immutable, and not class members. The nearest approach to the
|> > latter is t
1 - 100 of 118 matches
Mail list logo
