Working on Python benchmarking

[tleeuwenb...@gmail.com]

Hi there...

I'm working on a package to provide python benchmarking (profiling and
analysis over time). The idea is to provide a decorator which can be
applied to unit tests which will cause the system to be profiled while
running those tests. The idea would be that any existing set of unit
tests could easily be selectively turned into a benchmarking suite by
the simple application of a decorator. An analysis module would
provide an instant picture of system performance while under test.

I have a basic package which provides the decorator, but have not yet
begun work on a module to provide an effective analysis of results.

I was wondering if anyone had already done any work in this space, and
would like to exchange some ideas? If anyone is interested, I have the
code hosted and can share it, but it's embarassingly primitive so I
don't really want to say I've done anything fantastic just yet! I just
wouldn't mind bouncing ideas around...

Cheers,
-T
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Purely historic question: VT200 text graphic programming

[Blockheads Oi Oi]

On Mar 11, 9:17 am, Anssi Saari  wrote:
> Grant Edwards  writes:
> > C wasn't very widely used under VMS, and VMS had it's own screen
> > formatting and form handling libraries.
>
> Just curious, what language was widely used in VMS? My VMS experience
> is limited to running Maple for a math course in the university in
> early 1990s. Didn't know how to do much more than start Maple,
> probably just dir, logout (or was it logoff?) and ftp :)

The opposite of widely used, how about C with embedded SQL or CORAL
66 :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What do you use with Python for GUI programming and why?

[Adam Tauno Williams]

On Fri, 2011-03-11 at 09:34 -0800, Rafe Kettler wrote:
> On Mar 10, 9:25 pm, Robert  wrote:
> > Is there a push to one toolkit or the other?

I use PyGtk.  It is robust, fast, and integrates well into the desktop.
Also the documentation is very good and the forum very helpful.

My PyGtk app is Imbolc 

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: organizing many python scripts, in a large corporate environment.

[bukzor]

On Mar 11, 10:14 pm, "eryksun ()"  wrote:
> I'm not an expert at Python packaging, but assuming a structure such as
>
> folder1
>        \
>         __init__.py
>         module1.py
> folder2
>        \
>         __init__.py
>         module2.py
>
> within module1, I can import from module2, e.g.:

This only works if you can edit the PYTHONPATH. With thousands of
users and dozens of groups each with their own custom environments,
this is a herculean effort.

$ ./folder1/module1.py
module 1 !
Traceback (most recent call last):
  File "./folder1/module1.py", line 4, in 
import folder2.module2
ImportError: No module named folder2.module2

$ export PYTHONPATH=$PWD
$ ./folder1/module1.py
module 1 !
module 2 !
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Purely historic question: VT200 text graphic programming

[Grant Edwards]

On 2011-03-12, Martin Gregorie  wrote:

> Sorry if I wasn't clear: I was intending to compare APIs rather than the 
> display mechanisms - I am aware that both text terminals and vector 
> graphics terminals are raster devices, not vector like oscilloscopes.  
> What I was getting at is that the API used to cause graphics or text to 
> be output on a dot-matrix printer is totally unlike that used to draw to 
> same representations on a pen plotter.

You're right.  The point I was trying to make was that the 240 was a
superset of the 220, and could be used identically as the 220 was
used. Back in the years when I used a 240 for 8 hours day the the
exact same API was used for the 240 as was used for a 220. The only
exception was the afternoon I decided to write a clock app just to see
how the graphics mode on a 240 worked.  I have no idea why my employer
bought 240's instead of 220's.  It's not like anybody spent a lot of
time looking at drawings of wombats -- in fact, I was probably the
only person at the company who knew you could. [Talk about obscure VMS
allusions...]

-- 
Grant
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: attach to process by pid?

[Grant Edwards]

On 2011-03-12, John Nagle  wrote:
> On 3/9/2011 5:38 PM, Miki Tebeka wrote:
>>> Is there any way to attach to an already running process by pid? I
>>> want to send commands from python to an application that is already
>>> running. I don't want to give the command name to
>>> subprocess.Popen.
>> We probably need more information. What do you mean by "send
>> commands"? (What was your work flow if you could give the command
>> name to Popen?)
>
> There are ways under Windows to attach to a running process and do 
> things to it.  Look up "CreateRemoteThread".  There's a way to
> do this under Linux, too.  See 

