Queue question
- A two parter newbie question I am afraid. Am I right in thinking that using something like ... item = a_queue.get() print item will not print 'item' unless or until there is an item in the queue to retrieve. Effectively stalling the thread at the .get() instruction? I can see that this it may be tested for, using the .empty() function thereby allowing the code to progress if there was nothing in the queue, but how is .not_empty used ? Thanks in advance - -- http://mail.python.org/mailman/listinfo/python-list
Re: Queue question
Ahh the penny has dropped at last. I am using the WingIDE and .not_empty is one of the properties it exposes with it's intellisense. As such its use is not documented. No problem. Using the exception would more accurate - I can see that. In my simple case the queue is a one to one link, into and out of a single thread and so I can use the .empty() call with impunity. I can see that using queue's may be overkill in this instance but it has been good practice to get to know how they operate. Being new to python I am just getting used to syntax and conventions, your reply has clarrified the issue for me. Thank you for posting Steve. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to organize Python files in a (relatively) big project
I have this problem myself, and as I am a recent Python convert my aproach may not be conventional - but as it is working for me I thought I would share. First off you need to split your code into logical objects. In my case I have an obvious client and server object, But within each I have individual stand alone major objects and so my directory structure reflects this... Prog Dir -- MainApp.py Bin __init__.py --- main.py --- lib.py Client __init__.py --- main.py Browser 1 __init__.py --- main.py --- B1_file1.py --- B1_file2.py Browser 2 __init__.py --- main.py --- B2_file1.py --- B2_file2.py Server __init__.py --- main.py Server Object 1 __init__.py --- main.py --- SO1_file1.py --- SO1_file2.py Server Object 2 __init__.py --- main.py --- SO2_file1.py --- SO2_file2.py Each main.py file is used to call each downstream main.py file be it as a thread or once only run. The beauty of this idea is that if I want to completely change say Server Object 2, I can do whatever I like within the downstream directory as the only outside call is via an external reference to the main.py file. If you have a mind, you could have a library file of common apps held within the bin directory that you can make available to all downstream modules. As I say - it only works if you can logically split your program into independent blocks. If there is a more Pythonesque way of doing this I be grateful if someone could share. HTH -- http://mail.python.org/mailman/listinfo/python-list
Re: IronPython 1.0 - Bugs or Features?
Claudio Grondi wrote: > tjreedy wrote: > > "Claudio Grondi" <[EMAIL PROTECTED]> wrote in message > > news:[EMAIL PROTECTED] > > > >>I also erroneously assumed, that the first problem was detected during > >>parsing ... so, by the way: how can I distinguish an error raised while > >>parsing the code and an error raised when actually running the code? > > > > > > Parsing detects and reports syntax errors and maybe something else if you > > use non-ascii chars without matching coding cookie. Other errors are > > runtime. > Let's consider >print '"Data ê"' > > In CPython 2.4.2 there is in case of non-ascii character: >sys:1: DeprecationWarning: Non-ASCII character '\xea' in file > C:\IronPython-1.0-BugsOrFeatures.py on line 3, but no encoding > declared; see http://www.python.org/peps/pep-0263.html for details > "Data♀♂ Û" > > IronPython does not raise any warning and outputs: > "Data♀♂ ?" > > So it seems, that IronPython is not that close to CPython as I have it > expected. > It takes much more time to run this above simple script in IronPython as > in CPython - it feels as IronPython were extremely busy with starting > itself. > > Claudio Grondi IronPython is a .NET language, so does that mean that it invokes the JIT before running actual code? If so, then "simple short scripts" would take longer with IronPython "busy starting itself" loading .NET and invoking the JIT. This effect would be less noticable, the longer the program is. But I'm just guessing; I've not used IronPython. -- http://mail.python.org/mailman/listinfo/python-list
Re: IronPython 1.0 released today!
Congrats on reaching 1.0, Jim. BTW, here's a John Udell screencast of Jim demo'ing IronPython. Among other things, it shows IronPython integrating with Visual Studio, Monad, C#, VB.NET, and WPF. It's a great video. http://weblog.infoworld.com/udell/2006/08/30.html#a1515 -- http://mail.python.org/mailman/listinfo/python-list
