Class data members in C

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

Re: Class data members in C

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

Number methods

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

Re: Class data members in C

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

Re: what can be used in a signal handler

't be 100% reliable on all systems. Sorry. But that is the situation :-( Regards, Nick Maclaren. -- http://mail.python.org/mailman/listinfo/python-list

Re: How to find out if another process is using a file

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

Re: How to find out if another process is using a file

_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

Re: when format strings attack

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

RE: OT Annoying Habits (Was: when format strings attack)

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

RE: OT Annoying Habits (Was: when format strings attack)

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

Re: The reliability of python threads

|> 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

Re: The reliability of python threads

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

Re: The reliability of python threads

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

Re: The reliability of python threads

;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

Re: The reliability of python threads

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

Re: The reliability of python threads

^^ |> 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

Re: The reliability of python threads

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

Re: The reliability of python threads

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

<    1   2