> "http://www.codeproject.com/KB/DLL/code_injection.aspx";.

The basic method being used in the recipe above to "mess with" the
target process is the ptrace system call (which is how the debugger
manipulates the state of the target process).  There are probably
other less indirect ways of using ptrace to "hijack" stdin, but
running code in the context of the target process that creates a pipe
and attaches stdin to it might work.

> It is very unlikely that a Python programmer would use either of
> these.  The original poster needs to express more clearly what
> they really want to do.  I suspect they want to create a server
> that client programs can talk to.  There are good ways to do that,
> both on the same machine and across a network.

Oh, Certainly.  The OP's question was so vague that I think we all
know this is just an academic discussion and has nothing (practical)
to do with the OP.

-- 
Grant

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: organizing many python scripts, in a large corporate environment.

[eryksun ()]

bukzor wrote:
> This only works if you can edit the PYTHONPATH. With thousands of
> users and dozens of groups each with their own custom environments,
> this is a herculean effort.

It works for me without setting PYTHONPATH. Again, I run the module from the 
root folder with the -m option as a package module (no .py extension), which is 
easy enough to do with a Windows shortcut. 

No doubt there's a way to hack things to make direct execution work, but I 
don't think it's recommended to directly run a script that's part of a package 
namespace. Experts on the subject can feel free to chime in. 

If you need a site-wide solution that works with Unix shebang, you could 
symlink the names of all the scripts to a dispatcher. Extract the name from 
argv[0] based on the symlink filename, and then find the script in the package 
(or periodically update a stored hash of all scripts). Have the dispatcher run 
it as a package module with `python -m path.to.module [args]`. 

I hope someone else has a better idea...

--
EOF
-- 
http://mail.python.org/mailman/listinfo/python-list

Do you monitor your Python packages in inux distributions?

[skip]

I'm one of the SpamBayes developers and in a half-assed way try to keep
track of SB dribbles on the net via a saved Google search.  About a month
ago I got a hit on an Ubuntu bug tracker about a SpamBayes bug.  As it turns
out, Ubuntu distributes an outdated (read: no longer maintained) version of
SpamBayes.  The bug had been fixed over three years ago in the current
version.  Had I known this I could probably have saved them some trouble, at
least by suggesting that they upgrade.

I have a question for you people who develop and maintain Python-based
packages.  How closely, if at all, do you monitor the bug trackers of Linux
distributions (or Linux-like packaging systems like MacPorts) for activity
related to your packages?  How do you encourage such projects to push bug
reports and/or fixes upstream to you?  What tools are out there to discover
which Linux distributions have SpamBayes packages?  (I know about
rpmfind.net, but there must be other similar sites by now.)

Thx,

-- 
Skip Montanaro - s...@pobox.com - http://www.smontanaro.net/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: organizing many python scripts, in a large corporate environment.

[Tim Johnson]

* Phat Fly Alanna  [110312 07:22]:
> We've been doing a fair amount of Python scripting, and now we have a
> directory with almost a hundred loosely related scripts. It's
> obviously time to organize this, but there's a problem. These scripts
> import freely from each other and although code reuse is  generally a
> good thing it makes it quite complicated to organize them into
> directories.
> 
> There's a few things that you should know about our corporate
> environment:
> 
> 1) I don't have access to the users' environment. Editing the
> PYTHONPATH is out, unless it happens in the script itself.
> 2) Users don't install things. Systems are expected to be *already*
> installed and working, so setup.py is not a solution.
> 
> I'm quite willing to edit my import statements and do some minor
> refactoring, but the solutions I see currently require me to divide
> all  the code strictly between "user runnable scripts" and
> "libraries", which isn't feasible, considering the amount of code.
> 
> Has anyone out there solved a similar problem? Are you happy with it?
  Slightly similar - time doesn't permit details, but I used among
  other things 4 methods that worked well for me:
  1)'Site modules' with controlling constants,including paths
  2)Wrappers for the __import__ function that enabled me to fine -
  tune where I was importing from.
  3)Cut down on the number of executables by using 'loaderers'.
  4)I modified legacy code to take lessons from the MVC architecture,
  and in fact my architecture following these changes could be
  called 'LMVCC' for
  loader
  model
  view
  controller
  config

  I hope I've made some sense with these brief sentences.
