Re: What is Expressiveness in a Computer Language
George Neuner wrote: I can know that my conversion of floating point to integer is going to produce a value within a certain range ... but, in general, the compiler can't determine what that range will be. All it knows is that a floating point value is being truncated and the stupid programmer wants to stick the result into some type too narrow to represent the range of possible values. Like I said to Ben, I haven't seen any _practical_ static type system that can deal with things like this. Writing a generic function is impossible under the circumstances, and writing a separate function for each narrow type is ridiculous and a maintenance nightmare even if they can share the bulk of the code. This is the partial function question again, in a different guise. Marshall -- http://mail.python.org/mailman/listinfo/python-list
Re: Replace Whole Object Through Object Method
Maric Michaud wrote: Le lundi 26 juin 2006 22:37, [EMAIL PROTECTED] a écrit : Won't work because there will be employers that aren't workers. And yes, only some workers will become employers, but also only some employers will also be workers (at some point in program). Let me be more clear: workers -- subset of workers --become-- employers employers -- subset of employers --become-- workers It is very important that both should maintain attribute values, regardless of whether they take on new roles. Furthermore, this is a very simple case and ultimately in my program an object should be able to dynamically take on a multitude of roles (classes of behavior) without mucking at all with their pre-existing states. This seem to be a OO design problem and you clearly make a misuse of inheritance, if a person can eventually have many roles, but doesn't have this role for all his lifetime, then the person *is* not his roles. That the meaning of inheritance, class B(A) means a B is a A. The association between a person and his roles is obviously a 1-n association, which can be rendered by different patterns (delegation, composition, strategy, etc.). You should google on design patterns and make your choice. A misuse of inheritance eh? Inheritance, like other language features, is merely a tool. I happen to be using this tool to have my virtual persons change roles at different points in their lifetime, as many real people tend to do. Thus, at these points, B is indeed an A. What a person is, whether in real life or in my program, is not static and comes into definition uniquely for each moment (micro-moment, etc.) of existence. Now, please, I have no intention of carrying the conversation in such a silly direction, I wasn't inviting a discussion on philosophy or some such. I seek to work the tools to my needs, not the other way around. -- _ Maric Michaud _ Aristote - www.aristote.info 3 place des tapis 69004 Lyon Tel: +33 426 880 097 -- http://mail.python.org/mailman/listinfo/python-list
Re: TypeError: Cannot create a consistent method resolution order (MRO) for bases object
Maric Michaud wrote: Le lundi 26 juin 2006 20:06, [EMAIL PROTECTED] a écrit : What are the reason one would get this error: TypeError: Cannot create a consistent method resolution order (MRO) for bases object ?? I can provide the code if needed This is the python solution to the diamond problem (cf. wikipedia). In [61]: class a(object) : pass : In [62]: class b(a) : pass : In [63]: class c(object, a) : pass : --- exceptions.TypeError Traceback (most recent call last) /home/maric/ipython console TypeError: Error when calling the metaclass bases Cannot create a consistent method resolution order (MRO) for bases object, a In [64]: b.mro() Out[64]: [class '__main__.b', class '__main__.a', type 'object'] In [65]: class c(a, object) : pass : In [66]: c.mro() Out[66]: [class '__main__.c', class '__main__.a', type 'object'] In [67]: class d(b, c) : pass : In [69]: d.mro() Out[69]: [class '__main__.d', class '__main__.b', class '__main__.c', class '__main__.a', type 'object'] mro means method resolution order, this is the path the interpreter will look for attributes for a given class. You cannot introduce inconsistency in this path, for example duplicate the type object before another type (or any type wich appear to be the ancestor of another). -- Ah, thank you Maric, I see the problem. I diagrammed the flow of class inheritance and I can see the problem clearly. Ruby doesn't have this problem because it uses a single inheritance model complemented by the power of mixins (modules of functionality mixed into classes as needed). So what's the Pythonic solution to this problem? -- http://mail.python.org/mailman/listinfo/python-list
Execute Commands on Remote Computers over Network
I have been researching this topic and come up with some code to make it work. It uses SSL and requires the 3rd party package Paramiko (which requires PyCrypto). However, at this moment I have no network to test the code on! Trying to connect to localhost (127.0.0.1) fails. Before I buy network components, I want to be sure that this code will work. Will someone with two networked computers try it out for me? Thanks! Code: def remotely_execute_command(ipaddr, port, user, passwd=None, cmd): import paramiko transport = paramiko.Transport(ipaddr + : + port) transport.connect(username=user, password=passwd) channel = transport.open_session() channel.exec_command(cmd) print Command + cmd + executed by user + user + with password + passwd + at + host + : + port -- http://mail.python.org/mailman/listinfo/python-list
Re: Replace Whole Object Through Object Method
Bruno Desthuilliers wrote: (snip) It is very important that both should maintain attribute values, regardless of whether they take on new roles. Seems obvious. But just a question, BTW: do workers and employers share the same attributes ? And if not, how do you intend to initialize the employers attributes on workers (and the other way round) ? They have unique attributes, conflict is not a problem. What do you mean by init-on? Furthermore, this is a very simple case and ultimately in my program an object *Any* object ?-) Yes, any real-world object modeled in my program. should be able to dynamically take on a multitude of roles (classes of behavior) without mucking at all with their pre-existing states. Multiple roles at the same time, or sequentially ? And in the first case (which I assume), do you have the case of overriding behaviors ? And if yes, how should the resolution order be defined ? And what about attributes ? (I mean, do your 'roles' have specific attributes ?) Multiple roles at the same time, with specific attributes for each. Overriding behaviors is not a problem as each has unique behaviors. Common behaviors are sourced from a base class. In the case of multiple simultaneous roles, overwriting these common behaviors with duplicates isn't really a problem in the sense that the dups are indeed identical to the previous code. -- http://mail.python.org/mailman/listinfo/python-list
Traversing Inheritance Model
What's the best way to traverse the web of inheritance? I want to take a class and traverse its bases and then the bases' bases etc looking for a particular class. What first came to mind was nested for loops. However, I want to know if there's some pre-existing method for doing this or if this isn't even possible (might send me in circles perhaps?).Thanks all. -- http://mail.python.org/mailman/listinfo/python-list
Re: nested dictionary assignment goes too far
Thanks a lot Serge and Ben. Your posts were right on. I hope the weather is good wherever you are. Jake -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
I wrote: The important thing is the dynamicism of lisp allowed one to write polymorphic programs, before most of us knew the term. Chris Smith [EMAIL PROTECTED] writes: Sure. In exchange for giving up the proofs of the type checker, you could write all kinds of programs. To this day, we continue to write programs in languages with dynamic checking features because we don't have powerful enough type systems to express the corresponding type system. And to me the question is what kinds of types apply to these dynamic programs, where in fact you may have to solve the halting problem to know exactly when some statement is executed. I expect that some programs have type signatures that exceed the expressibility of any static system (that is Turing complete). Therefore, we need something that computes the appropriate type at run-time, because we need full Turing power to compute it. To me such a system is a dynamic type system. I think dynamic tags are a good approximation, because they only compute what type the expression has this time. I believe that, in fact, it would be trivial to imagine a type system which is capable of expressing that type. Okay, not trivial, since it appears to be necessary to conceive of an infinite family of integer types with only one value each, along with range types, and relationships between them; but it's probably not completely beyond the ability of a very bright 12-year-old who has someone to describe the problem thoroughly and help her with the notation. Well, it look like you are right in that I see following is a Haskell program that looks essentially correct. I wanted something that was simple enough that one could see that it could be computed, but which was complex enough that it had to be computed (and couldn't be statically expressed with a system that did no type computations). Perhaps, there is no such beast. Or, perhaps I just can't formulate it. Or, perhaps we have static type checkers which can do computations of unbounded complexity. However, I thought that one of the characteristics of type systems was that they did not allow unbounded complexity and weren't Turing Complete. You would, of course, need a suitable type system first. For example, it appears to me that there is simply no possible way of expressing what you've described in Java, even with the new generics features. Perhaps it's possible in ML or Haskell (I don't know). My point is that if you were allowed to design a type system to meet your needs, I bet you could do it. Or, I could do as I think the dynamic programmers do, dispense with trying to formulate a sufficiently general type system and just check the tags at the appropriate points. Sure. The important question, then, is whether there exists any program bug that can't be formulated as a type error. If you allow Turing Complete type systems, then I would say no--every bug can be reforumlated as a type error. If you require your type system to be less powerful, then some bugs must escape it. -Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Greg Buchholz [EMAIL PROTECTED] writes: Chris F Clark wrote: Thus, as we traverse a list, the first element might be an integer, the second a floating point value, the third a sub-list, the fourth and fifth, two more integers, and so on. If you look statically at the head of the list, we have a very wide union of types going by. However, perhaps there is a mapping going on that can be discerned. For example, perhaps the list has 3 distinct types of elements (integers, floating points, and sub-lists) and it circles through the types in the order, first having one of each type, then two of each type, then four of each type, then eight, and so on. Sounds like an interesting problem. Although not the exact type specified above, here's something pretty similar that I could think of implementing in Haskell. (I don't know what a sub-list is, for example). Maybe some Haskell wizard could get rid of the tuples? data Clark a b c = Nil | Cons a (Clark b c (a,a)) deriving Show clark = (Cons 42 (Cons 3.14 (Cons abc (Cons (1,2) (Cons (1.2,3.4) (Cons (foo,bar) (Cons ((9,8),(7,6)) (Cons ((0.1,0.2),(0.3,0.4)) Nil main = print clark Very impressive. It looks right to me and simple enough to understand. I must find the time to learn a modern FP language. Can you write a fold for this that prints the data as a binary tree of triples? I have to believe it isn't that hard -Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Chris F Clark wrote: And to me the question is what kinds of types apply to these dynamic programs, where in fact you may have to solve the halting problem to know exactly when some statement is executed. I expect that some programs have type signatures that exceed the expressibility of any static system (that is Turing complete). Therefore, we need something that computes the appropriate type at run-time, because we need full Turing power to compute it. To me such a system is a dynamic type system. I think dynamic tags are a good approximation, because they only compute what type the expression has this time. Yes, an important question (IMHO the *more* important question than the terminology) is what *programs* do we give up if we wish to use static typing? I have never been able to pin this one down at all. Frankly, if the *only* issue between static and dynamic was the static checking of the types, then static typing woud unquestionably be superior. But that's not the only issue. There are also what I call packaging issues, such as being able to run partly-wrong programs on purpose so that one would have the opportunity to do runtime analysis without having to, say, implement parts of some interface that one isn't interested in testing yet. These could also be solved in a statically typed language. (Although historically it hasn't been done that way.) The real question is, are there some programs that we can't write *at all* in a statically typed language, because they'll *never* be typable? I think there might be, but I've never been able to find a solid example of one. Perhaps, there is no such beast. Or, perhaps I just can't formulate it. Or, perhaps we have static type checkers which can do computations of unbounded complexity. However, I thought that one of the characteristics of type systems was that they did not allow unbounded complexity and weren't Turing Complete. The C++ type system is Turing complete, although in practical terms it limits how much processing power it will spend on types at compile time. If you allow Turing Complete type systems, then I would say no--every bug can be reforumlated as a type error. If you require your type system to be less powerful, then some bugs must escape it. I don't think so. Even with a Turing complete type system, a program's runtime behavior is still something different from its static behavior. (This is the other side of the types are not tags issue--not only is it the case that there are things static types can do that tags can't, it is also the case that there are things tags can do that static types can't.) Marshall -- http://mail.python.org/mailman/listinfo/python-list
Re: Python taught in schools?
In article [EMAIL PROTECTED], Mirco Wahab [EMAIL PROTECTED] wrote: Thus spoke Lawrence D'Oliveiro (on 2006-06-26 09:21): In article [EMAIL PROTECTED], Mirco Wahab [EMAIL PROTECTED] wrote: C++ programming requires you to massively invest your thinking first into the setup of your build environment ... I don't understand why. It's easy enough to build small programs with a single g++ command. Think about beeing a young guy with a windows pc at home. To make sense of your 45 min C++ class, you need to practice the stuff at home for sure, I'd guess. Now go ahead! What would you do? Download a Linux distro with a complete GCC, Emacs, GDB etc. Then go wild. -- http://mail.python.org/mailman/listinfo/python-list
Re: HTTP server
Simon Forman wrote:
...
Awesome! Glad to hear it.
...
Thanks for the help. I got it to work now.
You're welcome. I'm glad I could help you. :-D
Im having trouble with the following code for handling GET requests
from a client to my HTTP server. What i want to do is restrict access
only to a folder and contents within this folder. But when trying to
open files (text files) i get file not found error from send_head()
method of SimpleHTTPServer. The reason behind this is when opening the
file the path to the file is only C:\file.txt when it should be
C:\folder\file.txt. And when i remove the code that checks if path
contains txt it works (i can access files without errors).
Any help will be greatly appreciated!
code
def list_directory(self, path):
Helper to produce a directory listing (absent index.html).
Return value is either a file object, or None (indicating an
error). In either case, the headers are sent, making the
interface the same as for send_head().
f = StringIO()
p = self.translate_path(self.path)
if p.find(txt) == -1:
f.write(titlehttpserver.py: Access Denied/title )
f.write(h2httpserver.py: Access Denied/h2 )
else:
try:
list = os.listdir(path)
except os.error:
self.send_error(404, No permission to list directory)
return None
list.sort(key=lambda a: a.lower())
displaypath = cgi.escape(urllib.unquote(self.path))
f.write(titleDirectory listing for %s/title\n %
displaypath)
f.write(h2Directory listing for %s/h2\n %
displaypath)
f.write(hr\nul\n)
for name in list:
fullname = os.path.join(path, name)
displayname = linkname = name
# Append / for directories or @ for symbolic links
if os.path.isdir(fullname):
displayname = name + /
linkname = name + /
if os.path.islink(fullname):
displayname = name + @
# Note: a link to a directory displays with @ and
links with /
f.write('lia href=%s%s/a\n'
% (urllib.quote(linkname),
cgi.escape(displayname)))
f.write(/ul\nhr\n)
length = f.tell()
f.seek(0)
self.send_response(200)
self.send_header(Content-type, text/html)
self.send_header(Content-Length, str(length))
self.end_headers()
return f
/code
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python taught in schools?
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Gary Duzan) wrote: I understand that the school switched [from C++] to Java a short time later, which is some improvement, but still has a good bit of baggage. Java started out trying to avoid most of the complexities of C++, but ended up having to reintroduce many of them anyway. p.s. Then sock them with ML or Haskell to weed out the weak ones. ;-) Then if they survive Occam, throw Java at them, so they'll know what they are missing but can still get a job... And yet, because they didn't start with Java, they'll still have the ability to think. Which is bound to annoy PHBs out in the real world ... -- http://mail.python.org/mailman/listinfo/python-list
Re: Having problems with strings in HTML
In article [EMAIL PROTECTED],
Kiana Toufighi [EMAIL PROTECTED] wrote:
print '''
a
href=http://bbc.botany.utoronto.ca/ntools/cgi-bin/ntools_treeview_word.cgi?inp
ut=max=2values_off=noremove_bracket=noshow_line_nr=yesshow_link_out=yesde
cimal_places=10show_classification=yesdb=arabidopsisselection=any%20termmod
e=mode_nos=yellow_blue=yeslocal_file_name=%(OUT_FILE_NAME)sshow_instruction
s=noexpt_link=NASCArraysmax_adjust=2view_size=largehighlight=%(HI_LITE_FILE
_NAME)sGraphicalOutput/a
''' % {'OUT_FILE_NAME': OUT_FILE_NAME, 'HI_LITE_FILE_NAME':
HI_LITE_FILE_NAME}
By the way, you _do_ realize that your characters should be escaped
as amp;, don't you?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Execute Commands on Remote Computers over Network
In article [EMAIL PROTECTED], dylpkls91 [EMAIL PROTECTED] wrote: I have been researching this topic and come up with some code to make it work. It uses SSL and requires the 3rd party package Paramiko (which requires PyCrypto). Why not just spawn an invocation of SSH? -- http://mail.python.org/mailman/listinfo/python-list
Re: Traversing Inheritance Model
[EMAIL PROTECTED] wrote: What's the best way to traverse the web of inheritance? I want to take a class and traverse its bases and then the bases' bases etc looking for a particular class. What first came to mind was nested for loops. However, I want to know if there's some pre-existing method for doing this or if this isn't even possible (might send me in circles perhaps?).Thanks all. The __mro__ descriptor does what you want. Example: class A(object): ... pass ... class B(object): ... pass ... class C(A, B): ... pass ... C.__mro__ (class '__main__.C', class '__main__.A', class '__main__.B', type 'object') See: http://www.python.org/download/releases/2.2.3/descrintro/ and http://www.python.org/download/releases/2.3/mro/ for details. Ziga -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Chris F Clark [EMAIL PROTECTED] wrote: And to me the question is what kinds of types apply to these dynamic programs, where in fact you may have to solve the halting problem to know exactly when some statement is executed. Yes, I believe (static) type systems will always end up approximating (conservatively) the possible behavior of programs in order to perform their verification. Or, perhaps we have static type checkers which can do computations of unbounded complexity. However, I thought that one of the characteristics of type systems was that they did not allow unbounded complexity and weren't Turing Complete. Honestly, I suspect you'd get disagreement within the field of type theory about this. Certainly, there are plenty of researchers who have proposed type systems that potentially don't even terminate. The consensus appears to be that they are worth studying within the field of type theory, but I note that Pierce still hasn't dropped the word tractable from his definition in his introductory text, despite acknowledging only a couple pages later that languages exist whose type systems are undecidable, and apparently co-authoring a paper on one of them. The consensus seems to be that such systems are interesting if they terminate quickly for interesting cases (in which case, I suppose, you could hope to eventually be able to formalize what cases are interesting, and derive a truly tractable type system that checks that interesting subset). Interestingly, Pierce gives ML as an example of a language whose type checker does not necesarily run in polynomial time (thus failing some concepts of tractable) but that does just fine in practice. I am just quoting here, so I don't know exactly how this is true. Marshall mentioned template meta-programming in C++, which is definitely Turing- complete. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
[ python-Bugs-1512504 ] builtin enumerate overflows
Bugs item #1512504, was opened at 2006-06-26 08:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1512504group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: James Harlow (hythloday) Assigned to: Nobody/Anonymous (nobody) Summary: builtin enumerate overflows Initial Comment: The index that the builtin function enumerate() returns is a mere integer and will wrap back to a negative number when it overflows. This seems to be by design (unless I'm misunderstanding the point of PyInt_FromLong), but is sufficiently surprising that I'd suggest it's a bug anyway. I've attached a test case - it takes a while to execute, but the results are so deeply exciting that it's worth doing just for fun! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1512504group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1512604 ] Install on Windows Vista locks up
Bugs item #1512604, was opened at 2006-06-26 06:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1512604group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Michael Lucas (michael_lucas) Assigned to: Nobody/Anonymous (nobody) Summary: Install on Windows Vista locks up Initial Comment: I have had problems trying to install this version on Vista. When the install gets to the verifying disk space requirements the system locks up. It does not go any further. I have to cancel the instalation of python. The only way I have got around this is to install an older version of python (version 2.3.5) this version does work, but there are newer versions that I want to work with on my system. If anyone has a work around for this please contact me at [EMAIL PROTECTED] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1512604group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1511998 ] Glitches in What's New for beta 1
Bugs item #1511998, was opened at 2006-06-25 00:09 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1511998group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: A.M. Kuchling (akuchling) Summary: Glitches in What's New for beta 1 Initial Comment: PEP 343 writeup 2.5a2 changed the generator decorator back to 'contextmanager' when the __context__ method was dropped (without context objects involved, the name contextfactory didn't make sense any more). xmlcore vs xml The notes about the introduction of xmlcore seem a little misleading (implying that 'import xml' will fail on a base 2.5 installation). Isn't the xml namespace a combination of both xmlcore and PyXML? wsgiref The example should either import make_server from wsgiref.simple_server, or else call simple_server.make_server AST compiler documentation People interested in the AST compiler should be directed towards Brett's writeup in PEP 339. http://www.python.org/dev/peps/pep-0339/ Remove of PyRange_New It may be worth noting that you can use PyObject_Call(PyRange_Type, etc...) instead (as per recent python-dev discussion). -- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-26 08:45 Message: Logged In: YES user_id=11375 Suggested changes applied; thanks! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1511998group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1512163 ] mailbox (2.5b1): locking doesn't work (esp. on FreeBSD)
Bugs item #1512163, was opened at 2006-06-25 11:38 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1512163group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox (2.5b1): locking doesn't work (esp. on FreeBSD) Initial Comment: fcntl/flock() locking of mailboxes is actually disabled due to a typo: --- mailbox.py.orig +++ mailbox.py @@ -15,7 +15,7 @@ import rfc822 import StringIO try: -import fnctl +import fcntl except ImportError: fcntl = None However, once enabled, it doesn't work on FreeBSD - the lock() method always raises ExternalClashError (tested on 5.3). This is because flock(), lockf() and fcntl locking share the same underlying mechanism on this system (and probably others), and so the second lock can never be acquired. -- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-26 08:56 Message: Logged In: YES user_id=11375 Interesting. The man page for flock() on my Linux system says of flock() in a certain version: This yields true BSD semantics: there is no interaction between the types of lock placed by flock(2) and fcntl(2), and flock(2) does not detect deadlock. Apparently this is out of date, and placing two locks is harmful. I think it's best to just use one set of locking primitives, and that one should be lockf(); the flock() calls should be removed. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-25 15:52 Message: Logged In: YES user_id=33168 Andrew, are you helping maintain this module? David is correct that fcntl is mispelled in current svn. Not sure what to do about the locking issue. David, would it be possible for you to work on a patch to correct this problem? I'm not sure if any developer has access to a FreeBSD box similar to yours. (There are a couple that use FreeBSD though.) It would be great to come up with tests for this if the current ones don't stress this situation. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1512163group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1512695 ] cPickle.loads() seg.faults when interrupted with keyboard
Bugs item #1512695, was opened at 2006-06-26 16:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1512695group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Faik Uygur (faik) Assigned to: Nobody/Anonymous (nobody) Summary: cPickle.loads() seg.faults when interrupted with keyboard Initial Comment: cPickle.loads() gives segmentation fault when interrupted with keyboard (CTRL+C). Attached python script tested with python version 2.4.3 and 2.5b1. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1512695group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1512695 ] cPickle.loads() seg.faults when interrupted with keyboard
Bugs item #1512695, was opened at 2006-06-26 16:05 Message generated for change (Settings changed) made by faik You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1512695group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Faik Uygur (faik) Assigned to: Nobody/Anonymous (nobody) Summary: cPickle.loads() seg.faults when interrupted with keyboard Initial Comment: cPickle.loads() gives segmentation fault when interrupted with keyboard (CTRL+C). Attached python script tested with python version 2.4.3 and 2.5b1. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1512695group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1512163 ] mailbox (2.5b1): locking doesn't work (esp. on FreeBSD)
Bugs item #1512163, was opened at 2006-06-25 11:38 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1512163group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox (2.5b1): locking doesn't work (esp. on FreeBSD) Initial Comment: fcntl/flock() locking of mailboxes is actually disabled due to a typo: --- mailbox.py.orig +++ mailbox.py @@ -15,7 +15,7 @@ import rfc822 import StringIO try: -import fnctl +import fcntl except ImportError: fcntl = None However, once enabled, it doesn't work on FreeBSD - the lock() method always raises ExternalClashError (tested on 5.3). This is because flock(), lockf() and fcntl locking share the same underlying mechanism on this system (and probably others), and so the second lock can never be acquired. -- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-26 09:27 Message: Logged In: YES user_id=11375 Typo fixed in rev. 47099; flock() calls removed in rev. 47100; a test for lock conflicts added in rev. 47101. David, please try out the current SVN head and let me know if matters have improved. I'll wait to see the buildbot reports before closing this bug. (Surprisingly, we don't seem to have a FreeBSD buildbot, though we do have an OpenBSD one that didn't seem to have a problem with the original version of the mailbox code.) -- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-26 08:56 Message: Logged In: YES user_id=11375 Interesting. The man page for flock() on my Linux system says of flock() in a certain version: This yields true BSD semantics: there is no interaction between the types of lock placed by flock(2) and fcntl(2), and flock(2) does not detect deadlock. Apparently this is out of date, and placing two locks is harmful. I think it's best to just use one set of locking primitives, and that one should be lockf(); the flock() calls should be removed. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-25 15:52 Message: Logged In: YES user_id=33168 Andrew, are you helping maintain this module? David is correct that fcntl is mispelled in current svn. Not sure what to do about the locking issue. David, would it be possible for you to work on a patch to correct this problem? I'm not sure if any developer has access to a FreeBSD box similar to yours. (There are a couple that use FreeBSD though.) It would be great to come up with tests for this if the current ones don't stress this situation. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1512163group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1504333 ] sgmlib should allow angle brackets in quoted values
Bugs item #1504333, was opened at 2006-06-11 08:58
Message generated for change (Settings changed) made by akuchling
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1504333group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Sam Ruby (rubys)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: sgmlib should allow angle brackets in quoted values
Initial Comment:
Real live example (search for otherbr /corrections)
http://latticeqcd.blogspot.com/2006/05/non-relativistic-qcd.html
This addresses the following (included in the file):
# XXX The following should skip matching quotes (' or )
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=105470aid=1504333group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1512695 ] cPickle.loads() seg.faults when interrupted with keyboard
Bugs item #1512695, was opened at 2006-06-26 16:05 Message generated for change (Comment added) made by faik You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1512695group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Faik Uygur (faik) Assigned to: Nobody/Anonymous (nobody) Summary: cPickle.loads() seg.faults when interrupted with keyboard Initial Comment: cPickle.loads() gives segmentation fault when interrupted with keyboard (CTRL+C). Attached python script tested with python version 2.4.3 and 2.5b1. -- Comment By: Faik Uygur (faik) Date: 2006-06-26 17:08 Message: Logged In: YES user_id=1541018 I tracked the seg. fault. It seg. faults in method PyTuple_Pack(). When python receives the keyboard interrupt: o = va_arg(vargs, PyObject *); Py_INCREF(o); va_arg returns NULL, and Py_INCREF causes the seg.fault. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1512695group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1512791 ] module wave does no rounding
Bugs item #1512791, was opened at 2006-06-26 15:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1512791group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Kochanski (gpk) Assigned to: Nobody/Anonymous (nobody) Summary: module wave does no rounding Initial Comment: In wave.py, a floating point frame rate is truncated (rather than rounded) in function _write_header(). Fractional frame rates are perfectly reasonable, even if not normally seen in audio practice, and the software ought to represent them as accurately as possible. Moreover, it's sometimes reasonable to store the inverse of the frame rate, which is the time interval between frames. That's important when you're doing signal processing, and some data formats store 1.0/framerate rather than framerate. Anyhow, if you give setframerate() a float, it truncates rather than rounding, so dt = 1.0/44100 setframerate(1.0/dt) can end up setting the frame rate to 44099 Hz in the resulting data file. The fix is to change the last line of setframerate() to self._framerate = int(round(framerate)) . That also has the beneficial side-effect of giving an earlier error report in case someone gives the wrong type of object to setframerate() (such as None, or 44100, or some class). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1512791group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1202533 ] a bunch of infinite C recursions
Bugs item #1202533, was opened at 2005-05-15 16:43 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1202533group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Brett Cannon (bcannon) Summary: a bunch of infinite C recursions Initial Comment: There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed. The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves). class A: pass A.__mul__=new.instancemethod(operator.mul,None,A) A()*2 Segmentation fault -- Comment By: Armin Rigo (arigo) Date: 2006-06-25 02:33 Message: Logged In: YES user_id=4771 Yes, it seems reasonable. You should probably manipulate tstate-recursion_depth directly instead of via the macros, as e.g. ceval.c does. This would fix most crashes here. It would make the attached test17.py segfault, though. This test17 already segfaults a debug build of Python, but not a release build because the recursive PyErr_NormalizeException() is turned into a tail call by gcc. (What, a convoluted mind, mine?) -- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 14:54 Message: Logged In: YES user_id=357491 I just had an idea, Armin. What if, at the recursive call site in PyErr_NormalizeException(), we called Py_LeaveRecursiveCall() before and Py_EnterRecursiveCall() after? That would keep the recursion limit the same when the normalization was done, but still allow the check in PyObject_Call():: Py_LeaveRecursiveCall(); PyErr_NormalizeException(exc, val, tb); Py_EnterRecursiveCall(); Since it is an internal call I think it would be safe to play with the recursion depth value like this. What do you think? -- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 13:57 Message: Logged In: YES user_id=357491 The rev. that Armin checked in was actually r47061. -- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 13:53 Message: Logged In: YES user_id=357491 I thought the check was in slot_tp_call and not PyObject_Call. So yeah, I basically forgot. =) The problem with allowing the segfault to stay is that it destroys security in terms of protecting the interpreter, which I am trying to deal with. So leaving random ways to crash the interpreter is currently a no-no for me. I will see if I can come up with another way to fix this issue. -- Comment By: Armin Rigo (arigo) Date: 2006-06-23 13:05 Message: Logged In: YES user_id=4771 I'd have answer good idea, go ahead, if it were not for what I found out a few days ago, which is that: * you already checked yourself a Py_EnterRecursiveCall() into PyObject_Call() -- that was in r46806 (I guess you forgot) * I got a case of Python hanging on me in an infinite busy loop, which turned out to be caused by this (!) So I reverted r46806 in r47601, added a test (see log for an explanation), and moved the PyEnter_RecursiveCall() elsewhere, where it still catches the originally intended case, but where it will probably not catch the cases of the present tracker any more. Not sure what to do about it. I'd suggest to be extra careful here; better some extremely obscure and ad-hoc ways to provoke a segfault, rather than busy-loop hangs in previously working programs... -- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 12:44 Message: Logged In: YES user_id=357491 Do you have any objection to using the Py_EnterRecursiveCall() in PyObject_Call(), Armin, to at least deal with the crashers it fixes? -- Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-01 13:39 Message: Logged In: YES user_id=593130 Bug submission [ 1267884 ] crash recursive __getattr__ appears to be another example of this problem, so I closed it as a duplicate. If that turns out to be wrong, it should be reopened. -- Comment By: Armin Rigo (arigo) Date: 2005-05-29 05:23 Message: Logged In: YES user_id=4771 Adding a Py_EnterRecursiveCall() in PyObject_Call() seems to fix all the examples so far, with the exception of the
[ python-Bugs-1511497 ] xml.sax.expatreader is missing
Bugs item #1511497, was opened at 2006-06-23 20:14 Message generated for change (Comment added) made by calvin You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1511497group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: xml.sax.expatreader is missing Initial Comment: Hi, when testing the new Python 2.5 subversion tree I encountered this behaviour: $ python2.5 Python 2.5b1 (trunk:47065, Jun 22 2006, 20:56:23) [GCC 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)] on linux2 Type help, copyright, credits or license for more information. import xml.sax.expatreader print xml.sax.expatreader Traceback (most recent call last): File stdin, line 1, in module AttributeError: 'module' object has no attribute 'expatreader' So the import went ok, but using the attribute gave an error. This is very strange. Python 2.4 did not have this behaviour. -- Comment By: Wummel (calvin) Date: 2006-06-26 20:15 Message: Logged In: YES user_id=9205 I built Python directly from the SVN trunk repository with $ ./configure make altinstall I attached the pyconfig.h that was generated. If you need more info, feel free to ask. After building and installing, I started up python2.5 and executed import xml.sax.expatreader and then print xml.sax.expatreader, and nothing else. Another thing I tried is import from, which works. But importing xml.sax.expatreader directly, as noted above, does not work. Here is the log with the import from test: Python 2.5b1 (trunk:47090, Jun 25 2006, 09:59:02) [GCC 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)] on linux2 Type help, copyright, credits or license for more information. from xml.sax import expatreader print expatreader module 'xml.sax.expatreader' from '/usr/local/lib/python2.5/xmlcore/sax/expatreader.pyc' print xml.sax.expatreader Traceback (most recent call last): File stdin, line 1, in module AttributeError: 'module' object has no attribute 'expatreader' -- Comment By: Martin v. Löwis (loewis) Date: 2006-06-24 12:39 Message: Logged In: YES user_id=21627 How precisely did you test it? What configure options did you set up, what commands did you provide to build Python? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1511497group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1202533 ] a bunch of infinite C recursions
Bugs item #1202533, was opened at 2005-05-15 16:43 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1202533group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Brett Cannon (bcannon) Summary: a bunch of infinite C recursions Initial Comment: There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed. The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves). class A: pass A.__mul__=new.instancemethod(operator.mul,None,A) A()*2 Segmentation fault -- Comment By: Brett Cannon (bcannon) Date: 2006-06-26 12:31 Message: Logged In: YES user_id=357491 Yes, Armin, that is a rather evil piece of code. =) But I have a possible simple solution. =) If you add a check after the PyExceptionClass_Check() in the 'if' statement that tstate-recursion_depth is greater than 0, you short-circuit the infinite recursion and still get a sensible output. I have attached a patch with my proposed changes for PyObject_Call() and PyErr_NormalizeException() and the remove of the recursion check for slot_tp_call(). The only issue I can see with this is if the recursion_depth check turns out to be too small of a number. But I really doubt that will be an issue since one shouldn't be having a depth of tracebacks greater than the current recursion depth. Let me know what you think of the patch. -- Comment By: Armin Rigo (arigo) Date: 2006-06-25 02:33 Message: Logged In: YES user_id=4771 Yes, it seems reasonable. You should probably manipulate tstate-recursion_depth directly instead of via the macros, as e.g. ceval.c does. This would fix most crashes here. It would make the attached test17.py segfault, though. This test17 already segfaults a debug build of Python, but not a release build because the recursive PyErr_NormalizeException() is turned into a tail call by gcc. (What, a convoluted mind, mine?) -- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 14:54 Message: Logged In: YES user_id=357491 I just had an idea, Armin. What if, at the recursive call site in PyErr_NormalizeException(), we called Py_LeaveRecursiveCall() before and Py_EnterRecursiveCall() after? That would keep the recursion limit the same when the normalization was done, but still allow the check in PyObject_Call():: Py_LeaveRecursiveCall(); PyErr_NormalizeException(exc, val, tb); Py_EnterRecursiveCall(); Since it is an internal call I think it would be safe to play with the recursion depth value like this. What do you think? -- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 13:57 Message: Logged In: YES user_id=357491 The rev. that Armin checked in was actually r47061. -- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 13:53 Message: Logged In: YES user_id=357491 I thought the check was in slot_tp_call and not PyObject_Call. So yeah, I basically forgot. =) The problem with allowing the segfault to stay is that it destroys security in terms of protecting the interpreter, which I am trying to deal with. So leaving random ways to crash the interpreter is currently a no-no for me. I will see if I can come up with another way to fix this issue. -- Comment By: Armin Rigo (arigo) Date: 2006-06-23 13:05 Message: Logged In: YES user_id=4771 I'd have answer good idea, go ahead, if it were not for what I found out a few days ago, which is that: * you already checked yourself a Py_EnterRecursiveCall() into PyObject_Call() -- that was in r46806 (I guess you forgot) * I got a case of Python hanging on me in an infinite busy loop, which turned out to be caused by this (!) So I reverted r46806 in r47601, added a test (see log for an explanation), and moved the PyEnter_RecursiveCall() elsewhere, where it still catches the originally intended case, but where it will probably not catch the cases of the present tracker any more. Not sure what to do about it. I'd suggest to be extra careful here; better some extremely obscure and ad-hoc ways to provoke a segfault, rather than busy-loop hangs in previously working programs...
[ python-Bugs-1508864 ] threading.Timer/timeouts break on change of win32 local time
Bugs item #1508864, was opened at 2006-06-19 14:53 Message generated for change (Settings changed) made by qopit You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1508864group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Russell Warren (qopit) Assigned to: Nobody/Anonymous (nobody) Summary: threading.Timer/timeouts break on change of win32 local time Initial Comment: THE ISSUE... --- threading.py imports time.time as _time. On win32 systems, time.time() periodically reads the system time to figure out when to fire an Event. System time can change while waiting for an Event! eg: If the system time is changed while a threading.Timer is pending, the execution time is affected by the time change. eg: set a pending Timer and then change the clock back an hour - this causes your Timer to fire an hour later. This is clearly not desirable. A FIX... --- A fix for this is to use time.clock() on win32 systems instead. Once I found the problem, I currently just fix it by overriding threading._time to be time.clock. Right now I do this in every file that uses threading.Timer. COMMENTS... --- The penalty for this is that there will be a rollover problem eventaully... when the 64-bit performance counter rolls over in 30+ years of continuous pc operation. I'd much rather have this near impossible event than the very likely system time change. This is a general problem I find with the time module and I often have to switch between time() and clock() dependent on operating system, but I only work with win32 and Linux. The issue is that if you want a high resolution and extended rollover counter, it is a different call on each system. -- Comment By: Russell Warren (qopit) Date: 2006-06-26 16:59 Message: Logged In: YES user_id=1542586 This is an issue for anything that uses threading.py's _time function. This includes _Condition.wait(), which screws up both Conditions and Events, which then screw up (for example) the core Queue.Queue timeout implementation. threading.Thread.join also uses the _time call, so it could also get screwed by changes to the local time on Win32. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1508864group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1511497 ] xml.sax.expatreader is missing
Bugs item #1511497, was opened at 2006-06-23 20:14 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1511497group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: XML Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Wummel (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: xml.sax.expatreader is missing Initial Comment: Hi, when testing the new Python 2.5 subversion tree I encountered this behaviour: $ python2.5 Python 2.5b1 (trunk:47065, Jun 22 2006, 20:56:23) [GCC 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)] on linux2 Type help, copyright, credits or license for more information. import xml.sax.expatreader print xml.sax.expatreader Traceback (most recent call last): File stdin, line 1, in module AttributeError: 'module' object has no attribute 'expatreader' So the import went ok, but using the attribute gave an error. This is very strange. Python 2.4 did not have this behaviour. -- Comment By: iga Seilnacht (zseil) Date: 2006-06-27 00:52 Message: Logged In: YES user_id=1326842 I see the same behaviour with the official Python 2.5 beta 1 Windows installer. The interesting thing is that the expatreader module is present in sys.modules: Python 2.5b1 (r25b1:47027, Jun 20 2006, 09:31:33) [MSC v.1310 32 bit (Intel)] on win32 ... import xml.sax.expatreader xml.sax.expatreader Traceback (most recent call last): ... AttributeError: 'module' object has no attribute 'expatreader' import sys sys.modules['xml.sax.expatreader'] module 'xml.sax.expatreader' from '...\lib\xmlcore\sax\expatreader.pyc' All of the other modules in xml package can be imported without any trouble. I don't understand what is the real problem here, but it goes away if you import xmlcore.sax package before expatreader: [restart python] import xmlcore.sax import xml.sax.expatreader xml.sax.expatreader module 'xml.sax.expatreader' from '...\lib\xmlcore\sax\expatreader.pyc' The simplest fix would be to use at least one absolute import in ...\lib\xmlcore\sax\__init__.py, for example you could change line 22: from xmlreader import InputSource to: from xmlcore.sax.xmlreader import InputSource but that might just hide the real bug. -- Comment By: Wummel (calvin) Date: 2006-06-26 20:15 Message: Logged In: YES user_id=9205 I built Python directly from the SVN trunk repository with $ ./configure make altinstall I attached the pyconfig.h that was generated. If you need more info, feel free to ask. After building and installing, I started up python2.5 and executed import xml.sax.expatreader and then print xml.sax.expatreader, and nothing else. Another thing I tried is import from, which works. But importing xml.sax.expatreader directly, as noted above, does not work. Here is the log with the import from test: Python 2.5b1 (trunk:47090, Jun 25 2006, 09:59:02) [GCC 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)] on linux2 Type help, copyright, credits or license for more information. from xml.sax import expatreader print expatreader module 'xml.sax.expatreader' from '/usr/local/lib/python2.5/xmlcore/sax/expatreader.pyc' print xml.sax.expatreader Traceback (most recent call last): File stdin, line 1, in module AttributeError: 'module' object has no attribute 'expatreader' -- Comment By: Martin v. Löwis (loewis) Date: 2006-06-24 12:39 Message: Logged In: YES user_id=21627 How precisely did you test it? What configure options did you set up, what commands did you provide to build Python? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1511497group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1513032 ] 'make install' failure on FreeBSD 5.3
Bugs item #1513032, was opened at 2006-06-26 23:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1513032group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: David Watson (baikie) Assigned to: Nobody/Anonymous (nobody) Summary: 'make install' failure on FreeBSD 5.3 Initial Comment: Version: 2.5b1 See attached log. 'install' seems to be being passed an unexpanded glob due to Lib/lib-old being empty. Creating a file in lib-old allows installation to continue. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1513032group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1512163 ] mailbox (2.5b1): locking doesn't work (esp. on FreeBSD)
Bugs item #1512163, was opened at 2006-06-25 16:38 Message generated for change (Comment added) made by baikie You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1512163group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox (2.5b1): locking doesn't work (esp. on FreeBSD) Initial Comment: fcntl/flock() locking of mailboxes is actually disabled due to a typo: --- mailbox.py.orig +++ mailbox.py @@ -15,7 +15,7 @@ import rfc822 import StringIO try: -import fnctl +import fcntl except ImportError: fcntl = None However, once enabled, it doesn't work on FreeBSD - the lock() method always raises ExternalClashError (tested on 5.3). This is because flock(), lockf() and fcntl locking share the same underlying mechanism on this system (and probably others), and so the second lock can never be acquired. -- Comment By: David Watson (baikie) Date: 2006-06-26 23:56 Message: Logged In: YES user_id=1504904 Yeah, it works fine now (locks successfully when the mailbox isn't locked by another process, and fails when it is locked), although I was reminded that the Python install process didn't work properly (I've submitted another bug report). However, I should point out that flock() locking is required when working with qmail on (for example) Linux - flock() is the only locking mechanism it uses, and as noted below, flock() on Linux is independent from fcntl/lockf(). -- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-26 14:27 Message: Logged In: YES user_id=11375 Typo fixed in rev. 47099; flock() calls removed in rev. 47100; a test for lock conflicts added in rev. 47101. David, please try out the current SVN head and let me know if matters have improved. I'll wait to see the buildbot reports before closing this bug. (Surprisingly, we don't seem to have a FreeBSD buildbot, though we do have an OpenBSD one that didn't seem to have a problem with the original version of the mailbox code.) -- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-26 13:56 Message: Logged In: YES user_id=11375 Interesting. The man page for flock() on my Linux system says of flock() in a certain version: This yields true BSD semantics: there is no interaction between the types of lock placed by flock(2) and fcntl(2), and flock(2) does not detect deadlock. Apparently this is out of date, and placing two locks is harmful. I think it's best to just use one set of locking primitives, and that one should be lockf(); the flock() calls should be removed. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-25 20:52 Message: Logged In: YES user_id=33168 Andrew, are you helping maintain this module? David is correct that fcntl is mispelled in current svn. Not sure what to do about the locking issue. David, would it be possible for you to work on a patch to correct this problem? I'm not sure if any developer has access to a FreeBSD box similar to yours. (There are a couple that use FreeBSD though.) It would be great to come up with tests for this if the current ones don't stress this situation. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1512163group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1512163 ] mailbox (2.5b1): locking doesn't work (esp. on FreeBSD)
Bugs item #1512163, was opened at 2006-06-25 11:38 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1512163group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox (2.5b1): locking doesn't work (esp. on FreeBSD) Initial Comment: fcntl/flock() locking of mailboxes is actually disabled due to a typo: --- mailbox.py.orig +++ mailbox.py @@ -15,7 +15,7 @@ import rfc822 import StringIO try: -import fnctl +import fcntl except ImportError: fcntl = None However, once enabled, it doesn't work on FreeBSD - the lock() method always raises ExternalClashError (tested on 5.3). This is because flock(), lockf() and fcntl locking share the same underlying mechanism on this system (and probably others), and so the second lock can never be acquired. -- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-26 19:24 Message: Logged In: YES user_id=11375 Hm, this looks messy; I doubt the module can know if you want lockf() or fcntl() locking. Maybe Mailbox.lock() should grow an optional parameter that lets you specify the locking mechanism to use -- lockf, fcntl, or both. (But defaulting to what?) On the other hand, maybe it's too late to go making API changes for beta2 (but I suspect it would be OK in this case). -- Comment By: David Watson (baikie) Date: 2006-06-26 18:56 Message: Logged In: YES user_id=1504904 Yeah, it works fine now (locks successfully when the mailbox isn't locked by another process, and fails when it is locked), although I was reminded that the Python install process didn't work properly (I've submitted another bug report). However, I should point out that flock() locking is required when working with qmail on (for example) Linux - flock() is the only locking mechanism it uses, and as noted below, flock() on Linux is independent from fcntl/lockf(). -- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-26 09:27 Message: Logged In: YES user_id=11375 Typo fixed in rev. 47099; flock() calls removed in rev. 47100; a test for lock conflicts added in rev. 47101. David, please try out the current SVN head and let me know if matters have improved. I'll wait to see the buildbot reports before closing this bug. (Surprisingly, we don't seem to have a FreeBSD buildbot, though we do have an OpenBSD one that didn't seem to have a problem with the original version of the mailbox code.) -- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-26 08:56 Message: Logged In: YES user_id=11375 Interesting. The man page for flock() on my Linux system says of flock() in a certain version: This yields true BSD semantics: there is no interaction between the types of lock placed by flock(2) and fcntl(2), and flock(2) does not detect deadlock. Apparently this is out of date, and placing two locks is harmful. I think it's best to just use one set of locking primitives, and that one should be lockf(); the flock() calls should be removed. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-25 15:52 Message: Logged In: YES user_id=33168 Andrew, are you helping maintain this module? David is correct that fcntl is mispelled in current svn. Not sure what to do about the locking issue. David, would it be possible for you to work on a patch to correct this problem? I'm not sure if any developer has access to a FreeBSD box similar to yours. (There are a couple that use FreeBSD though.) It would be great to come up with tests for this if the current ones don't stress this situation. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1512163group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1512163 ] mailbox (2.5b1): locking doesn't work (esp. on FreeBSD)
Bugs item #1512163, was opened at 2006-06-25 08:38 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1512163group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox (2.5b1): locking doesn't work (esp. on FreeBSD) Initial Comment: fcntl/flock() locking of mailboxes is actually disabled due to a typo: --- mailbox.py.orig +++ mailbox.py @@ -15,7 +15,7 @@ import rfc822 import StringIO try: -import fnctl +import fcntl except ImportError: fcntl = None However, once enabled, it doesn't work on FreeBSD - the lock() method always raises ExternalClashError (tested on 5.3). This is because flock(), lockf() and fcntl locking share the same underlying mechanism on this system (and probably others), and so the second lock can never be acquired. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-26 20:21 Message: Logged In: YES user_id=33168 Is the optional parameter necessary if you use inheritance (assuming there's a class/object in there)? Maybe it would be better to have a subclass? Would that be better for us to provide or just to add something to the docs that a user could make a subclass to work around locking issues? I haven't looked at the issues, but if we really need an API change, I'm probably ok with it since it would seem to be quite small. If an API change is really required (doc isn't sufficient), I'd like it to go in ASAP. We could doc for 2.5 and if there's a problem fix for 2.6. -- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-26 16:24 Message: Logged In: YES user_id=11375 Hm, this looks messy; I doubt the module can know if you want lockf() or fcntl() locking. Maybe Mailbox.lock() should grow an optional parameter that lets you specify the locking mechanism to use -- lockf, fcntl, or both. (But defaulting to what?) On the other hand, maybe it's too late to go making API changes for beta2 (but I suspect it would be OK in this case). -- Comment By: David Watson (baikie) Date: 2006-06-26 15:56 Message: Logged In: YES user_id=1504904 Yeah, it works fine now (locks successfully when the mailbox isn't locked by another process, and fails when it is locked), although I was reminded that the Python install process didn't work properly (I've submitted another bug report). However, I should point out that flock() locking is required when working with qmail on (for example) Linux - flock() is the only locking mechanism it uses, and as noted below, flock() on Linux is independent from fcntl/lockf(). -- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-26 06:27 Message: Logged In: YES user_id=11375 Typo fixed in rev. 47099; flock() calls removed in rev. 47100; a test for lock conflicts added in rev. 47101. David, please try out the current SVN head and let me know if matters have improved. I'll wait to see the buildbot reports before closing this bug. (Surprisingly, we don't seem to have a FreeBSD buildbot, though we do have an OpenBSD one that didn't seem to have a problem with the original version of the mailbox code.) -- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-26 05:56 Message: Logged In: YES user_id=11375 Interesting. The man page for flock() on my Linux system says of flock() in a certain version: This yields true BSD semantics: there is no interaction between the types of lock placed by flock(2) and fcntl(2), and flock(2) does not detect deadlock. Apparently this is out of date, and placing two locks is harmful. I think it's best to just use one set of locking primitives, and that one should be lockf(); the flock() calls should be removed. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-25 12:52 Message: Logged In: YES user_id=33168 Andrew, are you helping maintain this module? David is correct that fcntl is mispelled in current svn. Not sure what to do about the locking issue. David, would it be possible for you to work on a patch to correct this problem? I'm not sure if any developer has access to a FreeBSD box similar to yours. (There are a couple that use FreeBSD though.) It would be great to come up with tests for this if the current ones don't stress this situation.
[ python-Bugs-1512504 ] builtin enumerate overflows
Bugs item #1512504, was opened at 2006-06-26 01:50 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1512504group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: James Harlow (hythloday) Assigned to: Raymond Hettinger (rhettinger) Summary: builtin enumerate overflows Initial Comment: The index that the builtin function enumerate() returns is a mere integer and will wrap back to a negative number when it overflows. This seems to be by design (unless I'm misunderstanding the point of PyInt_FromLong), but is sufficiently surprising that I'd suggest it's a bug anyway. I've attached a test case - it takes a while to execute, but the results are so deeply exciting that it's worth doing just for fun! -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-26 20:22 Message: Logged In: YES user_id=33168 Raymond, any comments? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1512504group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1513032 ] 'make install' failure on FreeBSD 5.3
Bugs item #1513032, was opened at 2006-06-26 15:54 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1513032group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Closed Resolution: Fixed Priority: 5 Submitted By: David Watson (baikie) Assigned to: Neal Norwitz (nnorwitz) Summary: 'make install' failure on FreeBSD 5.3 Initial Comment: Version: 2.5b1 See attached log. 'install' seems to be being passed an unexpanded glob due to Lib/lib-old being empty. Creating a file in lib-old allows installation to continue. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-26 21:13 Message: Logged In: YES user_id=33168 Thanks! Committed revision 47115. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1513032group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1510172 ] Absolute/relative import not working?
Bugs item #1510172, was opened at 2006-06-21 12:35 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1510172group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Mitch Chapman (mitchchapman) Assigned to: Nick Coghlan (ncoghlan) Summary: Absolute/relative import not working? Initial Comment: Trying to import from a module using dotted import syntax produces this exception: ValueError: Relative importpath too deep This behavior has been confirmed on Mac OS X 10.4 using the Python 2.5b1 disk image; and on CentOS 4 using the Python 2.5b1 source tarball. The exception is raised regardless of whether the PYTHONPATH environment variable can see the toplevel directory of the package being tested; regardless of whether the import is performed from an interactive Python session or from a script invoked from the command line; and regardless of whether the main script starts with from __future__ import absolute_import To test, I tried to re-create the package structure used as an example in PEP 328. (See attachments.) Most of the files were empty, except moduleX.py and moduleY.py: #moduleX.py: from __future__ import absolute_import from .moduleY import spam #moduleY.py: spam = spam According to the PEP, if should be possible to import moduleX without error. But I get the above exception whenever I try to import moduleX or to run it from the command line. $ python2.5 moduleX.py Traceback (most recent call last): File moduleX.py, line 3, in module from .moduleY import spam ValueError: Relative importpath too deep Is this a usage/documentation error? -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-26 21:41 Message: Logged In: YES user_id=33168 http://mail.python.org/pipermail/python-dev/2006-June/066197.html Nick you made mention of changing the docs, but I'm not sure if you did or not. Could you address this bug? Thanks. -- Comment By: Thomas Wouters (twouters) Date: 2006-06-23 06:52 Message: Logged In: YES user_id=34209 See the discussion started at: http://mail.python.org/pipermail/python-dev/2006-June/066161.html It's not a bug in 328 or 338 (the PEP that adds the -m switch for packages), but in the interaction between the two. I don't think this will be fixed for 2.5, since there is no obvious fix. If it hurts when you press there, don't press there. Either don't use -m for packaged modules, or have the packaged module only use absolute imports. (But don't be surprised if the script-module is imported twice, once as __main__ and once as the module itself. That's a whole other bug/feature.) -- Comment By: Mitch Chapman (mitchchapman) Date: 2006-06-21 16:57 Message: Logged In: YES user_id=348188 Hm... but the same error occurs if one tries to import moduleX from an interactive Python session, or from a sibling module. In other words, in 2.5b1 any module which uses relative imports can be used only as a fully-qualified member of a package. It cannot be imported directly by a sibling module, and it cannot be used as a main module at all: $ python2.5 -m package.subpackage1.moduleX ... from .moduleY import spam ValueError: Relative importpath too deep Given other efforts (PEP 299; PEP 338) to make it easier to use modules both as mainlines and as imports, I still think this is a bug. -- Comment By: iga Seilnacht (zseil) Date: 2006-06-21 15:59 Message: Logged In: YES user_id=1326842 I think this is a usage error. The problem is that you run moduleX as a script. This puts the module's directory as the first entry in sys.path (see http://docs.python.org/dev/lib/module-sys.html#l2h-5058 for detais). As a consequence, moduleX is recognised as a top level module, not as part of a package. If you want to test relative import, try opening an interactive shell in the directory where `package` resides, and type: from package.subpackage1 import moduleX moduleX.spam 'spam' -- Comment By: Mark Nottingham (mnot) Date: 2006-06-21 14:16 Message: Logged In: YES user_id=21868 Seeing the same behaviour; OSX with the installer. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1510172group_id=5470 ___ Python-bugs-list mailing list
[ python-Bugs-1512504 ] builtin enumerate overflows
Bugs item #1512504, was opened at 2006-06-26 03:50 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1512504group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: James Harlow (hythloday) Assigned to: Raymond Hettinger (rhettinger) Summary: builtin enumerate overflows Initial Comment: The index that the builtin function enumerate() returns is a mere integer and will wrap back to a negative number when it overflows. This seems to be by design (unless I'm misunderstanding the point of PyInt_FromLong), but is sufficiently surprising that I'd suggest it's a bug anyway. I've attached a test case - it takes a while to execute, but the results are so deeply exciting that it's worth doing just for fun! -- Comment By: Raymond Hettinger (rhettinger) Date: 2006-06-27 00:13 Message: Logged In: YES user_id=80475 You're correct. The behavior was by design, emphasizing speed and simplicity over a toy limiting case. If some app actually requires enumeration of over 2**31 objects, it is trivial to write a generator that gives the desired flexibility. Of course, on 64 bit machines, the limit is a bit higher ;-) -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-26 22:22 Message: Logged In: YES user_id=33168 Raymond, any comments? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=105470aid=1512504group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