-- 
Tim 
tim at johnsons-web.com or akwebsoft.com
http://www.akwebsoft.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Changing class name causes process to 'hang'

[Tim Johnson]

I'm using Python 2.6.5 on ubuntu 10.04 32-bit.
My issue however, is with a code base that goes back to 2002,
which at that time was 1.5~ or so.

I have been since that time using my own cgi module which in turn,
uses the python standard `cgi' module.

The object instantiation has looked something like this:
## code below
cgi = cgilib.cgitools()
## /code

I choose to create a new cgi module by copying `cgilib' as `cgirev'
and renamed the `cgitools' to `Cgi' so that the instantiation
looked like
## code below
cgi = cgirev.Cgi()
## /code

And ran into problems, the cgi script would run almost to
completion, but acted like it lost track of the stack at some point
and would not terminate.

I deleted all .pyc files associated with any file that might be a
dependency. That did not solve the problem.  After scratching my head
and swearing for a couple of hours, I changed the name of the `Cgi'
class back to `cgitools' and everything worked.

## code below
cgi = cgirev.Cgi()
## /code

1)This is a mystery to me that may likely hide other issues that may
come to bite me later.

2)I don't want to be stuck with the `cgitools' classname. 

I have never used a debugger with python. Never had to, python's
error messages have always been my friend and mentor, but in this
case there are no error messages.


I would welcome hints on how to trouble-shoot this issue.
TIA
-- 
Tim 
tim at johnsons-web.com or akwebsoft.com
http://www.akwebsoft.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: organizing many python scripts, in a large corporate environment.

[Tim Johnson]

* Tim Johnson  [110312 10:41]:
<...>   3)Cut down on the number of executables by using 'loaderers'.
  Sheesh! Typo, meant to say 'loaders'..
  sorry
-- 
Tim 
tim at johnsons-web.com or akwebsoft.com
http://www.akwebsoft.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Purely historic question: VT200 text graphic programming

[Martin Gregorie]

On Sat, 12 Mar 2011 17:11:37 +, Grant Edwards wrote:

> The point I was trying to make was that the 240 was a
> superset of the 220, and could be used identically as the 220 was used.
>
Fair enough: I bow to hands-on experience. 

My source - http://vt100.net/vt_history - Says "There is no VT200 as 
such; the VT220 is a text terminal, while the VT240 and VT241 are 
graphics terminals, supporting Digital’s ReGIS graphics and Tektronix 
vector graphics." which I read to mean that a 240/241 wouldn't accept the 
same command set as the 220.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org   |
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Purely historic question: VT200 text graphic programming

[Martin Gregorie]

On Fri, 11 Mar 2011 23:00:25 -0800, Dennis Lee Bieber wrote:

>   Note the last sentence starting "The name ANSI..."
>
Indeed. I'm pretty certain that the first time I met the term "ANSI" was 
in connection with the DOS add-on 'ANSI driver' that allowed programs to 
control the display by emitting escape codes - without it the DOS screen 
was treated as a glass teletype.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org   |
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What do you use with Python for GUI programming and why?

[Stef Mientki]

On 11-03-2011 22:45, Dan Stromberg wrote:
>
> On Fri, Mar 11, 2011 at 12:54 PM, Fred Pacquier  > wrote:
>
> Robert mailto:sigz...@gmail.com>> said :
>
> > Is there a push to one toolkit or the other?
>
> If you are just now getting started, I would honestly suggest you save a
> whole lot of time and dive straight into PyQt. I've tried most 'em over 
> the
> years (including some now discontinued), and in my experience Qt is way
> above the rest, especially as far as consistency and productivity are
> concerned. The Python bindings are very mature and well maintained, and go
> a long way attenuating the evil C++ roots.
>
> I havent tried Nokia's equivalent (PySide). I'm not sure what its fate 
> will
> turn out, given the company's change of heart and Microsoft honeymoon. At
> least PyQt is't going anywhere soon.
>
>
> Didn't Nokia acquire Trolltech (and hence the rights to much if not all of 
> Qt) in 2008?
yep, and they just sold the commercial part of QT to Digia.
>
> I'm not at all sure Qt's future is as bright as one might wish for.  They've 
> already declared that
> Qt will not be ported to Windows Mobile in any official way, and of course 
> mobile (not necessarily
> Windows Mobile) is where just about everything is headed.
And Nokia is talking with Micraosoft about using theirs Phone 7
>
> Actually, for something that's very cross-platform, you might check this out:
> http://radicalbreeze.com/  Bryan can be a bit of a goober, but it sounds like 
> he's successfully
> implemented a great idea for quickly and easily writing cross-platform 
> applications.
another way of reaching the same goal,
is to use a wrapper that supports the different backends.
As I found wxPython much too difficult (I was a Delphi guy),
I started directly with a wrapper when I started using wxPython a few years ago.
In the meanwhile I've extended (very experimental) the wrapper so it not only 
supports wxPython, but
also PyJamas, PySide and PyGUi.

cheers,
Stef
>
> "Illumination even gives you the full Adobe Flex, Android Java, iOS Obj-C and 
> Python source code
> to the projects you create.  Making it a great way to prototype new projects, 
> or learn new languages."
>
> I've still got a soft spot for Pyjamas though - it's opensource.
>

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Purely historic question: VT200 text graphic programming

[Grant Edwards]

On 2011-03-12, Martin Gregorie  wrote:
> On Sat, 12 Mar 2011 17:11:37 +, Grant Edwards wrote:
>
>> The point I was trying to make was that the 240 was a
>> superset of the 220, and could be used identically as the 220 was used.
>>
> Fair enough: I bow to hands-on experience. 
>
> My source - http://vt100.net/vt_history - Says "There is no VT200 as 
> such; the VT220 is a text terminal, while the VT240 and VT241 are 
> graphics terminals, supporting Digital???s ReGIS graphics and Tektronix 
> vector graphics." which I read to mean that a 240/241 wouldn't accept the 
> same command set as the 220.

Yes, that is what it sounds like from that description, but the 240
(mono) and 241 (color) could be used as normal ASCII/ANSI text
terminals (and most of the time they were).  After thinking about it
more, I do remember one graphical app that I used regularly, and that
was a .dvi file previewer that let you view a document typeset by
TeX/LaTeX.  Due to the size/resolution of the screen, it wasn't usable
to actually read a document, but you could check to see if some
particular formatting detail turned out the way you wanted it to.

-- 
Grant Edwards   grant.b.edwardsYow! I want to read my new
  at   poem about pork brains and
  gmail.comouter space ...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Changing class name causes process to 'hang'

[Terry Reedy]

On 3/12/2011 2:53 PM, Tim Johnson wrote:

I'm using Python 2.6.5 on ubuntu 10.04 32-bit.
My issue however, is with a code base that goes back to 2002,
which at that time was 1.5~ or so.

I have been since that time using my own cgi module which in turn,
uses the python standard `cgi' module.

The object instantiation has looked something like this:
## code below
cgi = cgilib.cgitools()
## /code


Is 'cgilib' *your* wrapper of the cgi module, or from a third party.


I choose to create a new cgi module by copying `cgilib' as `cgirev'
and renamed the `cgitools' to `Cgi' so that the instantiation
looked like
## code below
cgi = cgirev.Cgi()
## /code

And ran into problems, the cgi script would run almost to
completion, but acted like it lost track of the stack at some point
and would not terminate.

I deleted all .pyc files associated with any file that might be a
dependency. That did not solve the problem.  After scratching my head
and swearing for a couple of hours, I changed the name of the `Cgi'
class back to `cgitools' and everything worked.

## code below
cgi = cgirev.Cgi()
## /code

1)This is a mystery to me that may likely hide other issues that may
come to bite me later.

2)I don't want to be stuck with the `cgitools' classname.

I have never used a debugger with python. Never had to, python's
error messages have always been my friend and mentor, but in this
case there are no error messages.


Without seeing cgitools/cgirev, it is hard to say. Something like

while True:
  try:
x = cgitools()
break
  except NameError
pass

would produce the symptom ;-)

--
Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

Re: Do you monitor your Python packages in inux distributions?

[Irmen de Jong]

On 12-3-2011 20:26, s...@pobox.com wrote:


I'm one of the SpamBayes developers and in a half-assed way try to keep
track of SB dribbles on the net via a saved Google search.  About a month
ago I got a hit on an Ubuntu bug tracker about a SpamBayes bug.  As it turns
out, Ubuntu distributes an outdated (read: no longer maintained) version of
SpamBayes.  The bug had been fixed over three years ago in the current
version.  Had I known this I could probably have saved them some trouble, at
least by suggesting that they upgrade.

I have a question for you people who develop and maintain Python-based
packages.  How closely, if at all, do you monitor the bug trackers of Linux
distributions (or Linux-like packaging systems like MacPorts) for activity
related to your packages?  How do you encourage such projects to push bug
reports and/or fixes upstream to you?  What tools are out there to discover
which Linux distributions have SpamBayes packages?  (I know about
rpmfind.net, but there must be other similar sites by now.)


Hello Skip.
I'm the author of Pyro and had something similar happening a while ago.
Ubuntu being the distribution in case, and they decided to upgrade their package to the 
still-not-stable version 4 of Pyro. But version 4 is incompatible with Pyro3. 
Predictably, soon afterwards, complaints and bug reports started to appear.


I wasn't aware of all this until I was contacted by a Debian (or Ubuntu, but it doesn't 
really matter) user directly to alert me to the problem. I *did* know that Debian and 
Ubuntu have been including Pyro as a package for quite a while, but I'm not following 
their activity much.


(Via the package 'homepage' I contacted the package maintainer and things have been 
sorted out.)


I tend to glance on the deb package 'homepage' once in a while (few months) to see if 
something interesting pops up in their tracker and such, but I'm doing that randomly.
Also I'm not actively encouraging anybody to push tracker issues upstream to me. I'm not 
spending much time on Pyro, and it seems people know how to find me anyway. What distros 
decide to do with it is their business, I'm just hoping the package maintainer is smart 
enough to know what to do with the issues reported on their trackers (if any).


Besides Debian and Ubuntu I'm not aware of any other distro that includes a Pyro 
package. I found out about Debian/Ubuntu by googling.


All in all probably not a very helpful example but I thought I'd share my 
experience.

Cheers
Irmen de Jong
--
http://mail.python.org/mailman/listinfo/python-list

Re: Do you monitor your Python packages in inux distributions?

[Philip Semanchuk]

On Mar 12, 2011, at 2:26 PM, s...@pobox.com wrote:

> 
> I'm one of the SpamBayes developers and in a half-assed way try to keep
> track of SB dribbles on the net via a saved Google search.  About a month
> ago I got a hit on an Ubuntu bug tracker about a SpamBayes bug.  As it turns
> out, Ubuntu distributes an outdated (read: no longer maintained) version of
> SpamBayes.  The bug had been fixed over three years ago in the current
> version.  Had I known this I could probably have saved them some trouble, at
> least by suggesting that they upgrade.
> 
> I have a question for you people who develop and maintain Python-based
> packages.  How closely, if at all, do you monitor the bug trackers of Linux
> distributions (or Linux-like packaging systems like MacPorts) for activity
> related to your packages?  How do you encourage such projects to push bug
> reports and/or fixes upstream to you?  What tools are out there to discover
> which Linux distributions have SpamBayes packages?  (I know about
> rpmfind.net, but there must be other similar sites by now.)

Hi Skip,
I use google alerts to track where my packages posix_ipc and sysv_ipc get 
mentioned, and they have been turned into packages for Fedora and I think one 
other distro the name of which escapes me at the moment. At first I was really 
pleased to see them made into distro-specific packages because I'm too lazy to 
do it myself. But then I realized the same side effect that you described -- 
the versions distributed via my Web site have moved on and added bug fixes and 
major features like Python 3 support, while the distro-specific packages are 
frozen in time.


I guess via my Google alerts I would learn if a bug was filed against one of my 
outdated packages. I only get 1-2 alerts per day, so they're easy to keep track 
of. If my packages were more popular, I might get so many alerts I'd just stop 
reading them. So far I've never seen a distro-specific bug reported against one 
of my packages. All bugs have been reported directly to me. I hope that 
continues to be the case because I don't have a good solution to the problems 
you mentioned.

Cheers
Philip


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Changing class name causes process to 'hang'

[Tim Johnson]

* Terry Reedy  [110312 13:28]:
> On 3/12/2011 2:53 PM, Tim Johnson wrote:
> 
> Is 'cgilib' *your* wrapper of the cgi module, or from a third party.
  cgilib is my module. I use the cgi module as follows:
## code below
import cgi
self.form = cgi.FieldStorage(keep_blank_values=1)
## /code
> Without seeing cgitools/cgirev, it is hard to say. Something like
> 
> while True:
>   try:
> x = cgitools()
> break
>   except NameError
> pass
> 
> would produce the symptom ;-)
  Hmm! I'm unsure what you mean here, but
  I did do something like this:
## code below
if __name__=="__main__":
import sys,traceback
sys.stderr = sys.stdout ##
try :
print("Content-type: text/html\n")
print("")
cgi = CGI()
print("here")
print("CGI OUTPUT TEST")
for i in range(cgi.len_path_parts()):
print("path part # %d requested: %s" % (i,str(cgi[i])))
except :
traceback.print_exc()
## /code
And I get 
CGI OUTPUT TEST
path part # 0 requested: test
path part # 1 requested: this
Whether I use CGI or cgitools as the class name.

But, if I use CGI as the class name and instantiate from a large application
with numerous dependecies, the process hangs.
The same happens if I 'alias' cgitools, as in
class CGI(cgitools):
pass
It is as if some gremlin lives on my system and insists that I use
the name `cgitools' and only the name `cgitools'. I'm sure
this comes from a side effect somewhere in the process.
thanks for the reply
-- 
Tim 
tim at johnsons-web.com or akwebsoft.com
http://www.akwebsoft.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: OT: processes, terminals and file descriptors on *nix (was: Re: attach to process by pid?)

[Nobody]

On Sat, 12 Mar 2011 00:49:08 +0100, Alexander Kapps wrote:

> I still try to digest your explanations. I thought, that processes 
> just do something like dup()'ing the file descriptors of their 
> terminal but after some strace experiments, I think that is totally 
> wrong.

Actually, the way that descriptors are inherited by a fork()ed process is
akin to dup(). In particular, any descriptors which refer to a
random-access stream (anything which supports lseek(), i.e. a file or
block device) share a single file position, so lseek()ing on a descriptor
will affect the file position for any copies of that stream created by
dup(), dup2() or fork(); the only way to get a stream with its own
position is to open() the file (etc) again. Likewise for the file
status flags (O_APPEND, O_NONBLOCK, etc). However, a "cloned" descriptor
gets its own copy of the file descriptor flags (i.e. the FD_CLOEXEC flag).

open()ing the /proc//fd/ pseudo-files is a bit of a hack, and
Linux-specific. The behaviour is a cross between the fork/dup behaviour
and a separate open() operation. Opening a descriptor which refers to a
pipe opens the "correct" end based upon the mode (read or write), as with
a normal open(), but the resulting descriptor shares its file position and
status flags, as with fork/dup.

> I'd like to learn more about this (how processes, their controlling 
> terminals and the std file descriptors relate)

There's nothing special about the standard descriptors. A child process
inherits all of its parent's descriptors. If the parent has closed any of
its standard descriptors, they'll still be closed in the child
(one exception: Linux will force these descriptors to be open when
executing a setuid executable to avoid potential security issues).

Also, the controlling terminal is unrelated to the standard descriptors.
Upon login, a terminal will typically be assigned as both the controlling
terminal and all three standard descriptors, but they may diverge after
that. E.g. if you start a pipeline ("foo | bar | baz") from the shell,
some of the standard descriptors will be replaced by pipes, but the
controlling terminal will be unaffected. The controlling terminal relates
primarily to signals (Ctrl-C, Ctrl-Z, etc) and job control.

> Do you know any links to deeper material (tried Google but what I've 
> found is to shallow)

I don't have any links. If you want to understand the core Unix API, the
best reference I know of is Stevens ("Advanced Programming in the Unix
Environment", by W. Richard Stevens). Unfortunately, it's not cheap.

In spite of the title, it doesn't assume any prior Unix knowledge; the
"Advanced" mainly refers to the fact that it's the opposite of the "Learn
X in Five Minutes" books, i.e. it's thorough. That's how it comes to >700
pages while only covering the core API (files, processes, and terminals;
no sockets, no X, no I18N, ...).

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Changing class name causes process to 'hang'

[Terry Reedy]

On 3/12/2011 7:18 PM, Tim Johnson wrote:

* Terry Reedy  [110312 13:28]:

On 3/12/2011 2:53 PM, Tim Johnson wrote:

Is 'cgilib' *your* wrapper of the cgi module, or from a third party.



   cgilib is my module. I use the cgi module as follows:
## code below
 import cgi
 self.form = cgi.FieldStorage(keep_blank_values=1)
## /code


And cgitools is a class therein?


Without seeing cgitools/cgirev, it is hard to say. Something like

while True:
   try:
 x = cgitools()
 break
   except NameError
 pass

would produce the symptom ;-)



   Hmm! I'm unsure what you mean here, but


If the name 'cgitools' is used *somewhere*, not necessary in cgilib 
itself, other than in the class header itself, but the resulting 
NameError is *somehow* caught inside a retry loop, then your total 
application would exhibit the symptom you describe ('hanging'). This 
could happen if there is a bare 'except:' statement (these are not 
recommended) that needs to be specific 'except SomeError:'.



   I did do something like this:
## code below
if __name__=="__main__":
 import sys,traceback
 sys.stderr = sys.stdout ##
 try :
 print("Content-type: text/html\n")
 print("")
 cgi = CGI()
 print("here")
 print("CGI OUTPUT TEST")
 for i in range(cgi.len_path_parts()):
 print("path part # %d requested: %s" % (i,str(cgi[i])))
 except :
 traceback.print_exc()
## /code
And I get
CGI OUTPUT TEST
path part # 0 requested: test
path part # 1 requested: this
Whether I use CGI or cgitools as the class name.

But, if I use CGI as the class name and instantiate from a large application
with numerous dependecies, the process hangs.



The same happens if I 'alias' cgitools, as in
class CGI(cgitools):
 pass


You mean you leave 'class cgitools()...' alone within cgilib and just 
add that? That would discredit the theory above. What if you use a 
different alias, like 'moretools'? Are you on an OS where 'cgi' and 
'CGI' could get confused?



It is as if some gremlin lives on my system and insists that I use
the name `cgitools' and only the name `cgitools'. I'm sure
this comes from a side effect somewhere in the process.
thanks for the reply



--
Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

two brief question about abstractproperty

[Darren Dale]

I've been reading PEP 3119 and the documentation for ABCs in the
python documentation. According to the PEP, the following should yield
an error, because the abstract property has not been overridden:

import abc
class C:
__metaclass__ = abc.ABCMeta
@abc.abstractproperty
def x(self):
return 1
c=C()

but an error is not raised, nor for the case where I do:

class D(C):
pass
d=D()

Have I misunderstood the documentation? Why doesn't this raise an
error? I see the same behavior with the @abstractmethod.

Also, why isn't it possible to declare an abstract read/write property
with the decorator syntax:

class C:
__metaclass__ = abc.ABCMeta
@abc.abstractproperty
def x(self):
pass
@x.setter
def x(self, val):
"this is also abstract"

-- 
http://mail.python.org/mailman/listinfo/python-list

IronPython 2.7 Now Available

[Jeff Hardy]

On behalf of the IronPython team, I'm very pleased to announce the
release of IronPython 2.7. This release contains all of the language
features of Python 2.7, as well as several previously missing modules
and numerous bug fixes. IronPython 2.7 also includes built-in Visual
Studio support through IronPython Tools for Visual Studio. IronPython
2.7 requires .NET 4.0 or Silverlight 4.

To download IronPython 2.7, visit
http://ironpython.codeplex.com/releases/view/54498. Any bugs should be
reported at http://ironpython.codeplex.com/workitem/list/basic.

Python 2.7 includes a number of features backported from the Python
3.0 series. This release implements the new builtin _io module,
includes dictionary and set comprehensions, set literals, supports
multiple context managers in the with statement, and adds several new
functions to the itertools methods, and auto indexing for the new
string formatting. There are also numerous updates to the standard
library such as ordered dictionaries and the new argparse module.

This release also includes a “IronPython Tools for Visual Studio”
option within the IronPython installer. This enables one install to
get both IronPython and IronPython Visual Studio support assuming you
have an existing installation of Visual Studio 2010. This version of
IronPython Tools includes a number of bug fixes as improved WPF
designer support. The designer fully supports XAML and WPF including
data binding to Python classes dynamically.

To improve interop with modern .NET code such as LINQ, support for
extension methods has been added as the clr.ImportExtensions method.

We’ve also updated the IronPython installer to include documentation
based upon the CPython documentation. This new .chm file includes
documentation on the Python language and standard library. It’s been
extended from the normal Python documentation to include IronPython
specific topics such as the DLR hosting APIs and extending IronPython
from statically typed .NET languages.

We flushed out more support for missing built-in modules which CPython
includes. This release includes the mmap and signal modules bringing
better support for interoperating with unmanaged code, the zlib and
gzip modules for compression, and the subprocess and webbrowser
modules for interacting with other programs.

As usual there are a number of bug fixes and performance improvements.
This release includes major performance improvements in cPickle, the
sum built-in function, and includes support for fast exceptions which
do not use the .NET exception mechanism. There have also been
improvements to significantly reduce memory usage of the IronPython
ASTs. One of the end results of these numerous improvements is that
IronPython’s startup time has decreased by 10% when compared to
IronPython 2.6.1.

This is the first full community release of IronPython, and I want to
give a huge thank you to everyone who was involved in this release.

- Jeff
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: two brief question about abstractproperty

[Darren Dale]

On Mar 12, 11:16 pm, Darren Dale  wrote:
> I've been reading PEP 3119 and the documentation for ABCs in the
> python documentation. According to the PEP, the following should yield
> an error, because the abstract property has not been overridden:
>
> import abc
> class C:
>     __metaclass__ = abc.ABCMeta
>     @abc.abstractproperty
>     def x(self):
>         return 1
> c=C()
>
> but an error is not raised

I guess the problem was not using the appropriate syntax for python 3:

class C(metaclass=abc.ABCMeta):
...

> Also, why isn't it possible to declare an abstract read/write property
> with the decorator syntax:
>
> class C:
>     __metaclass__ = abc.ABCMeta
>     @abc.abstractproperty
>     def x(self):
>         pass
>     @x.setter
>     def x(self, val):
>         "this is also abstract"

It seems like this syntax should be possible, that instantiation would
check that if the C.x is an abstract property and the x.setter has
been specified, then subclasses of C need to specify a setter before
they can be instantiated.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How should I handle socket receiving?

[Tim Roberts]

Hans  wrote:
>
>I'm thinking to write a code which to:
>1. establish tons of udp/tcp connections to a server

What does "tons" mean?  Tens?  Hundreds?

>my question is how should I handle receiving traffic from each
>connection respectively? 

You're really going to want to use "select".  You can store the objects in
a dictionary where the key is the socket number.  That way, you can use the
result of the select and get your network object directly.
-- 
Tim Roberts, t...@probo.com
Providenza & Boekelheide, Inc.
-- 
http://mail.python.org/mailman/listinfo/python-list