[ANN] argparse 1.1 - Command-line parsing library

[Steven Bethard]

===
Announcing argparse 1.1
===
The argparse module provides an easy, declarative interface for
creating command line tools, which knows how to:
 * parse the arguments and flags from sys.argv
 * convert arg strings into objects for your program
 * format and print informative help messages
 * and much more...

The argparse module improves on the standard library optparse module
in a number of ways including:
 * handling positional arguments
 * supporting sub-commands
 * allowing alternative option prefixes like + and /
 * handling zero-or-more and one-or-more style arguments
 * producing more informative usage messages
 * providing a much simpler interface for custom types and actions

Download argparse
=
The argparse homepage has links for source, MSI and single file
distributions of argparse:
 http://code.google.com/p/argparse/

About this release
==
This is the final release of argparse before its move to the Python
2.7 and 3.2 standard libraries. Major enhancements in this release:

* ArgumentParser(..., version=XXX) is deprecated. Instead, you should
  use add_argument(..., action='version') which is more flexible and
  does not force you to accept -v/--version as your version flags.

* Usage and help (but not version) messages are now written to stdout
  instead of stderr, consistent with most existing programs.

* User defined types passed as a type= argument can now raise an
  ArgumentTypeError to provide a custom error message.

* Namespace objects now support containment, e.g. "'foo' in args".

Various bugs were also squashed, e.g. "from argparse import *" now
works. See the news file for detailed information:

  http://argparse.googlecode.com/svn/tags/r11/NEWS.txt

Enjoy!

Steve
-- 
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Six Minutes and fourty two seconds

[Anthra Norell]

Tobiah wrote:
Now that I use python, this is the amount of time 
per day that I spend adding forgotten semicolons while

debugging other languages.
  

What compels you to write Python code without semicolons?

Frederic

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

Detecting new removable drives in Linux

[Bart Smeets]

Hello,

I'm trying to write a script which detects when a new removable drive is
connected to the computer. On #python I was advised to use the
dbus-bindings. However the documentation on this is limited. Does anyone
know of an example of how I can detect new removable drives?

Thanks in advance!
Regards,
Bart
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to use python to register a service (an existing .exe file)

[Chris Withers]

Aahz wrote:

In article <4b79e28c$0$4610$426a7...@news.free.fr>,
News123   wrote:


Is there a python way to register new windows services.

I am aware of the
instsrv.exe program, which can be used to install services.
I could use subprocess.Popen to call

instsrv.exe "service_name" program.exe

but wondered, whether there's already an existing function.


Use the win32 package.


Indeed, there's some intersting code in this area here:

http://svn.zope.org/Zope/trunk/src/nt_svcutils/service.py?rev=104819&view=auto

http://svn.zope.org/Zope/trunk/src/Zope2/Startup/zopectl.py?rev=105396&view=auto

...particularly in the do_install function in the latter...

Chris


--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk

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

Re: Docstrings considered too complicated

[Jean-Michel Pichavant]

MRAB wrote:

Gregory Ewing wrote:

Mel wrote:

You could think of it as a not bad use of the design principle 
"Clear The Simple Stuff Out Of The Way First".  Destinations are 
commonly a lot simpler than sources


That's not usually true in assembly languages, though,
where the source and destination are both very restricted
and often about the same complexity.

That's not to say that right-to-left is the wrong way
to do it in an assembly language, but there are less
misleading words than "move" that could be used.

Z80 assembly language uses "load", which makes things
considerably clearer:

  LD A, B  ; load A with B


Some processors distinguish between "load" (memory to register) and
"store" (register to memory), and the destination and LHS operand of
binary operations might be the same register, for example:

CLC ; clear the carry
LDA first ; accumulator := byte at first
ADCA second ; accumulator := accumulator + byte at second + carry
STA result ; byte at third := accumulator

Guys, you sound like people arguing about old school TV show / series 
like star treck :-)

- "He was wearing a blue suit !"
- "Check episode number 29, he appeared with a pink one!"

I'm glad I'm too young to had to code in assembler, or to bear the 
vision of those unlikely space suits from the 70's ;-)


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

pythonpath

[luca72]

Sorry for my stupid question if i have to load module from a folder i
have to append it to the sys path the folder?
ex:
if my  folder module is  /home/lucak904/Scrivania/Luca/enigma2
i do this :
import sys
sys.path.append('/home/lucak904/Scrivania/Luca/enigma2')
If this is correct why when i write:
form enigma2 import *
i get no module named enigma2

Thanks
Luca

I'm under linux


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

Re: Starting Python from the terminal with no welcome message

[candide]

Tim Chase a écrit :

> 
>   bash$ python -ic ""
> 
> to get a python shell without the banner.
>


Works fine. thanks a lot.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: taking python enterprise level?...

[simn_stv]

On Feb 25, 12:21 pm, "Martin P. Hellwig" 
wrote:
> On 02/25/10 10:26, simn_stv wrote:
> > what i am concerned about is scalability and
> > efficiency, well, as far as the 'core' is concerned.
>
> > would python be able to manage giving me a solid 'core' and will i be
> > able to use python provide any API i would like to implement?...
>
> 
> Python isn't the most efficient language, the assembler provided by the
> maker of your CPU probably is the best you can get,

LOL...;), yeah right, the mere thought of writing assembler
instructions is SCARY!!

>everything after
> that is a trade-off between performance and flexibility (flexible in the
> most flexible sense of the word :-)).
>
> That being said, for me, Python (well actually any turing complete
> programming language), is more like a box of lego with infinite amount
> of pieces.
> Scalability and API issues are the same as the shape and function of the
> model your making with lego.
>
> Sure some type of pieces might be more suited than other types but since
> you can simulate any type of piece with the ones that are already
> present, you are more limited by your imagination than by the language.
>
> So in short, I don't see any serious problems using Python, I have used
> it in Enterprise environments without any problems but than again I was
> aware not to use it for numerical intensive parts without the use of 3rd
> party libraries like numpy. Which for me resulted in not doing the
> compression of a database delta's in pure python but to offload that to
> a more suitable external program, still controlled from Python though.
>
> --
> mph

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

Re: pythonpath

[刘宇辉]

>Sorry for my stupid question if i have to load module >from a folder ihave
to append it to the sys path the >folder?
>ex:
>if my  folder module is  /home/lucak904/Scrivania/Luca/enigma2
>i do this :
>import sys
>sys.path.append('/home/lucak904/Scrivania/Luca/enigma2')
>If this is correct why when i write:
>form enigma2 import *
>i get no module named enigma2

is  the folder module  /home/lucak904/Scrivania/Luca/enigma2.py?   i think
the extension  is necessary .

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

Re: taking python enterprise level?...

[simn_stv]

On Feb 25, 5:18 pm, "D'Arcy J.M. Cain"  wrote:
> On Thu, 25 Feb 2010 15:29:34 +
> "Martin P. Hellwig"  wrote:
>
> > On 02/25/10 13:58, D'Arcy J.M. Cain wrote:
> > > On Thu, 25 Feb 2010 02:26:18 -0800 (PST)
> > 
> > > Our biggest problem was in
> > > a network heavy element of the app and that was low level TCP/IP stuff
> > > that rather than being Python's problem was something we used Python to
> > > fix.
> > 
> > Out off interest, could you elaborate on that?
>
> Somewhat - there is an NDA so I can't give exact details.  It was
> crucial to our app that we sync up databases in Canada and the US (later
> Britain, Europe and Japan) in real time with those transactions.  Our
> problem was that even though our two server systems were on the
> backbone, indeed with the same major carrier, we could not keep them in
> sync.  We were taking way to long to transact an update across the
> network.
>
> The problem had to do with the way TCP/IP works, especially closer to
> the core.  Our provider was collecting data and sending it only after
> filling a buffer or after a timeout.  The timeout was short so it
> wouldn't normally be noticed and in most cases (web pages e.g.) the
> connection is opened, data is pushed and the connection is closed so
> the buffer is flushed immediately.  Our patterns were different so we
> were hitting the timeout on every single transaction and there was no
> way we would have been able to keep up.
>
> Our first crack at fixing this was to simply add garbage to the packet
> we were sending.  Making the packets an order of magnitude bigger sped
> up the proccessing dramatically.  That wasn't a very clean solution
> though so we looked for a better way.
>
> That better way turned out to asynchronous update transactions.  All we
> did was keep feeding updates to the remote site and forget about ACKS.
> We then had a second process which handled ACKS and tracked which
> packets had been properly transferred.  The system had IDs on each
> update and retries happened if ACKS didn't happen soon enough.
> Naturally we ignored ACKS that we had already processed.
>
> All of the above (and much more complexity not even discussed here) was
> handled by Python code and database manipulation.  There were a few
> bumps along the way but overall it worked fine.  If we were using C or
> even assembler we would not have sped up anything and the solution we
> came up with would have been horrendous to code.  As it was I and my
> chief programmer locked ourselves in the boardroom and had a working
> solution before the day was out.

sure it wouldnt have sped it up a bit, even a bit?; probably the
development and maintenance time would be a nightmare but it should
speed the app up a bit...

>
> Python wins again.
>
> --
> D'Arcy J.M. Cain  |  Democracy is three 
> wolveshttp://www.druid.net/darcy/   |  and a sheep voting on
> +1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.

seriously added to the reputation of python, from my own
perspective...kudos python!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Detecting new removable drives in Linux

[Albert Hopkins]

On Mon, 2010-03-01 at 10:48 +0100, Bart Smeets wrote:
> Hello,
> 
> 
> I'm trying to write a script which detects when a new removable drive
> is connected to the computer. On #python I was advised to use the
> dbus-bindings. However the documentation on this is limited. Does
> anyone know of an example of how I can detect new removable drives?

The documentation does suck and, at least for the python bindings, is
horribly outdated.

Also, the python bindings for dbus are not as "pythonic" as they could
be.  I was working on a python/dbus program a while back and basically
had to resort to looking at the source of a program that did, or almost
did, what I wanted and using that as an example.

You may even want to look at C sources as I don't think the python
bindings are that much different.

HTH,
-a



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

Re: Sample code usable Tkinter listbox

[Alf P. Steinbach]

* rantingrick:


kw.setdefault('activestyle', 'none')


Hm, let me steal this line... Thanks!


Cheers,

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

Re: pythonpath

[Albert Hopkins]

On Mon, 2010-03-01 at 02:48 -0800, luca72 wrote:
> Sorry for my stupid question if i have to load module from a folder i
> have to append it to the sys path the folder?
> ex:
> if my  folder module is  /home/lucak904/Scrivania/Luca/enigma2
> i do this :
> import sys
> sys.path.append('/home/lucak904/Scrivania/Luca/enigma2')
> If this is correct why when i write:
> form enigma2 import *
> i get no module named enigma2

There are two reasons for this:

 1. enigma2 is not in your namespace.  What's inside enigma is.  For
example, you can't say "from site-packages import *"  because
Python doesn't look at "site-packages". It looks at what's
inside site-packages.  If you wanted" enigma2" to be in your
namespace, you should add /home/lucak904/Scrivania/Luca" to your
system path.
 2. Even if you did above, it may not work because enigma2 is a
directory. Remember "from x import *" only works for modules and
packages, so if you want "enigma2" to be a package, remember to
add an (empty) __init__.py to the directory.

Hope this helps.
-a


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

Re: taking python enterprise level?...

[simn_stv]

On Feb 25, 5:18 pm, "D'Arcy J.M. Cain"  wrote:
> On Thu, 25 Feb 2010 15:29:34 +
> "Martin P. Hellwig"  wrote:
>
> > On 02/25/10 13:58, D'Arcy J.M. Cain wrote:
> > > On Thu, 25 Feb 2010 02:26:18 -0800 (PST)
> > 
> > > Our biggest problem was in
> > > a network heavy element of the app and that was low level TCP/IP stuff
> > > that rather than being Python's problem was something we used Python to
> > > fix.
> > 
> > Out off interest, could you elaborate on that?
>
> Somewhat - there is an NDA so I can't give exact details.  It was
> crucial to our app that we sync up databases in Canada and the US (later
> Britain, Europe and Japan) in real time with those transactions.  Our
> problem was that even though our two server systems were on the
> backbone, indeed with the same major carrier, we could not keep them in
> sync.  We were taking way to long to transact an update across the
> network.
>
> The problem had to do with the way TCP/IP works, especially closer to
> the core.  Our provider was collecting data and sending it only after
> filling a buffer or after a timeout.  The timeout was short so it
> wouldn't normally be noticed and in most cases (web pages e.g.) the
> connection is opened, data is pushed and the connection is closed so
> the buffer is flushed immediately.  Our patterns were different so we
> were hitting the timeout on every single transaction and there was no
> way we would have been able to keep up.
>
> Our first crack at fixing this was to simply add garbage to the packet
> we were sending.  Making the packets an order of magnitude bigger sped
> up the proccessing dramatically.  That wasn't a very clean solution
> though so we looked for a better way.
>
> That better way turned out to asynchronous update transactions.  All we
> did was keep feeding updates to the remote site and forget about ACKS.
> We then had a second process which handled ACKS and tracked which
> packets had been properly transferred.  The system had IDs on each
> update and retries happened if ACKS didn't happen soon enough.
> Naturally we ignored ACKS that we had already processed.
>
> All of the above (and much more complexity not even discussed here) was
> handled by Python code and database manipulation.  There were a few
> bumps along the way but overall it worked fine.  If we were using C or
> even assembler we would not have sped up anything and the solution we
> came up with would have been horrendous to code.  As it was I and my
> chief programmer locked ourselves in the boardroom and had a working
> solution before the day was out.

sure it wouldnt have sped it up a bit, even a bit?; probably the
development and maintenance time would be a nightmare but it should
speed the app up a bit...

>
> Python wins again.
>
> --
> D'Arcy J.M. Cain  |  Democracy is three 
> wolveshttp://www.druid.net/darcy/   |  and a sheep voting on
> +1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.

seriously added to the reputation of python, from my own
perspective...kudos python!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: taking python enterprise level?...

[simn_stv]

On Feb 26, 10:32 am, mdipierro  wrote:
> 100,000 hits a day is not a low. I get that some day on my web server
> without problem and without one request dropped.
>
> Most frameworks web2py, Django, Pylons can handle that kind of load
> since Python is not the bottle neck.
taking a look at django right now, doesnt look too bad from where im
standing, maybe when i get into the code i'd run into some issues that
would cause some headaches!!

> You have to follow some tricks:
>
> 1) have the web server serve static pages directly and set the pragma
> cache expire to one month
> 2) cache all pages that do not have forms for at least few minutes
> 3) avoid database joins

but this would probably be to the detriment of my database design,
which is a no-no as far as im concerned. The way the tables would be
structured requires 'joins' when querying the db; or could you
elaborate a little??

> 4) use a server with at least 512KB Ram.

hmmm...!, still thinking about what you mean by this statement also.

> 5) if you pages are large, use gzip compression
>
> If you develop your app with the web2py framework, you always have the
> option to deploy on the Google App Engine. If you can live with their
> constraints you should have no scalability problems.
>
> Massimo
>
> On Feb 25, 4:26 am, simn_stv  wrote:
>
> > hello people, i have been reading posts on this group for quite some
> > time now and many, if not all (actually not all!), seem quite
> > interesting.
> > i plan to build an application, a network based application that i
> > estimate (and seriously hope) would get as many as 100, 000 hits a day
> > (hehe,...my dad always told me to 'AIM HIGH' ;0), not some 'facebook'
> > or anything like it, its mainly for a financial transactions which
> > gets pretty busy...
> > so my question is this would anyone have anything that would make
> > python a little less of a serious candidate (cos it already is) and
> > the options may be to use some other languages (maybe java, C (oh
> > God))...i am into a bit of php and building API's in php would not be
> > the hard part, what i am concerned about is scalability and
> > efficiency, well, as far as the 'core' is concerned.
>
> > would python be able to manage giving me a solid 'core' and will i be
> > able to use python provide any API i would like to implement?...
>
> > im sorry if my subject was not as clear as probably should be!.
> > i guess this should be the best place to ask this sort of thing, hope
> > im so right.
>
> > Thanks

thanks for the feedback...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Detecting new removable drives in Linux

[Stefan Behnel]

Bart Smeets, 01.03.2010 10:48:
> I'm trying to write a script which detects when a new removable drive is
> connected to the computer. On #python I was advised to use the
> dbus-bindings. However the documentation on this is limited. Does anyone
> know of an example of how I can detect new removable drives?

You could execute a script from HAL, e.g. using halevt, and let the script
communicate with your program.

http://www.nongnu.org/halevt/

Stefan

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

Re: Docstrings considered too complicated

[alex23]

Andreas Waldenburger  wrote:
> But as I said: a) I am (we are) not in a position to impose this (We
> don't work with the code, we just run the software).

I personally believe that the end users have _every_ right to impose
quality requirements on  code used within their business...although I
may not bring this up in front of them at meetings :)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Docstrings considered too complicated

[Andreas Waldenburger]

On Mon, 1 Mar 2010 05:01:49 -0800 (PST) alex23 
wrote:

> Andreas Waldenburger  wrote:
> > But as I said: a) I am (we are) not in a position to impose this (We
> > don't work with the code, we just run the software).
> 
> I personally believe that the end users have _every_ right to impose
> quality requirements on  code used within their business...although I
> may not bring this up in front of them at meetings :)

Huh? That's like demanding a certain type of truck or vehicle
maintenance plan from a trucking company. Sure, you *could* do it, but
that effectively only limits your options. I think there should be a
clear separation of concerns here.

/W

-- 
INVALID? DE!

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

connect with me

[sayed jewel21]

dear guys you can do subscribe with site easily-

http://freelivestreamonlinepctv.blogspot.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

ANN: A new version (0.2.4) of the Python module which wraps GnuPG has been released.

[Vinay Sajip]

A new version of the Python module which wraps GnuPG has been
released.

What Changed?
=
This is a minor enhancement release. See the project website (
http://code.google.com/p/python-gnupg/ ) for more information.

The current version passes all tests on Windows (Python 2.4, 2.5, 2.6,
3.1, Jython 2.5.1) and Ubuntu (Python 2.4, 2.5, 2.6, 3.0, Jython
2.5.1).

What Does It Do?

The gnupg module allows Python programs to make use of the
functionality provided by the Gnu Privacy Guard (abbreviated GPG or
GnuPG). Using this module, Python programs can encrypt and decrypt
data, digitally sign documents and verify digital signatures, manage
(generate, list and delete) encryption keys, using proven Public Key
Infrastructure (PKI) encryption technology based on OpenPGP.

This module is expected to be used with Python versions >= 2.4, as it
makes use of the subprocess module which appeared in that version of
Python. This module is a newer version derived from earlier work by
Andrew Kuchling, Richard Jones and Steve Traugott.

A test suite using unittest is included with the source distribution.

Simple usage:

>>> import gnupg
>>> gpg = gnupg.GPG(gnupghome='/path/to/keyring/directory')
>>> gpg.list_keys()
[{
  ...
  'fingerprint': 'F819EE7705497D73E3CCEE65197D5DAC68F1AAB2',
  'keyid': '197D5DAC68F1AAB2',
  'length': '1024',
  'type': 'pub',
  'uids': ['', 'Gary Gross (A test user) ']},
 {
  ...
  'fingerprint': '37F24DD4B918CC264D4F31D60C5FEFA7A921FC4A',
  'keyid': '0C5FEFA7A921FC4A',
  'length': '1024',
  ...
  'uids': ['', 'Danny Davis (A test user) ']}]
>>> encrypted = gpg.encrypt("Hello, world!", ['0C5FEFA7A921FC4A'])
>>> str(encrypted)
'-BEGIN PGP MESSAGE-\nVersion: GnuPG v1.4.9 (GNU/Linux)\n
\nhQIOA/6NHMDTXUwcEAf
...
-END PGP MESSAGE-\n'
>>> decrypted = gpg.decrypt(str(encrypted), passphrase='secret')
>>> str(decrypted)
'Hello, world!'
>>> signed = gpg.sign("Goodbye, world!", passphrase='secret')
>>> verified = gpg.verify(str(signed))
>>> print "Verified" if verified else "Not verified"
'Verified'

For more information, visit http://code.google.com/p/python-gnupg/ -
as always, your feedback is most welcome (especially bug reports,
patches and suggestions for improvement). Enjoy!

Cheers

Vinay Sajip
Red Dove Consultants Ltd.
-- 
http://mail.python.org/mailman/listinfo/python-list

python socket service related question!

[elca]

Hello,All

im totally new to socket programming in python. i was read some tutorial and
manual, but i didn't found what i want to make python related socket script
in manual or tutorial.

i want to make socket script which can send some info to server and also
receive some info from server. For example, i want to send my login
information to server, and want to receive result reply from server.

but i have no idea..how to send my login  information(id and password) to
server.

i was captured with wireshark, some process to send login info to server.

and i was found port number is 5300 and server ip is 58.225.56.152

and i was send id is 'aaa' and password 'bbb' and i was received

'USER NOT FOUND' result from server.

how can i make this kind of process with python socket ?

if anyone help me some reference or some example or anything help much
appreciate!

   00 50 56 f2 c8 cc 00 0c 29 a8 f8 c0 08 00 45 00  .PV.).E.
0010   00 e2 2a 19 40 00 80 06 d0 55 c0 a8 cb 85 3a e1  @u:.
0020   38 98 05 f3 15 9a b9 86 62 7b 0d ab 0f ba 50 18  8...b{P.
0030   fa f0 26 14 00 00 50 54 3f 09 a2 91 7f 13 00 00  ..&...PT?...
0040   00 1f 14 00 02 00 00 00 00 00 00 00 07 00 00 00  
0050   61 61 61 61 61 61 61 50 54 3f 09 a2 91 7f 8b 00  aaaPT?..
0060   00 00 1f 15 00 08 00 00 00 07 00 00 00 61 61 61  .aaa
0070   61 61 61 61 07 00 00 00 62 62 62 62 62 62 62 01  bbb.
0080   00 00 00 31 02 00 00 00 4b 52 0f 00 00 00 31 39  ...1KR19
0090   32 2e 31 36 38 2e 32 30 33 2e 31 33 33 30 00 00  2.168.203.1330..
00a0   00 4d 69 63 72 6f 73 6f 66 74 20 57 69 6e 64 6f  .Microsoft Windo
00b0   77 73 20 58 50 20 50 72 6f 66 65 73 73 69 6f 6e  ws XP Profession
00c0   61 6c 20 53 65 72 76 69 63 65 20 50 61 63 6b 20  al Service Pack 
00d0   32 14 00 00 00 31 30 30 31 33 30 30 35 33 31 35  210013005315
00e0   37 38 33 37 32 30 31 32 33 03 00 00 00 34 37 30  783720123470

   00 0c 29 a8 f8 c0 00 50 56 f2 c8 cc 08 00 45 00  ..)PV.E.
0010   00 28 ae 37 00 00 80 06 8c f1 3a e1 38 98 c0 a8  .(.7..:.8...
0020   cb 85 15 9a 05 f3 0d ab 0f ba b9 86 63 35 50 10  c5P.
0030   fa f0 5f 8e 00 00 00 00 00 00 00 00  .._.

   00 0c 29 a8 f8 c0 00 50 56 f2 c8 cc 08 00 45 00  ..)PV.E.
0010   00 4c ae 38 00 00 80 06 8c cc 3a e1 38 98 c0 a8  .L.8..:.8...
0020   cb 85 15 9a 05 f3 0d ab 0f ba b9 86 63 35 50 18  c5P.
0030   fa f0 3e 75 00 00 50 54 3f 09 a2 91 7f 16 00 00  ..>u..PT?...
0040   00 1f 18 00 01 00 00 00 0e 00 00 00 55 73 65 72  User
0050   20 4e 6f 74 20 46 6f 75 6e 64 Not Found


-- 
View this message in context: 
http://old.nabble.com/python-socket-service-related-question%21-tp27743609p27743609.html
Sent from the Python - python-list mailing list archive at Nabble.com.

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

Permission Problem

[Victor Subervi]

Hi;
I encountered and solved this problem before with the help of the list, but
it's back, and I've reviewed and done everything I was shown to do last
time, so I'm lost. Here's the script:

#!/usr/bin/python

import cgitb; cgitb.enable()
import cgi
import sys,os
sys.path.append(os.getcwd())
from login import login
import MySQLdb
import re, string
import fpformat

form = cgi.FieldStorage()
width = form.getfirst('width')
lines = '''
#!/usr/bin/python

return %s''' % width
f = 'width.py'
try:
  os.remove(f)
except OSError:
  pass
f = open(f, 'w')
f.writelines(lines)
f.close()

Simple enough. Here's the permissions:

drwxrwxrwx 31 root root   4096 Feb 23 04:57 ..
-rwxrwxrwx  1 root root390 Mar  1 05:52 preload.py

All loaded up deliberately to try and get it to work. Here's the error:

 /var/www/html/globalsolutionsgroup.vi/preload.py
   21 except OSError:
   22   pass
   23 f = open(f, 'w')
   24 f.writelines(lines)
   25 f.close()
f = 'width.py', builtin open = 
IOError: [Errno 13] Permission denied: 'width.py'
  args = (13, 'Permission denied')
  errno = 13
  filename = 'width.py'
  strerror = 'Permission denied'

What'd I do wrong?
TIA,
beno

-- 
The Logos has come to bear
http://logos.13gems.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Class attributes / methods lost?

[Gabor Urban]

Hi guys,

I am building a nested data structure with the following compontens:

<>

class Item:
def __init__(self, pId, pChange, pComment):
self.ID = pId
self.Delta = pChange
self.Comment = pComment

def PrintItem(self):
str = '%s,%s,%s'%(self.ID,self.Delta,self.comment)
return str

class Package:
def __init__(self, pSerial, pDate, pOwner, pSchema):
self.serial = pSerial
self.date = pDate
self.owner = pOwner
self.schema = pSchema
self.items = []

def insertItem(self, pItem):
self.items.append(pItem)

def printPackage(self):
lines = []
str = '%s,%s,%s,%s'%(self.serial,self.date,self.owner,self.schema)
number = self.items.length
for idx in xrange(number):
line = ''
istr = self.items[idx].PrintItem()
line = str + ',' + istr
lines.append(line)
return lines

<>

The above structure is processed with next code:

<>

size = len(packages)
package = None
for index in xrange(size):
logger.info('PrettyPrinting package id=%d',index)
oplines = []
oplines = packages[index].printPackage()
for i in xrange(oplines.length):
data.append(oplines[i])
<>

I've got the next error message:
' Traceback (most recent call last):
  File "XmlHistory_orig.py", line 203, in ?
oplines = packages[index].printPackage()
TypeError: unbound method printPackage() must be called with Package
instance as first argument (got nothing instead) '

I did give a try to access the fields directly

<>
packages = []
data = []

size = len(packages)
for index in xrange(size):
str = 
'%s,%s,%s,%s'%(packages[index].serial,packages[index].date,packages[index].owner,packages[index].schema)
itemnum = len(packages[index].items)
oplines = []
for itemIndx in xrange(itemnum):
element =
'%s,%s,%s'%(packages[index].items[itemIdx].ID,packages[index].items[itemIdx].Delta,packages[index].items[itemIdx].comment)
oplines.append(str + ','+elemt)

<>

Error:

Traceback (most recent call last):
  File "XmlHistory.py", line 204, in ?
str = 
'%s,%s,%s,%s'%(packages[index].serial,packages[index].date,packages[index].owner,packages[index].schema)
AttributeError: class Package has no attribute 'serial'

The strange in this issue for me, that I do not see why are the class
methods and fields lost.

Any idea is wellcome.

Gabor
-- 
Linux: Choice of a GNU Generation
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Class attributes / methods lost?

[Peter Otten]

Gabor Urban wrote:

> I am building a nested data structure with the following compontens:



> Any idea is wellcome.

The error messages suggest that you are using classes where you should be 
using class instances, but you don't provide the code where this problem 
originates.

The code you do give looks like a very literal and incomplete conversion 
from Java. Rather than go into the details I suggest that you have a look at 
the Tutorial (and PEP 8) before you proceed.

http://docs.python.org/tutorial/index.html
http://www.python.org/dev/peps/pep-0008/

Peter


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

Re: taking python enterprise level?...

[D'Arcy J.M. Cain]

On Mon, 1 Mar 2010 04:11:07 -0800 (PST)
simn_stv  wrote:
> > All of the above (and much more complexity not even discussed here) was
> > handled by Python code and database manipulation.  There were a few
> > bumps along the way but overall it worked fine.  If we were using C or
> > even assembler we would not have sped up anything and the solution we
> > came up with would have been horrendous to code.  As it was I and my
> > chief programmer locked ourselves in the boardroom and had a working
> > solution before the day was out.
> 
> sure it wouldnt have sped it up a bit, even a bit?; probably the
> development and maintenance time would be a nightmare but it should
> speed the app up a bit...

What do you mean by "even a bit?"  The bulk of the time is in sending
bits on the wire.  Computer time was always negligible in this
situation.  Yes, I can write all of my applications in assembler to get
a 0.01% increase in speed but who cares?

If you have decent algorithms in place then 99% of the time I/O will be
your bottleneck and if it isn't then you have a compute heavy problem
that assembler isn't going to fix.

And even if I get a 100% increase in speed, I still lose.  Computer
time is cheaper than programmer time by so many orders of magnitude
that it isn't even worh factoring in the speedup.

-- 
D'Arcy J.M. Cain  |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: taking python enterprise level?...

[simn_stv]

On Feb 26, 10:19 am, "Diez B. Roggisch"  wrote:
> Am 26.02.10 05:01, schrieb D'Arcy J.M. Cain:
>
>
>
> > On Fri, 26 Feb 2010 01:12:00 +0100
> > "Diez B. Roggisch"  wrote:
> >>> That better way turned out to asynchronous update transactions.  All we
> >>> did was keep feeding updates to the remote site and forget about ACKS.
> >>> We then had a second process which handled ACKS and tracked which
> >>> packets had been properly transferred.  The system had IDs on each
> >>> update and retries happened if ACKS didn't happen soon enough.
> >>> Naturally we ignored ACKS that we had already processed.
>
> >> sounds like using UDP to me, of course with a protocol on top (namely
> >> the one you implemented).
>
> >> Any reason you sticked to TCP instead?
>
> > TCP does a great job of delivering a stream of data in order and
> > handling the retries.  The app really was connection oriented and we
> > saw no reason to emulate that over an unconnected protocol.  There were
> > other wheels to reinvent that were more important.
>
> So when you talk about ACKs, you don't mean these on the TCP-level
> (darn, whatever iso-level that is...), but on some higher level?
>
> Diez

i think its on the TCP that he's referring to or is it?...
if it is, that means he's doing some 'mean' network level scripting,
impressive...but i never thought python could go that deep in network
programming!...
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: taking python enterprise level?...

[D'Arcy J.M. Cain]

On Mon, 1 Mar 2010 06:42:28 -0800 (PST)
simn_stv  wrote:
> On Feb 26, 10:19 am, "Diez B. Roggisch"  wrote:
> > So when you talk about ACKs, you don't mean these on the TCP-level
> > (darn, whatever iso-level that is...), but on some higher level?
> 
> i think its on the TCP that he's referring to or is it?...

No, I mean in our own application layer.

> if it is, that means he's doing some 'mean' network level scripting,
> impressive...but i never thought python could go that deep in network
> programming!...

What I meant was that we just keep sending packets which TCP/IP keeps
in order for us by reassembling out-of-order and retransmitted
packets.  Asynchronously we sent back to our own application an ACK
that our app level packet was finally received.  It's a sliding window
protocol.  http://en.wikipedia.org/wiki/Sliding_Window_Protocol

-- 
D'Arcy J.M. Cain  |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Permission Problem

[Victor Subervi]

Never mind. I figured out my error.
beno

On Mon, Mar 1, 2010 at 10:02 AM, Victor Subervi wrote:

> Hi;
> I encountered and solved this problem before with the help of the list, but
> it's back, and I've reviewed and done everything I was shown to do last
> time, so I'm lost. Here's the script:
>
> #!/usr/bin/python
>
> import cgitb; cgitb.enable()
> import cgi
> import sys,os
> sys.path.append(os.getcwd())
> from login import login
> import MySQLdb
> import re, string
> import fpformat
>
> form = cgi.FieldStorage()
> width = form.getfirst('width')
> lines = '''
> #!/usr/bin/python
>
> return %s''' % width
> f = 'width.py'
> try:
>   os.remove(f)
> except OSError:
>   pass
> f = open(f, 'w')
> f.writelines(lines)
> f.close()
>
> Simple enough. Here's the permissions:
>
> drwxrwxrwx 31 root root   4096 Feb 23 04:57 ..
> -rwxrwxrwx  1 root root390 Mar  1 05:52 preload.py
>
> All loaded up deliberately to try and get it to work. Here's the error:
>
>  /var/www/html/globalsolutionsgroup.vi/preload.py
>21 except OSError:
>22   pass
>23 f = open(f, 'w')
>24 f.writelines(lines)
>25 f.close()
> f = 'width.py', builtin open = 
> IOError: [Errno 13] Permission denied: 'width.py'
>   args = (13, 'Permission denied')
>   errno = 13
>   filename = 'width.py'
>   strerror = 'Permission denied'
>
> What'd I do wrong?
> TIA,
> beno
>
> --
> The Logos has come to bear
> http://logos.13gems.com/
>



-- 
The Logos has come to bear
http://logos.13gems.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Class attributes / methods lost?

[Jean-Michel Pichavant]

Gabor Urban wrote:

Hi guys,

I am building a nested data structure with the following compontens:

<>

class Item:
def __init__(self, pId, pChange, pComment):
self.ID = pId
self.Delta = pChange
self.Comment = pComment

def PrintItem(self):
str = '%s,%s,%s'%(self.ID,self.Delta,self.comment)
return str

class Package:
def __init__(self, pSerial, pDate, pOwner, pSchema):
self.serial = pSerial
self.date = pDate
self.owner = pOwner
self.schema = pSchema
self.items = []

def insertItem(self, pItem):
self.items.append(pItem)

def printPackage(self):
lines = []
str = '%s,%s,%s,%s'%(self.serial,self.date,self.owner,self.schema)
number = self.items.length
for idx in xrange(number):
line = ''
istr = self.items[idx].PrintItem()
line = str + ',' + istr
lines.append(line)
return lines

<>

The above structure is processed with next code:

<>

size = len(packages)
package = None
for index in xrange(size):
logger.info('PrettyPrinting package id=%d',index)
oplines = []
oplines = packages[index].printPackage()
for i in xrange(oplines.length):
data.append(oplines[i])
<>

I've got the next error message:
' Traceback (most recent call last):
  File "XmlHistory_orig.py", line 203, in ?
oplines = packages[index].printPackage()
TypeError: unbound method printPackage() must be called with Package
instance as first argument (got nothing instead) '

I did give a try to access the fields directly

<>
packages = []
data = []

size = len(packages)
for index in xrange(size):
str = 
'%s,%s,%s,%s'%(packages[index].serial,packages[index].date,packages[index].owner,packages[index].schema)
itemnum = len(packages[index].items)
oplines = []
for itemIndx in xrange(itemnum):
element =
'%s,%s,%s'%(packages[index].items[itemIdx].ID,packages[index].items[itemIdx].Delta,packages[index].items[itemIdx].comment)
oplines.append(str + ','+elemt)

<>

Error:

Traceback (most recent call last):
  File "XmlHistory.py", line 204, in ?
str = 
'%s,%s,%s,%s'%(packages[index].serial,packages[index].date,packages[index].owner,packages[index].schema)
AttributeError: class Package has no attribute 'serial'

The strange in this issue for me, that I do not see why are the class
methods and fields lost.

Any idea is wellcome.

Gabor
  

Ok here are some suggestions :

1/ do not name a method PrintItem if the method does not print anything 
(it does not)

2/ use the __str__ method to return a nice representation of your objects
3/ use pythonic iteration controls
4/ be consistant with your naming convention, your Item's attributes 
start with an Uppercase letter, Package's attributes with a lowercase 
one. (I suggest the lowercase)



class Item(object):
   def __init__(self, pId, pChange, pComment):
   self.id = pId
   self.delta = pChange
   self.comment = pComment

   def __str__(self):
   return self.__class__.__name__ + ':' + str(self.__dict__)

class Package(object):
   def __init__(self, pSerial, pDate, pOwner, pSchema):
   self.serial = pSerial
   self.date = pDate
   self.owner = pOwner
   self.schema = pSchema
   self.items = []

   def insertItem(self, pItem):
   self.items.append(pItem)

   def __str__(self):
   _dict = self.__dict__.copy()
   _dict['items'] = [str(item) for item in self.items]
   return self.__class__.__name__ + ':' + str(_dict)

i1 = Item('a', 'b', 'c')
i2 = Item('foo', 'bar', 'baz')
p = Package(1,2,3,4)
p.insertItem(i1)
p.insertItem(i2)
packages = [p]

for package in packages:
   print package

>>> Package:{'date': 2, 'owner': 3, 'serial': 1, 'schema': 4, 'items': 
["Item:{'comment': 'c', 'id': 'a', 'delta': 'b'}", "Item:{'comment': 
'baz', 'id': 'foo', 'delta': 'bar'}"]}


Regarding the error you get, it seems you've stored the class itself, 
instead instances.
The error should be in the way you've built the package list, but you 
did not provide the code.


JM

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

Re: Docstrings considered too complicated

[MRAB]

Jean-Michel Pichavant wrote:

MRAB wrote:

Gregory Ewing wrote:

Mel wrote:

You could think of it as a not bad use of the design principle 
"Clear The Simple Stuff Out Of The Way First".  Destinations are 
commonly a lot simpler than sources


That's not usually true in assembly languages, though,
where the source and destination are both very restricted
and often about the same complexity.

That's not to say that right-to-left is the wrong way
to do it in an assembly language, but there are less
misleading words than "move" that could be used.

Z80 assembly language uses "load", which makes things
considerably clearer:

  LD A, B  ; load A with B


Some processors distinguish between "load" (memory to register) and
"store" (register to memory), and the destination and LHS operand of
binary operations might be the same register, for example:

CLC ; clear the carry
LDA first ; accumulator := byte at first
ADCA second ; accumulator := accumulator + byte at second + carry
STA result ; byte at third := accumulator

Guys, you sound like people arguing about old school TV show / series 
like star treck :-)

- "He was wearing a blue suit !"
- "Check episode number 29, he appeared with a pink one!"

I'm glad I'm too young to had to code in assembler, or to bear the 
vision of those unlikely space suits from the 70's ;-)



Ah, yes, Star Trek (the original series).

If they transported down to a planet and there was a man in a red shirt
who you'd never seen before, he'd be the one to die! :-)

BTW, the first programming I did was in hexadecimal (C4xx was "LDI xx").
--
http://mail.python.org/mailman/listinfo/python-list

Re: How to end TCP socket data while using readline()?

[Arjun Chennu]

Thanks for the feedback.

Opening a separate file-obj for writing and for reading is just what I've
been trying, but I don't seem to get it to work. I'm new to python and I'm
not sure if I'm missing the intricacy of some command. Please help:

Here is my server snippet:

(conn, addr) = sock1.accept()# connected socket
print 'Client (localhost) port: ', addr[1]

cf = conn.makefile('r',0)# file obj for reading
lf = open('ccs.txt','w')

for linenum, line in enumerate(cf):# iterate over socket
lines
lf.write(line)
#sys.stdout.write(line)
print len(line)

cf.close()

stat = 'wrote %s lines to file.\n' %(linenum+1)
cff = conn.makefile('w',0)   # file obj for writing
cff.writelines(stat)  # cff.write(stat) does not work
either!!
cff.close()

lf.close()
conn.close()
print stat, "DONE!"

And here is the client that I have for it:  (sfp is the local file object i
read from)

for line in sfp.readlines():
cf.write(line)
print len(line)

print 'done sending'
cf.close()   #writing ends here

cff = s.makefile('r',0)   # file obj for writing
for line in cff.readlines():
print line

cff.close()

sfp.close()
s.close()

The execution sends all the lines (and prints out the len(line) ) and then
stays waiting. THen when I manually terminate the client script, the server
script happily types the "DONE!" output.

Where is this protocol hanging up? Help much appreciated, with a small
explanation.

Cheers,
Arjun

On Sat, Feb 27, 2010 at 05:11, Cameron Simpson  wrote:

> On 26Feb2010 10:39, Arjun  wrote:
> | Hi, I have a small script that runs a TCP server. A client connects to
> | this server and transmits a stored file line-by-line, and then waits
> | for a confirmation "done". However, when I run them the first loop
> | never really ends -- as the TCP server keeps expecting more data. I am
> | using a file-like-object, and so somehow I have to communicate to the
> | server that it is the end-of-file.
> |
> | here is some server code
> | 
> | sock1.bind(('', port))
> | print "Listening at port: ", port
> | sock1.listen(1)  # listening socket
> | (conn, addr) = sock1.accept()# connected socket
> | print 'Client (localhost) port: ', addr[1]
> |
> | cf = conn.makefile('r',0)# file like obj for socket
> [...]
> | print 'close'
> | cf.flush()
> | cf.close()
> | sfp.close()
> [...]
>
> Too many files. It's not that hard! Or shouldn't be.
>
> | So what I am wondering is:
> |
> | 1. Using a file-like object means that the socket becomes uni-
> | directional, until the mode of the file object is changed from 'r' to
> | 'w' (or vice versa). This seems inefficient, and rather unPythonesque.
> | Can somebody tell me if there is a more elegant way of receiving all
> | the lines from the client, and then sending a "done" message to the
> | client?
>
> Get the socket. It is a file descriptor (or in may be a python "socket"
> object with a file descriptor inside).
>
> Open _two_ "file" objects on it using
>  from_file = os.fdopen(fd_of_socket, "r")
>  to_file = os.fdopen(fd_of_socket, "w").
>
> Use the same:
>  print >>to_file, 'close'
>  to_file.flush()
> method as you're using already.
> Read from to_file as needed.
>
> The same scheme should work in both server and client:
>
> Don't look for EOF, watch the input line flow.
>
> You might need to use readline() instead of the file-by-line iteration
> stuff,
> which I seem to recall has some sort of problem handing out the "latest"
> line.
>
> Cheers,
> --
> Cameron Simpson  DoD#743
> http://www.cskk.ezoshosting.com/cs/
>
> It's better, when you're riding with someone you don't know so well, to
> stick
> to the inside line - it's easier to avoid the bits...
>- Barry Sheene
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to end TCP socket data while using readline()?

[Arjun Chennu]

It DOES seem like only when the connection socket is closed via conn.close()
that the data is flushed and the 'waiting' ends. So with the earlier
suggestion that I open one file-obj for reading and one for writing, I still
cannot acheive two-way communication because I need to close the connection
for it to actually occur completely!

My client waits after the "done sending" line indefinitely. Weird.

A

On Mon, Mar 1, 2010 at 16:35, Arjun Chennu  wrote:

> Thanks for the feedback.
>
> Opening a separate file-obj for writing and for reading is just what I've
> been trying, but I don't seem to get it to work. I'm new to python and I'm
> not sure if I'm missing the intricacy of some command. Please help:
>
> Here is my server snippet:
>
>
> (conn, addr) = sock1.accept()# connected socket
> print 'Client (localhost) port: ', addr[1]
>
> cf = conn.makefile('r',0)# file obj for reading
>
> lf = open('ccs.txt','w')
>
> for linenum, line in enumerate(cf):# iterate over socket
> lines
> lf.write(line)
> #sys.stdout.write(line)
> print len(line)
>
> cf.close()
>
> stat = 'wrote %s lines to file.\n' %(linenum+1)
> cff = conn.makefile('w',0)   # file obj for writing
> cff.writelines(stat)  # cff.write(stat) does not work
> either!!
> cff.close()
>
> lf.close()
> conn.close()
> print stat, "DONE!"
>
> And here is the client that I have for it:  (sfp is the local file object i
> read from)
>
>
> for line in sfp.readlines():
> cf.write(line)
> print len(line)
>
> print 'done sending'
> cf.close()   #writing ends here
>
> cff = s.makefile('r',0)   # file obj for writing
> for line in cff.readlines():
> print line
>
> cff.close()
>
> sfp.close()
> s.close()
>
> The execution sends all the lines (and prints out the len(line) ) and then
> stays waiting. THen when I manually terminate the client script, the server
> script happily types the "DONE!" output.
>
> Where is this protocol hanging up? Help much appreciated, with a small
> explanation.
>
> Cheers,
> Arjun
>
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Draft PEP on RSON configuration file format

[Patrick Maupin]

On Feb 28, 9:18 pm, Steven D'Aprano > Wait a minute... if JSON is too
hard to edit, and RSON is a *superset* of
> JSON, that means by definition every JSON file is also a valid RSON file.
> Since JSON is too hard to manually edit, so is RSON.

Well, Python is essentially a superset of JSON, with string escape
handling being ever so slightly different, and using True instead of
true, False instead of false, and None instead of null.  YMMV, but I
find it possible, even probable, to write Python that is far easier to
edit than JSON, and in fact, I have used Python for configuration
files that are only to be edited by programmers or other technical
types.

> Come back when you actually have MANY users other than yourself using
> this is real-world projects. Until then, it is too early to even consider
> adding it the std library. Python comes with batteries included, but not
> experimental batteries that aren't even built yet, let alone proven that
> they work.

I know that it is too early to be included in the library.  But there
is a chicken-and-egg problem.  PEP 1 says you should circulate a
design for discussion before writing code...

I fully expect this sort of negative feedback, fully expect that it
will be years (if ever) before the code makes it into the standard
library, and yet I offer the design for your perusal, just on the slim
chance that I might get a few constructive criticisms on the actual
design to go along with all the silly strawmen reductio ad absurdum
arguments by people who aren't even going to bother to read the thing.

Best regards,
Pat
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: loop through each line in a text file

[qtrimble]

On Feb 26, 6:19 pm, ru...@yahoo.com wrote:
> On Feb 26, 2:21 pm, qtrimble  wrote:
>
>
>
> > On Feb 26, 4:14 pm, OdarR  wrote:
> > 
> > > > below is just a sample.  There are well over 500,000 lines that need
> > > > processed.
>
> > > > wer1999001
> > > >       31.2234      82.2367
> > > >       37.9535      82.3456
> > > > wer1999002
> > > >       31.2234      82.2367
> > > >       37.9535      82.3456
>
> > > did you try something as a working basis ?
>
> > > Olivier
>
> > Yes but it's very simple -
>
> > fileIN = open(r"C:\testing.txt", "r")
>
> > for line in fileIN:
> >     year = line[3:7]
> >     day = line[7:10]
> >     print year, day
>
> > This is good since i can get the year and day of year into a variable
> > but I haven't gotten any further.
>
> How about something like (untested):
>
>   for line in fileIN:
>        if line.startswith ("wer"):
>            year = line[3:7]
>            day = line[7:10]
>         else:
>            print "%s-%s %s" % (year, day, line.strip())
>
> You can adjust the details as needed...

Thanks to all of you for your suggestions.

This is what I have now.  It may not be the most efficient or well
written script but it works!  Thanks again!

fileIN = open(r"C:\z_paul\ims1999.txt", "r")

for line in fileIN:
if line.startswith("ims"):
year = line[3:7]
day = line[7:10]
newfile = file(r"C:\z_paul\output\ims" + year + day + ".txt",
"wt")
newfile.write("YEAR,DOY,Y_COORD,X_COORD,TYPE\n")
else:
temp = line.replace('  ',',')
temp2 = temp.replace(', ',',')
newfile.write(year + "," + day + temp2)
newfile.close()
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Docstrings considered too complicated

[Lie Ryan]

On 03/02/10 00:09, Andreas Waldenburger wrote:
> On Mon, 1 Mar 2010 05:01:49 -0800 (PST) alex23 
> wrote:
> 
>> Andreas Waldenburger  wrote:
>>> But as I said: a) I am (we are) not in a position to impose this (We
>>> don't work with the code, we just run the software).
>>
>> I personally believe that the end users have _every_ right to impose
>> quality requirements on  code used within their business...although I
>> may not bring this up in front of them at meetings :)
> 
> Huh? That's like demanding a certain type of truck or vehicle
> maintenance plan from a trucking company. Sure, you *could* do it, but
> that effectively only limits your options. I think there should be a
> clear separation of concerns here.

If my truck contains food items that spoils quickly, I would want to
make sure that the trucking company takes good care of their
refrigeration system and that the truck have as little chance as
possible for breakdown due to poor maintenance.
-- 
http://mail.python.org/mailman/listinfo/python-list

AOP decorator?

[gentlestone]

Hi,

suppose my source code looks like:

  import aspect_xy
  class Basic(object, aspect_xy.Basic):
pass # basic attributes and methods ...

and the source code of aspect_xy.py is:

  class Basic(object):
pass  # aspect extra attributes and methods ...

how can I write this with decorators? I want something like:
---
  import aspect_xy
  @aspect_xy # extra attributes and methods ...
  class Basic(object):
pass # basic attributes and methods ...
--
I want to write class decorator function, which:
1. Takes the basic class as parameter
2. Find the same class name in aspect_xy.py
3. Inherit the found aspect class
Is it possible?






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

Re: Draft PEP on RSON configuration file format

[Patrick Maupin]

On Mar 1, 12:39 am, John Nagle  wrote:
> Patrick Maupin wrote:
> > All:
>
> > Finding .ini configuration files too limiting, JSON and XML to hard to
> > manually edit, and YAML too complex to parse quickly, I have started
> > work on a new configuration file parser.
>
>     You're not supposed to edit those formats manually.
>
>                                         John Nagle

Opinions on that will vary, and as the saying goes, "everybody is
entitled to his own opinions, but not his own facts."

I submit as fact that there are many initialization files in each of
these formats, and I would be willing to place a wager that the
majority of the people on this list have used a text editor to modify
at least one file in this category at least once.

IOW, in my opinion (and it is only an opinion, not a fact), you are
actually helping to make the case that a better format is needed.

Regards,
Pat
-- 
http://mail.python.org/mailman/listinfo/python-list

Looking for an Application

[Greg Lindstrom]

A few months ago there was a post dealing with an application that would 
power scripts based on graphical snippets of the screen.  Essentially, 
the script would "look" for a match with what you pasted into it.  I 
don't recall the name of the application, but would like to try it.  
Does anyone remember what it is?


Thanks,
--greg


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

Re: Looking for an Application

[Shashwat Anand]

project sikuli : http://groups.csail.mit.edu/uid/sikuli/

On Mon, Mar 1, 2010 at 8:49 PM, Greg Lindstrom <
greg.lindst...@novasyshealth.com> wrote:

> A few months ago there was a post dealing with an application that would
> power scripts based on graphical snippets of the screen.  Essentially, the
> script would "look" for a match with what you pasted into it.  I don't
> recall the name of the application, but would like to try it.  Does anyone
> remember what it is?
>
> Thanks,
> --greg
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: DreamPie - The Python shell you've always dreamed about!

[Noam Yorav-Raphael]

This is most probably a bug discovered in DreamPie 1.0 (See
https://bugs.launchpad.net/dreampie/+bug/525652 )

Can you try to download DreamPie 1.0.1, and if it still happens,
report a bug?

Thanks!
Noam
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: DreamPie - The Python shell you've always dreamed about!

[Noam Yorav-Raphael]

Can you try DreamPie 1.0.1 and say if it still happens?

There's a bug report system at launchpad.net/dreampie.

Thanks,
Noam
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Draft PEP on RSON configuration file format

[Robert Kern]

On 2010-03-01 10:08 , Patrick Maupin wrote:

On Feb 28, 9:18 pm, Steven D'Aprano



Come back when you actually have MANY users other than yourself using
this is real-world projects. Until then, it is too early to even consider
adding it the std library. Python comes with batteries included, but not
experimental batteries that aren't even built yet, let alone proven that
they work.


I know that it is too early to be included in the library.  But there
is a chicken-and-egg problem.  PEP 1 says you should circulate a
design for discussion before writing code...


Ignore it. That comment really doesn't apply to this case. That's for things 
that only make sense in the language or standard library, like context managers. 
For libraries like this, Steven's summary is correct. It needs to have a useful 
life as a third party package for a few years before you should propose it for 
inclusion into the standard library. By all means, distribute a design document 
for comment before you implement things; it's a reasonable practice. But don't 
bother with a PEP yet.


--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

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

Re: Looking for an Application

[Arnaud Delobelle]

Greg Lindstrom  writes:

> A few months ago there was a post dealing with an application that
> would power scripts based on graphical snippets of the screen.
> Essentially, the script would "look" for a match with what you pasted
> into it.  I don't recall the name of the application, but would like
> to try it.  Does anyone remember what it is?
>
> Thanks,
> --greg

Project SIKULI?

http://groups.csail.mit.edu/uid/sikuli/

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

Re: Sample code usable Tkinter listbox

[rantingrick]

On Mar 1, 6:19 am, "Alf P. Steinbach"  wrote:

> >         kw.setdefault('activestyle', 'none')
>
> Hm, let me steal this line... Thanks!

Yes! the default activestyle is quite annoying!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Docstrings considered too complicated

[Andreas Waldenburger]

On Tue, 02 Mar 2010 03:18:30 +1100 Lie Ryan  wrote:

> On 03/02/10 00:09, Andreas Waldenburger wrote:
> > On Mon, 1 Mar 2010 05:01:49 -0800 (PST) alex23 
> > wrote:
> > 
> >> Andreas Waldenburger  wrote:
> >>> But as I said: a) I am (we are) not in a position to impose this
> >>> (We don't work with the code, we just run the software).
> >>
> >> I personally believe that the end users have _every_ right to
> >> impose quality requirements on  code used within their
> >> business...although I may not bring this up in front of them at
> >> meetings :)
> > 
> > Huh? That's like demanding a certain type of truck or vehicle
> > maintenance plan from a trucking company. Sure, you *could* do it,
> > but that effectively only limits your options. I think there should
> > be a clear separation of concerns here.
> 
> If my truck contains food items that spoils quickly, I would want to
> make sure that the trucking company takes good care of their
> refrigeration system and that the truck have as little chance as
> possible for breakdown due to poor maintenance.

My point was that it should not be any of your concern *how* they do
it, only *that* they do it.

Back in the software world: Those guys write code that works. It does
what it's supposed to do. Why should we care where they put their
comments?

-- 
INVALID? DE!

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

Is there a better way to do this?

[Matt Mitchell]

Hi,

I wrote a python script that uses pysvn to export projects from an svn
repo I have.  The repo has hundreds of projects in it with a directory
structure that is pretty uniform however it's not exactly uniform
because of the capitalization.  I.e.:
\root
  \project English
  \Stuff
  \Stuff 2
  \Project Spanish
  \Stuff 3 
  \Stuff 4

My svn repo is case sensitive so if I try to get \root\project
Spanish\Stuff 3 I get an error.  Fixing the capitalization is not an
option for me.  My initial idea was to make a list of all the different
ways "project" has been capitalized in my repo and try each one.  The
code looks like this:

import pysvn

def getstuff(stuffiwant, languageiwantitin):
projects = ("project %s/", "Project %s/", "pRojects %s/")
c = pysvn.Client()
for p in projects:
exportme = p % languageiwantitin
exportme = "http://localhost/"; + exportme + stuffiwant
try:
c.export(exportme, "C:\\temp\\")
break
except pysvn.ClientError:
print "Not the right capitalization."
# do the rest of the stuff I need to do.

This works, but to me it seems like there has to be a better way of
doing it. Any feedback or suggestions would be appreciated. 

Thanks,
Matt
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Draft PEP on RSON configuration file format

[Patrick Maupin]

On Mar 1, 11:13 am, Robert Kern  wrote:
> Ignore it. That comment really doesn't apply to this case. That's for things
> that only make sense in the language or standard library, like context 
> managers.
> For libraries like this, Steven's summary is correct. It needs to have a 
> useful
> life as a third party package for a few years before you should propose it for
> inclusion into the standard library. By all means, distribute a design 
> document
> for comment before you implement things; it's a reasonable practice. But don't
> bother with a PEP yet.

So, I went and re-read PEP 1, and in the fine print it directs me to
PEP 2.  Mea culpa -- I though I understood the PEP.

Nonetheless, the fact that I created what I call a "PEP draft" seems
to have had more read into it than I meant.  I will bear this in mind
when I start future projects.  I have a couple of projects, and
contribute to another, which in no way should wind up in the standard
library.  But I find the lack of a good, up-to-date, configuration
reader in the library to be an issue, which is why I had the temerity
to try to start a discussion on what a good standard configuration
file reader should be.

Yes, I would like to create something compelling enough to go into the
standard library. No, I don't expect it to wind up there for a very
long time, if ever.  BUT, at the same time, following the PEP format
is very valuable for my project.  It forces me to think more deeply
about the problem I am solving and it forces me to write down some
documentation.  Really, it's no more burdensome than any other similar
useful template.

Or, to put it another way, it is my goal (which I may or may not be
smart enough to reach) to write a module that anybody would want to
use; that is good enough to put into the standard library.  Whether
this happens or not, one useful tool to help the module down that path
(and produce a better module for me and other users even if it never
becomes part of the standard library) is to think about what it takes
to get into the standard library.  Part of this involves writing the
PEP.  Writing a PEP is a good exercise; the format itself helps me to
focus on important issues.

So I was writing the contents of the PEP anyway, just for me.  The
real question, then, is when to release the PEP (vs. the code).  I've
already got some coding done, but it is not yet good enough to share,
and if there is anybody else out there grappling with the same issues
at this time, I would prefer not to go into production with it until
they have had a chance to look over the design and offer insights and
criticisms.

Best regards,
Pat
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Docstrings considered too complicated

[Jean-Michel Pichavant]

Andreas Waldenburger wrote:

On Tue, 02 Mar 2010 03:18:30 +1100 Lie Ryan  wrote:

  

On 03/02/10 00:09, Andreas Waldenburger wrote:


On Mon, 1 Mar 2010 05:01:49 -0800 (PST) alex23 
wrote:

  

Andreas Waldenburger  wrote:


But as I said: a) I am (we are) not in a position to impose this
(We don't work with the code, we just run the software).
  

I personally believe that the end users have _every_ right to
impose quality requirements on  code used within their
business...although I may not bring this up in front of them at
meetings :)


Huh? That's like demanding a certain type of truck or vehicle
maintenance plan from a trucking company. Sure, you *could* do it,
but that effectively only limits your options. I think there should
be a clear separation of concerns here.
  

If my truck contains food items that spoils quickly, I would want to
make sure that the trucking company takes good care of their
refrigeration system and that the truck have as little chance as
possible for breakdown due to poor maintenance.



My point was that it should not be any of your concern *how* they do
it, only *that* they do it.

Back in the software world: Those guys write code that works. It does
what it's supposed to do. Why should we care where they put their
comments?

  
If you've bought the code and want to maintain it, you'd better make 
sure it's possible.
By the way, the ISO 9001 standard ask for your out sourced processing to 
be compliant with your QA objectives, so if you care about your code, 
then you should care for the code you buy.


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

Re: Docstrings considered too complicated

[Robert Kern]

On 2010-03-01 11:22 , Andreas Waldenburger wrote:


Back in the software world: Those guys write code that works. It does
what it's supposed to do. Why should we care where they put their
comments?


Software usually needs to be maintained and extended over the course of its 
lifetime. The original team that wrote it may not be available in the future.


Furthermore, docstrings are not comments. They become part of the function 
object and can be introspected at runtime. This is a very important tool when 
working with code at the interactive prompt and for the collection of API 
documentation. Comments are less useful than docstrings; the OP's complaint was 
that his programmers were putting the function documentation in other places 
than docstrings, rendering them less useful than they could have been.


--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

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

Re: Is there a better way to do this?

[Richard Brodie]

"Matt Mitchell"  wrote in message 
news:mailman.65.1267464765.23598.python-l...@python.org...
> My initial idea was to make a list of all the different
> ways "project" has been capitalized in my repo and try each one.  The
> code looks like this:

I would use pysvn.Client.list to get a list of files at whatever directory level
you require. Then you can do a case insensitive compare or whatever else.


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

Re: Verifying My Troublesome Linkage Claim between Python and Win7

[W. eWatson]

On 2/23/2010 6:04 PM, Aahz wrote:

In article,
W. eWatson  wrote:


My claim is that if one creates a program in a folder that reads a file
in the folder it and then copies it to another folder, it will read  the
data file in the first folder, and not a changed file in the new folder.
I'd appreciate it if some w7 users could try this, and let me know what
they find.

My experience is that if one checks the properties of the copied file,
it will point to the original py file and execute it and not the copy.


I've no time to verify your specific claim and have no readily available
proof for mine, but I've seen similar issues on Win7.  AFAIK, this has
nothing to do with Python.
I've been away for several days and have no idea if anyone above figured 
this out. Likely not,since your post is at the end.


Interesting about 'similar'. I'm pretty much done exploring every nook 
and cranny on this problem. It can be worked around. I will say that if 
I look at the properties of the copied file, it shows a shortcut tab 
that leads back to the original file. I have no recollection of making a 
shortcut, and always use Copy and Paste. Further, if I do create 
shortcut in W7, it adds "-shortcut to the file suffix. I do not ever 
recall seeing that anywhere. I just tried it in XP, and it puts it in 
front of the name.

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

[newbie] - python list into a sql query

[João]

Hi.

Can someone guide me into getting this to work? It's just really
querying a DB of an Autodiscovery tool to have a bunch of updated dns
files.
(Thought I'm still building the first script steps) I was able to
successfully query the DB against a single groupid, but am failing in
passing a list of integers into the sql query.

I'm failing miserably in,

sql = '''SELECT ip, host, dns FROM zabbix_tst_db.hosts WHERE hostid IN
(
select hostid from hosts_groups WHERE groupid IN (' +
','.join(map(str, %s)) + ')''' % grp_range


with
_mysql_exceptions.ProgrammingError: (1064, "You have an error in
your SQL syntax; check the manual that corresponds to your MySQL
server version for the right syntax to use near '' at line 1")



I'll gladly accept any other code change suggestion


#!/usr/bin/env python

import MySQLdb
import sys, os
import code

builder_path = '/opt/scripts/dns_builder'
grp_range = range(10,15)

try:
db = MySQLdb.connect(host="localhost",
   user="tst",passwd="tst",db="tst_db" )
except MySQLdb.Error, e:
print "Error %d: %s" % (e.args[0], e.args[1])

cursor = db.cursor()

sql = '''SELECT ip, host, dns FROM zabbix_tst_db.hosts WHERE
hostid IN (
select hostid from hosts_groups WHERE groupid IN (' +
','.join(map(str, %s)) + ')''' % grp_range

cursor.execute(sql)

f = open('%s/dns_unknown_list.txt', 'w+') % builder_path
data = cursor.fetchall()

for row in data:
ip = row[0]
host = row[1]
dns = row[2]
if host == dns:
  #tmn
  if ip[0][:10] in ('140.254.30','10.13.74.')
   group1_file = open('%s/group1.zone', 'w') % builder_path
   print >>group1_file, '''$ORIGIN group1

   '''
   print >>group1_file, '%s IN A%s' % (dns, ip)
  elif ip[0][:3] in ('8.128.46.','6.128.101')
   group2_file = open('%s/group2.zone', 'w') % builder_path
   print >>group2_file, '''$ORIGIN group2

   '''
   print >>group2_file, '%s IN A%s' % (dns, ip)
  else:
   print >>f, 'unknown IN A%s' % ip

db.close()
input_file.close()
f.close()
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Draft PEP on RSON configuration file format

[Robert Kern]

On 2010-03-01 11:34 , Patrick Maupin wrote:

On Mar 1, 11:13 am, Robert Kern  wrote:

Ignore it. That comment really doesn't apply to this case. That's for things
that only make sense in the language or standard library, like context managers.
For libraries like this, Steven's summary is correct. It needs to have a useful
life as a third party package for a few years before you should propose it for
inclusion into the standard library. By all means, distribute a design document
for comment before you implement things; it's a reasonable practice. But don't
bother with a PEP yet.


So, I went and re-read PEP 1, and in the fine print it directs me to
PEP 2.  Mea culpa -- I though I understood the PEP.

Nonetheless, the fact that I created what I call a "PEP draft" seems
to have had more read into it than I meant.  I will bear this in mind
when I start future projects.  I have a couple of projects, and
contribute to another, which in no way should wind up in the standard
library.  But I find the lack of a good, up-to-date, configuration
reader in the library to be an issue, which is why I had the temerity
to try to start a discussion on what a good standard configuration
file reader should be.

Yes, I would like to create something compelling enough to go into the
standard library. No, I don't expect it to wind up there for a very
long time, if ever.  BUT, at the same time, following the PEP format
is very valuable for my project.  It forces me to think more deeply
about the problem I am solving and it forces me to write down some
documentation.  Really, it's no more burdensome than any other similar
useful template.


Certainly. The PEP format is a useful one. I've used it myself for some numpy 
design documents. But can you see why people might get confused about your 
intentions when you call it a draft PEP and post it to python-dev? If you stop 
calling it a PEP and stop talking about putting it in the standard library, 
people will stop being distracted by those issues.


--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

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

Re: Variable definition

[Raphael Mayoraz]

John Posner wrote:

On 2/26/2010 6:32 PM, Raphael Mayoraz wrote:

Hello,

I'd like to define variables with some specific name that has a common
prefix.
Something like this:

varDic = {'red': 'a', 'green': 'b', 'blue': 'c'}
for key, value in varDic.iteritems():
'myPrefix' + key = value



No trick, just swap a new key-value pair for each existing pair:

  for key, value in varDic.iteritems():
  varDic[myPrefix + key] = value
  del varDict[key]

Just make sure that *myPrefix* isn't an empty string!

-John

Thanks for your answer.
However, your solution changes the key name in the dictionary.
That's not what I want I need to do. What I want is to define a new
variable which name is define as a string: 'myPrefx' + key. In the example
I give, I would get 3 variables:
myPrefixred = a
myPrefixgreen = b
myPrefixblue = c

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

Re: Draft PEP on RSON configuration file format

[Paul Rubin]

Patrick Maupin  writes:
> it is my goal (which I may or may not be smart enough to reach) to
> write a module that anybody would want to use;

But you are working on a solution in search of a problem.  The really
smart thing to do would be pick something more useful to work on.  We
don't need another configuration language.  I can't even say "yet
another" because there's already a "yet another" called yaml.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Draft PEP on RSON configuration file format

[Daniel Fetchinson]

>> it is my goal (which I may or may not be smart enough to reach) to
>> write a module that anybody would want to use;
>
> But you are working on a solution in search of a problem.  The really
> smart thing to do would be pick something more useful to work on.  We
> don't need another configuration language.  I can't even say "yet
> another" because there's already a "yet another" called yaml.

And in case you are new here let me assure you that Paul is saying
this with his full intention of being helpful to you. I also would
think that working on such a project might be fun and educational for
you but completely useless if you have users other than yourself in
mind. Again, I'm trying to be helpful here, so you can focus on a
project that is both fun/educational for you and also potentially
useful for others. This RSON business is not one of them.

Cheers,
Daniel



-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [newbie] - python list into a sql query

[MRAB]

João wrote:

Hi.

Can someone guide me into getting this to work? It's just really
querying a DB of an Autodiscovery tool to have a bunch of updated dns
files.
(Thought I'm still building the first script steps) I was able to
successfully query the DB against a single groupid, but am failing in
passing a list of integers into the sql query.

I'm failing miserably in,

sql = '''SELECT ip, host, dns FROM zabbix_tst_db.hosts WHERE hostid IN
(
select hostid from hosts_groups WHERE groupid IN (' +
','.join(map(str, %s)) + ')''' % grp_range


with
_mysql_exceptions.ProgrammingError: (1064, "You have an error in
your SQL syntax; check the manual that corresponds to your MySQL
server version for the right syntax to use near '' at line 1")


[snip]
The triple-quoted string starts at:

'''SELECT ...

and ends at:

...)''' % grp_range

which means that the part where you do the .join is _inside_ the string.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Draft PEP on RSON configuration file format

[Patrick Maupin]

On Mar 1, 12:03 pm, Paul Rubin  wrote:

> But you are working on a solution in search of a problem.  The really
> smart thing to do would be pick something more useful to work on.  We
> don't need another configuration language.  I can't even say "yet
> another" because there's already a "yet another" called yaml.

The only "in search of" here is that, instead of working on a point
solution for my particular problem, I am "in search of" a solution
that is a bit more elegant and general, and that might help solve
other people's problems too.  If you are not one of those that has
this sort of problem at this point in time, then feel free to kill-
file this thread.

Thanks,
Pat
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python shell crashing on paste

[Leo]

Thanks for responding Michel. It looks like its an issue with
pyreadline - http://ipython.scipy.org/moin/PyReadline/Intro - causing
the crash. I'm working with the author of it on trying to get the
issue figured out.

It's not related to UAC.

--
--Leo

On Feb 23, 10:41 pm, "Michel Claveau -
MVP" wrote:
> Hi!
>
> Where (directory) are you, when the problem come?
> Have you try with UAC disabled?
>
> @+
> --  
> MCI

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

Re: [newbie] - python list into a sql query

[Rami Chowdhury]

On Monday 01 March 2010 09:54:20 João wrote:
> Hi.
> 
> Can someone guide me into getting this to work? It's just really
> querying a DB of an Autodiscovery tool to have a bunch of updated dns
> files.

I wouldn't be building SQL queries by hand if I could avoid it -- is this just 
a few one-off scripts or a project that could usefully benefit from a database 
abstraction layer (like SQLAlchemy: http://www.sqlalchemy.org)?

> 
> sql = '''SELECT ip, host, dns FROM zabbix_tst_db.hosts WHERE hostid IN
> (
> select hostid from hosts_groups WHERE groupid IN (' +
> ','.join(map(str, %s)) + ')''' % grp_range
> 

I'm not sure what you expect this to evaluate to?

#>>> grp_range = [1, 2, 3] # dummy data
#>>> sql = '''SELECT ip, host, dns FROM zabbix_tst_db.hosts WHERE hostid IN
... (
... SELECT hostid FROM hosts_groups WHERE groupid IN (' + 
... ','.join(map(str, %s)) + ')''' % grp_range
#>>> print sql
SELECT ip, host, dns FROM zabbix_tst_db.hosts WHERE hostid IN
(
SELECT hostid FROM hosts_groups WHERE groupid IN (' + 
','.join(map(str, [1, 2, 3])) + ')

Since the triple-quoted string only ends at the corresponding triple quote, 
you're including some Python code into the string instead of executing it. If 
you really want to splice the elements of grp_range into the query, you should 
do something like:

#>>> sql = 'SELECT ip, host, dns FROM zabbix_tst_db.hosts WHERE hostid IN 
(SELECT hostid FROM hosts_groups WHERE groupid IN (%s))' % ",".join(str(x) for 
x in grp_range)
#>>> sql
'SELECT ip, host, dns FROM zabbix_tst_db.hosts WHERE hostid IN (SELECT hostid 
FROM hosts_groups WHERE groupid IN (1,2,3))'

Although, really, if you can, I'd parameterise the query (http://mysql-
python.sourceforge.net/MySQLdb-1.2.2/public/MySQLdb.cursors.BaseCursor-
class.html#execute) at the very least...

> 
> with
> _mysql_exceptions.ProgrammingError: (1064, "You have an error in
> your SQL syntax; check the manual that corresponds to your MySQL
> server version for the right syntax to use near '' at line 1")
> 
> 
> 
> I'll gladly accept any other code change suggestion
> 
> 
> #!/usr/bin/env python
> 
> import MySQLdb
> import sys, os
> import code
> 
> builder_path = '/opt/scripts/dns_builder'
> grp_range = range(10,15)
> 
> try:
> db = MySQLdb.connect(host="localhost",
>user="tst",passwd="tst",db="tst_db" )
> except MySQLdb.Error, e:
> print "Error %d: %s" % (e.args[0], e.args[1])
> 
> cursor = db.cursor()
> 
> sql = '''SELECT ip, host, dns FROM zabbix_tst_db.hosts WHERE
> hostid IN (
> select hostid from hosts_groups WHERE groupid IN (' +
> ','.join(map(str, %s)) + ')''' % grp_range
> 
> cursor.execute(sql)
> 
> f = open('%s/dns_unknown_list.txt', 'w+') % builder_path
> data = cursor.fetchall()
> 
> for row in data:
> ip = row[0]
> host = row[1]
> dns = row[2]
> if host == dns:
>   #tmn
>   if ip[0][:10] in ('140.254.30','10.13.74.')
>group1_file = open('%s/group1.zone', 'w') % builder_path
>print >>group1_file, '''$ORIGIN group1
> 
>'''
>print >>group1_file, '%s IN A%s' % (dns, ip)
>   elif ip[0][:3] in ('8.128.46.','6.128.101')
>group2_file = open('%s/group2.zone', 'w') % builder_path
>print >>group2_file, '''$ORIGIN group2
> 
>'''
>print >>group2_file, '%s IN A%s' % (dns, ip)
>   else:
>print >>f, 'unknown IN A%s' % ip
> 
> db.close()
> input_file.close()
> f.close()



Rami Chowdhury
"As an online discussion grows longer, the probability of a comparison 
involving Nazis or Hitler approaches one." -- Godwin's Law
408-597-7068 (US) / 07875-841-046 (UK) / 01819-245544 (BD)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Draft PEP on RSON configuration file format

[Patrick Maupin]

>
> Certainly. The PEP format is a useful one. I've used it myself for some numpy
> design documents. But can you see why people might get confused about your
> intentions when you call it a draft PEP and post it to python-dev? If you stop
> calling it a PEP and stop talking about putting it in the standard library,
> people will stop being distracted by those issues.

As I mentioned, I didn't see the fine print in PEP 1 about PEP 2 being
the document for library modules.  As I mentioned, mea culpa.  It is
painfully obvious that some don't like the way I have gone about
describing the project.  They obviously view me announcing this as
premature, or presumptuous, or something, and they have some sort of
visceral reaction to that.

However, I do not believe that any people (other than me) were really
confused in the process.  I made my intentions clear, and some people
reacted badly to that because I didn't follow the process (for which I
apologize again).  But calling it a draft PEP is a distraction
(because of the visceral reaction), but is not really what I would
call confusing.  My intention actually is to try to build something
that is worthy of the standard library, and to eventually try to get
it accepted, because I perceive a hole there, with a lot of point
solutions being done to solve a common problem, and I believe the
pushback is coming from people who fully understood that intention
from my posting.

I will try to say "hey -- here's a hole in the library and a proposal
for how to fix it" more diplomatically and in the correct forum in the
future, but it would be disingenuous for me to disown my goal of
getting a better configparser into the standard library.

Regards,
Pat
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Variable definition

[John Posner]

On 3/1/2010 1:07 PM, Raphael Mayoraz wrote:

John Posner wrote:

On 2/26/2010 6:32 PM, Raphael Mayoraz wrote:

Hello,

I'd like to define variables with some specific name that has a common
prefix.
Something like this:

varDic = {'red': 'a', 'green': 'b', 'blue': 'c'}
for key, value in varDic.iteritems():
'myPrefix' + key = value



No trick, just swap a new key-value pair for each existing pair:

for key, value in varDic.iteritems():
varDic[myPrefix + key] = value
del varDict[key]

Just make sure that *myPrefix* isn't an empty string!

-John

Thanks for your answer.
However, your solution changes the key name in the dictionary.
That's not what I want I need to do. What I want is to define a new
variable which name is define as a string: 'myPrefx' + key. In the example
I give, I would get 3 variables:
myPrefixred = a
myPrefixgreen = b
myPrefixblue = c


Yes, I misinterpreted your request. I believe there's a consensus around 
here that you shouldn't even try to accomplish your goal. Instead of 
creating *myPrefixred* as a (module-)global name or a (function-)local 
name, you should just use the dictionary as-is: *varDict['red']*. Or 
maybe make the names into attributes of a class, as Alex Goretoy 
suggested. [1]


Can you present a convincing argument as to why you really, really need 
to use the name *myPrefixred* ?


-John

[1] http://mail.python.org/pipermail/python-list/2010-February/1237736.html



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

Re: Draft PEP on RSON configuration file format

[Patrick Maupin]

On Mar 1, 12:40 pm, Daniel Fetchinson 
wrote:
> > But you are working on a solution in search of a problem.  The really
> > smart thing to do would be pick something more useful to work on.  We
> > don't need another configuration language.  I can't even say "yet
> > another" because there's already a "yet another" called yaml.
>
> And in case you are new here let me assure you that Paul is saying
> this with his full intention of being helpful to you. I also would
> think that working on such a project might be fun and educational for
> you but completely useless if you have users other than yourself in
> mind. Again, I'm trying to be helpful here, so you can focus on a
> project that is both fun/educational for you and also potentially
> useful for others. This RSON business is not one of them.

OK, but I am a bit unclear on what you and/or Paul are claiming.  It
could be one of a number of things.  For example:

- There is a preexisting file format suitable for my needs, so I
should not invent another one.

- If I invent a file format suitable for my needs, it couldn't
possibly be general enough for anybody else.

- Even if it was general enough for somebody else, there would only be
two of them.

I've been known to waste time (or be accused of wasting time) on
various endeavors, but I like to know exactly *why* it is perceived to
be a waste.

Regards,
Pat
-- 
http://mail.python.org/mailman/listinfo/python-list

Best auto insurance company // Best auto insurance company /// Best auto insurance company ///

[coolboy8]

VISIT http://alturl.com/8xs8
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: AOP decorator?

[Terry Reedy]

On 3/1/2010 11:22 AM, gentlestone wrote:

Hi,

suppose my source code looks like:

   import aspect_xy
   class Basic(object, aspect_xy.Basic):
 pass # basic attributes and methods ...


As a sidenote, this violates my understanding of aspect-oriented 
programming, which is to add aspects that go across several derived 
classes. But...




and the source code of aspect_xy.py is:

   class Basic(object):
 pass  # aspect extra attributes and methods ...

how can I write this with decorators? I want something like:
---
   import aspect_xy
   @aspect_xy # extra attributes and methods ...
   class Basic(object):
 pass # basic attributes and methods ...
--
I want to write class decorator function, which:
1. Takes the basic class as parameter
2. Find the same class name in aspect_xy.py
3. Inherit the found aspect class
Is it possible?


You would have to look at the difference between Basic with and without 
the explicit base class and patch the latter to look like the former. At 
minimum, you would have to fix .__bases__ and .__mro__, but I do not 
know if those are writable. To me, it seems easier to be explicit.


tjr

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

Re: AOP decorator?

[Jon Clements]

On Mar 1, 4:22 pm, gentlestone  wrote:
> Hi,
>
> suppose my source code looks like:
> 
>   import aspect_xy
>   class Basic(object, aspect_xy.Basic):
>     pass # basic attributes and methods ...
> 
> and the source code of aspect_xy.py is:
> 
>   class Basic(object):
>     pass  # aspect extra attributes and methods ...
> 
> how can I write this with decorators? I want something like:
> ---
>   import aspect_xy
>   @aspect_xy # extra attributes and methods ...
>   class Basic(object):
>     pass # basic attributes and methods ...
> --
> I want to write class decorator function, which:
> 1. Takes the basic class as parameter
> 2. Find the same class name in aspect_xy.py
> 3. Inherit the found aspect class
> Is it possible?

Untested and written quickly, so all possible disclaimers apply ;)

class BaseObject(object):
pass

def aspect_xy_dec(base):
def wrapper(cls):
return type(cls.__name__, (base, getattr(aspect_xy, cls.__name__)),
{})
return wrapper

@aspect_xy(BaseObject)
class SomeObject:
pass


Cheers,

Jon.


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

Re: Draft PEP on RSON configuration file format

[Paul Rubin]

Patrick Maupin  writes:
> - There is a preexisting file format suitable for my needs, so I
> should not invent another one.

There are in fact quite a few--json, yaml, .ini, xml, Python literals
(http://code.activestate.com/recipes/364469-safe-eval/), s-expressions,
actual Python code that the application can import, and so forth.

The problem isn't that you're trying to invent a useless file format per
se, but rather that in trying to get other people to learn it and use
it, you're also trying to appropriate a chunk of the user community's
scarce and precious brain cells without good justification.  Newbie
designers are often lured into that and they're unfortunately (i.e. to
the community's detrimtent) often more successful than they really
should be.

Your one complaint about yaml is that it's slow to parse.  Why do you
care about the parsing speed of a config file?  If the existing
implementation is too slow, why not write a faster one instead of
designing yayaml?  Even yaml is excessive in my view.  "Yet another" was
an ok plan when Steve Johnson started the trope by writing Yacc 30 years
ago.  These days, don't do yet another without very convincing reasons
for rejecting what is already there.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Draft PEP on RSON configuration file format

[Patrick Maupin]

On Mar 1, 1:37 pm, Paul Rubin  wrote:
> There are in fact quite a few--json, yaml, .ini, xml, Python literals
> (http://code.activestate.com/recipes/364469-safe-eval/), s-expressions,
> actual Python code that the application can import, and so forth.

Yes, I know about those.

> The problem isn't that you're trying to invent a useless file format per
> se, but rather that in trying to get other people to learn it and use
> it, you're also trying to appropriate a chunk of the user community's
> scarce and precious brain cells without good justification.  Newbie
> designers are often lured into that and they're unfortunately (i.e. to
> the community's detrimtent) often more successful than they really
> should be.

Can't disagree with the statement about newbie designers.  On the flip
side, sometimes things wind up being defacto standards, simply because
nobody could be bothered to write a better one, and they have lots of
little niggling warts that also collectively take up a lot of time and
attention.  There is obviously a good balance somewhere.

> Your one complaint about yaml is that it's slow to parse.  Why do you
> care about the parsing speed of a config file?  If the existing
> implementation is too slow, why not write a faster one instead of
> designing yayaml?  Even yaml is excessive in my view.  "Yet another" was
> an ok plan when Steve Johnson started the trope by writing Yacc 30 years
> ago.  These days, don't do yet another without very convincing reasons
> for rejecting what is already there.

One of my complaints.  If you had read the document you would have
seen others.  I actually have several complaints about YAML, but I
tried to write a cogent summary.

Regards,
Pat
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Draft PEP on RSON configuration file format

[Paul Rubin]

Patrick Maupin  writes:
> One of my complaints.  If you had read the document you would have
> seen others.  I actually have several complaints about YAML, but I
> tried to write a cogent summary.

Yaml sucks, but seems to have gotten some traction regardless.
Therefore the Python principle of "there should be one and only one
obvious way to do it" says: don't try to replace the existing thing if
your new thing is only slightly better.  Just deal with the existing
thing's imperfections or make improvements to it.  If you can make a
really powerful case that your new thing is 1000x better than the old
thing, that's different, but I don't think we're seeing that here.

Also, XML is used for pretty much everything in the Java world.  It
sucks too, but it is highly standardized, it observably gets the job
done, there are tons of structure editors for it, etc.  Frankly
I'd rather have stayed with it than deal with Yaml.

There are too many of these damn formats.  We should ban all but one of
them (I don't much care which one).  And making even more of them is not
the answer.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Docstrings considered too complicated

[Andreas Waldenburger]

On Mon, 01 Mar 2010 11:42:16 -0600 Robert Kern 
wrote:

> On 2010-03-01 11:22 , Andreas Waldenburger wrote:
> 
> > Back in the software world: Those guys write code that works. It
> > does what it's supposed to do. Why should we care where they put
> > their comments?
> 
> Software usually needs to be maintained and extended over the course
> of its lifetime. The original team that wrote it may not be available
> in the future.
> 
> Furthermore, docstrings are not comments. They become part of the
> function object and can be introspected at runtime. This is a very
> important tool when working with code at the interactive prompt and
> for the collection of API documentation. Comments are less useful
> than docstrings; the OP's complaint was that his programmers were
> putting the function documentation in other places than docstrings,
> rendering them less useful than they could have been.
> 

No, the OP complained about those guys being idiots. I should know,
because I posted it.

/W

-- 
INVALID? DE!

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

Re: Docstrings considered too complicated

[Andreas Waldenburger]

On Mon, 01 Mar 2010 18:42:17 +0100 Jean-Michel Pichavant
 wrote:

> Andreas Waldenburger wrote:
> [snip]
> > Back in the software world: Those guys write code that works. It
> > does what it's supposed to do. Why should we care where they put
> > their comments?
> >
> >   
> If you've bought the code and want to maintain it, you'd better make 
> sure it's possible.
> 
Fair enough, but we don't want to maintain it.


> By the way, the ISO 9001 standard ask for your out sourced processing
> to be compliant with your QA objectives, so if you care about your
> code, then you should care for the code you buy.
> 
We did not buy code. If it were written in C or such, we would never
get to see it.

It's not our concern.

/W

-- 
INVALID? DE!

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

Re: Draft PEP on RSON configuration file format

[Patrick Maupin]

On Mar 1, 2:08 pm, Paul Rubin  wrote:

> Yaml sucks, but seems to have gotten some traction regardless.

Yes, that's actually one of the reasons I want to do this.  I've heard
that some of the YAML people want that in the standard library, and
IMHO that would be a huge mistake.

> Therefore the Python principle of "there should be one and only one
> obvious way to do it" says: don't try to replace the existing thing if
> your new thing is only slightly better.

But for my use-case, YAML is irretrievably broken.  Sure, it looks
reasonably nice, but it increases regression runtime unacceptably.
Also, despite their current protestations that Yaml AIN'T markup
language, the syntax still belies its markup roots.  I'm looking for a
configuration language, not a markup language.

> Just deal with the existing thing's imperfections or make improvements to it.

Well, I've looked at the YAML parser and I can assure you that I will
not be contributing to that project.

> If you can make a really powerful case that your new thing is 1000x better 
> than the old thing, that's different, but I don't think we're seeing that 
> here.

Well, there's no way I'm hitting three orders of magnitude, but I
don't think the bar is really that high.  We will see.

> Also, XML is used for pretty much everything in the Java world.  It
> sucks too, but it is highly standardized, it observably gets the job
> done, there are tons of structure editors for it, etc.  Frankly
> I'd rather have stayed with it than deal with Yaml.

XML can certainly be made readable by humans.  It's hard to make it
writeable by (average) humans just using a regular text editor, and
even though there are tons of structure editors, requiring non-
technical people to find one of those and start using it is a non-
starter in many cases.  But I can't strongly disagree with the opinion
that YAML doesn't offer all that much over it.

> There are too many of these damn formats.  We should ban all but one of
> them (I don't much care which one).  And making even more of them is not
> the answer.

Well, I think that XML and YAML both overreach by trying to be all
things to all applications.  So I'm aiming a lot lower than that.  I
just want to make really good configuration files that are easy to
modify in a text editor.

None of the existing formats are suitable.  I may be the only one who
feels that way.  OTOH, if we never invented new things, then I
wouldn't be enjoying restructured text, and I'd be missing out on a
lot there...

Regards,
Pat
-- 
http://mail.python.org/mailman/listinfo/python-list

Class attributes / methods..... full Python script

[Gabor Urban]

Hi guys,

thanks for the ideas. Here you are the code. Not transcoded from Java
for I do not know Java enough..

I am scanning an XML file, and have a large ammount of logging.

Any ideas are wellcome as before

Thnx

Code:>

#-
## Generate CSV from OEP History XML
#-

import sys
import os
from xml.dom.minidom import parse, parseString
import xml.dom
import logging

versionStr = '0.01'

class Item:
def __init__(self, pId, pChange, pComment):
self.ID = pId
self.Delta = pChange
self.Comment = pComment

def PrintItem(self):
str = '%s,%s,%s'%(self.ID,self.Delta,self.comment)
return str

class Package:
def __init__(self, pSerial, pDate, pOwner, pSchema):
self.serial = pSerial
self.date = pDate
self.owner = pOwner
self.schema = pSchema
self.items = []

def insertItem(self, pItem):
self.items.append(pItem)

def printPackage(self):
lines = []
str = '%s,%s,%s,%s'%(self.serial,self.date,self.owner,self.schema)
number = self.items.length
for idx in xrange(number):
line = ''
istr = self.items[idx].PrintItem()
line = str + ',' + istr
lines.append(line)
return lines

def getItem(tracer, pkgItem, itemName):
retval = -1
name = ""
found = 0
str = ""
tracer.info('Function getItem entry, name = %s',itemName)
nItem = pkgItem.getElementsByTagName(itemName).item(0)
for node in pkgItem.childNodes:
if node.nodeType != xml.dom.Node.TEXT_NODE:
tracer.debug('Scanning node name = %s',node.nodeName)
if node.nodeName == itemName:
tracer.debug('Pkg %s found',itemName)
else:
tracer.warning('Pkg %s is not found',itemName)
continue
for entity in node.childNodes:
if entity.nodeType == xml.dom.Node.TEXT_NODE:
retval = entity.nodeValue
tracer.debug("Node value found %s",retval)
found = 1
break
if found == 1:
break
tracer.debug('Function getItem returns %s',retval)
return retval

logger = logging.getLogger('XmlHistory')
handler = logging.FileHandler("Xmlhistory.trc",'a')
## handler = logging.StreamHandler(sys.stderr)
logger.addHandler(handler)
formatter = logging.Formatter("%(name)s %(asctime)s %(filename)s
%(lineno)d %(levelname)s %(message)s")
handler.setFormatter(formatter)
logger.setLevel(2)

fileName = "history.xml"
output = 'history.csv'
logger.info('Xml history generator version %s',versionStr)
logger.info('Starting history generation on file:%s',fileName)

packages = []
data = []

## Start XML processing

dataSource = parse(fileName)
print dataSource.documentElement.tagName
listCsomag = dataSource.getElementsByTagName("csomag")
size = listCsomag.length
logger.debug('Number of packages = %d',size)
for idx in xrange(size):
attrib = ""
package = None
serial = 0
date = ""
owner = ""
schema = ""
flag = False
logger.info('Parsing package id=%d',idx)
attrib = getItem(logger, listCsomag.item(idx),'sorszam')
if attrib <> "NUM" and attrib <> -1:
serial = int(attrib)
flag = True
logger.debug('Package serial set to %d',serial)
else:
logger.debug("Template package found.")
break
attrib = ""
attrib = getItem(logger,listCsomag.item(idx),"datum")
if attrib <> -1:
date = attrib
flag = flag and True
logger.debug('Package date set to %s',date)
attrib = ""
attrib = getItem(logger,listCsomag.item(idx),"ki")
if attrib <> -1:
owner = attrib
flag = flag and True
logger.debug('Package owner set to %s',owner)
attrib = ""
attrib = getItem(logger,listCsomag.item(idx),"sema")
if attrib <> -1:
schema = attrib
flag = flag and True
logger.debug('Package schema set to %s',schema)

if flag <> True:
logger.error('Package id=%d is inconsistent',idx)
break
else:
logger.info('Package id=%d is ok',idx)

package = Package(serial,date,owner,schema)

listItem = listCsomag.item(idx).getElementsByTagName("item")
itemSize = listItem.length
logger.debug('Number of items = %d',itemSize)
for num in xrange(itemSize):
flag = False
value = -1
listId = 0
change = ""
comment = ""
item = None
logger.info('Parsing item id = %d',num)
value = getItem(logger,listItem.item(num),"item_id")
if value <> -1:
listId = int(value)
flag = True
logger.debug('List id set to %d',listId)
value = ""
value = getItem(logger,listItem.item(num),"valtozas")
if value <> -1:
change = value
 

Re: Draft PEP on RSON configuration file format

[Paul Rubin]

Patrick Maupin  writes:
> But for my use-case, YAML is irretrievably broken.  Sure, it looks
> reasonably nice, but it increases regression runtime unacceptably.

How big are the files that you want to parse with it?  Sheesh.

> Well, I've looked at the YAML parser and I can assure you that I will
> not be contributing to that project.

So write a new one that parses the same syntax, but cleaner and faster.

> XML can certainly be made readable by humans.  It's hard to make it
> writeable by (average) humans just using a regular text editor,

I do it all the time; it's a bit dreary but not difficult.  And there is
absolutely no way to get anything done in this field anymore without
dealing with XML from time to time.  So given that we all have some
experience using it, it's sensible to stick with it.

> None of the existing formats are suitable.  I may be the only one who
> feels that way.  OTOH, if we never invented new things, then I
> wouldn't be enjoying restructured text, and I'd be missing out on a
> lot there...

ReST is another abomination that should never have gotten off the
ground.  It is one of the reasons I react so negatively to your
config format proposal.  It just sounds like more of the same.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Method / Functions - What are the differences?

[Bruno Desthuilliers]

Michael Rudolf a écrit :
> Out of curiosity I tried this and it actually worked as expected:
> 
 class T(object):
> x=[]
> foo=x.append
> def f(self):
> return self.x
> 
> 
 t=T()
 t.f()
> []
 T.foo(1)
 t.f()
> [1]

> 
> At first I thought "hehe, always fun to play around with python. Might
> be useful sometimes" - but then It really confused me what I did. I
> mean: f is what we call a method, right? 

Wrong. It's a function. T.f is an unbound method (in python 2.x at
least) and t.f is a bound method.

> But was is foo?

A bound method. Bound to x, of course.

> It is not a
> method and not a classmethod as it accepts no self and no cls.

Yes it does. Else how would t.foo(4) (or T.foo(4)) append 4 to x ?

> Perhaps this all does not matter, 

It does.

> but now I am really confused about the
> terminology. So: what makes a method a method?

The right question is: what makes a function a method !-)

> And of what type?

Answer here:

http://groups.google.com/group/comp.lang.python/tree/browse_frm/thread/bd71264b6022765c/3a77541bf9d6617d#doc_89d608d0854dada0

I really have to put this in the wiki :-/
-- 
http://mail.python.org/mailman/listinfo/python-list

Building Python with Scons

[Gerhard Häring]

I'm setting up a third-party library project (similar to the one in 
Google Chromium) where I use SCons as build tool.


Now I need to integrate Python, too. Has anybody written a Scons script 
for Python 2.x or 3.x, yet?


-- Gerhard

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

Re: Draft PEP on RSON configuration file format

[Philip Semanchuk]

On Mar 1, 2010, at 3:08 PM, Paul Rubin wrote:


Patrick Maupin  writes:

One of my complaints.  If you had read the document you would have
seen others.  I actually have several complaints about YAML, but I
tried to write a cogent summary.


Yaml sucks, but seems to have gotten some traction regardless.
Therefore the Python principle of "there should be one and only one
obvious way to do it" says: don't try to replace the existing thing if
your new thing is only slightly better.  Just deal with the existing
thing's imperfections or make improvements to it.  If you can make a
really powerful case that your new thing is 1000x better than the old
thing, that's different, but I don't think we're seeing that here.

Also, XML is used for pretty much everything in the Java world.  It
sucks too, but it is highly standardized, it observably gets the job
done, there are tons of structure editors for it, etc.  Frankly
I'd rather have stayed with it than deal with Yaml.

There are too many of these damn formats.  We should ban all but one  
of
them (I don't much care which one).  And making even more of them is  
not

the answer.



I dunno, times change, needs change. We must invent new tools, be  
those computer languages or data formats. Otherwise we'd still be  
programming in COBOL and writing fixed-length records to 12 inch  
floppies.*


If Mr. Maupin was a giant corporation trying to shove a proprietary  
format down our collective throats, I might object to RSON. But he's  
not. He appears willing for it live or die on its merits, so I say  
good luck to him. I don't want or need it, but someone else might.


Cheers
Philip


* You had floppies? Bleddy luxury! We wrote our data on wood pulp we'd  
chewed ourselves and dried into paper, using drops of our own blood to  
represent 1s and 0s.


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

Re: Docstrings considered too complicated

[Mark Lawrence]

Andreas Waldenburger wrote:

On Mon, 01 Mar 2010 18:42:17 +0100 Jean-Michel Pichavant
 wrote:


Andreas Waldenburger wrote:
[snip]

Back in the software world: Those guys write code that works. It
does what it's supposed to do. Why should we care where they put
their comments?

  
If you've bought the code and want to maintain it, you'd better make 
sure it's possible.



Fair enough, but we don't want to maintain it.



By the way, the ISO 9001 standard ask for your out sourced processing
to be compliant with your QA objectives, so if you care about your
code, then you should care for the code you buy.


We did not buy code. If it were written in C or such, we would never
get to see it.

It's not our concern.

/W



From your original post.


a company that works with my company writes a lot of of their code in
Python (lucky jerks). I've seen their code and it basically looks like
this:


So what is the relationship between your company and this other company?
When it gets down to pounds, shillings and pence (gosh, I'm old!:) it 
sure as hell could make a tremendous difference in the long term, given 
that usually maintainance costs are astronomical when compared to 
initial development costs.


Regards.

Mark Lawrence.

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

Re: Draft PEP on RSON configuration file format

[Patrick Maupin]

On Mar 1, 2:42 pm, Paul Rubin  wrote:
> Patrick Maupin  writes:
> > But for my use-case, YAML is irretrievably broken.  Sure, it looks
> > reasonably nice, but it increases regression runtime unacceptably.
>
> How big are the files that you want to parse with it?  Sheesh.

Tiny, but over and over.  The rst2pdf testsuite can generate
approximately 160 PDFs, totalling around 2.5 MB, in around 22 seconds
on one of my machines.  But if I replace the JSON parser with a YAML
parser, that goes up to 55 seconds.  Wait, maybe it's because JSON is
optimized in C!  Nope, using JSON but disabling the C scanner only
takes it to 22.3 seconds...

>
> > Well, I've looked at the YAML parser and I can assure you that I will
> > not be contributing to that project.
>
> So write a new one that parses the same syntax, but cleaner and faster.

But there are already several parsers for YAML, and none of them
agree!  The syntax definition is a mess.  The thing's been in
development for 10 years now, and there is no one true way to do it.
Seriously, YAML overreaches for what I want.

> > XML can certainly be made readable by humans.  It's hard to make it
> > writeable by (average) humans just using a regular text editor,
>
> I do it all the time; it's a bit dreary but not difficult.  And there is
> absolutely no way to get anything done in this field anymore without
> dealing with XML from time to time.  So given that we all have some
> experience using it, it's sensible to stick with it.

But people "in this field" are not really my target audience.  Well, I
mean people in this field are the target audience for the library, but
not for the writing of the actual text files.

> ReST is another abomination that should never have gotten off the
> ground.  It is one of the reasons I react so negatively to your
> config format proposal.  It just sounds like more of the same.

Well, that clarifies a lot.  I guess we'll just have to agree to
disagree :-)

Regards,
Pat
-- 
http://mail.python.org/mailman/listinfo/python-list

How to crash CPython 3.1.1 in Windows XP

[Alf P. Steinbach]

How to crash CPython 3.1.1 in Windows XP:

  python -c "import os; os.spawnl( os.P_WAIT, 'blah' )"

I reported this as a bug, http://bugs.python.org/issue8036>

Workaround: it seems that spawnl is happy with an absolute path as second arg, 
followed by a third arg which should be the name of the program (repeated).



Cheers,

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

Re: Draft PEP on RSON configuration file format

[Emile van Sebille]

On 3/1/2010 1:02 PM Philip Semanchuk said...

* You had floppies? Bleddy luxury! We wrote our data on wood pulp we'd
chewed ourselves and dried into paper, using drops of our own blood to
represent 1s and 0s.


You had left-over blood?!!

Emile :)

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

Re: Class attributes / methods..... full Python script

[Peter Otten]

Gabor Urban wrote:

> thanks for the ideas. Here you are the code. Not transcoded from Java
> for I do not know Java enough..
> 
> I am scanning an XML file, and have a large ammount of logging.
> 
> Any ideas are wellcome as before
> 
> Thnx
> 
> Code:>

> packages.append(Package)

Replace Package (the class) with package (an instance).

> for i in xrange(oplines.length):
> data.append(oplines[i])

Python lists don't have a length attribute. You can determine their length 
with len(oplines). To iterate over the items of a list you need not know the 
list's length:

for line in oplines:
data.append(line)

which can be simplified to

data.extend(oplines)

Peter

PS: Rrread the tutorial
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Class attributes / methods..... full Python script

[MRAB]

Gabor Urban wrote:

Hi guys,

thanks for the ideas. Here you are the code. Not transcoded from Java
for I do not know Java enough..

I am scanning an XML file, and have a large ammount of logging.

Any ideas are wellcome as before

Thnx

Code:>

#-
## Generate CSV from OEP History XML
#-

import sys
import os
from xml.dom.minidom import parse, parseString
import xml.dom
import logging

versionStr = '0.01'

class Item:
def __init__(self, pId, pChange, pComment):
self.ID = pId
self.Delta = pChange
self.Comment = pComment

def PrintItem(self):
str = '%s,%s,%s'%(self.ID,self.Delta,self.comment)
return str

class Package:
def __init__(self, pSerial, pDate, pOwner, pSchema):
self.serial = pSerial
self.date = pDate
self.owner = pOwner
self.schema = pSchema
self.items = []

def insertItem(self, pItem):
self.items.append(pItem)

def printPackage(self):
lines = []
str = '%s,%s,%s,%s'%(self.serial,self.date,self.owner,self.schema)
number = self.items.length


If this is meant to get the length of self.items, then it won't work. It
should be:

number = len(self.items)


for idx in xrange(number):
line = ''


What's the purpose of this line? You're not using 'line' before you
assign to it again.


istr = self.items[idx].PrintItem()
line = str + ',' + istr
lines.append(line)
return lines

def getItem(tracer, pkgItem, itemName):
retval = -1
name = ""
found = 0
str = ""
tracer.info('Function getItem entry, name = %s',itemName)
nItem = pkgItem.getElementsByTagName(itemName).item(0)
for node in pkgItem.childNodes:
if node.nodeType != xml.dom.Node.TEXT_NODE:
tracer.debug('Scanning node name = %s',node.nodeName)
if node.nodeName == itemName:
tracer.debug('Pkg %s found',itemName)
else:
tracer.warning('Pkg %s is not found',itemName)
continue
for entity in node.childNodes:
if entity.nodeType == xml.dom.Node.TEXT_NODE:
retval = entity.nodeValue
tracer.debug("Node value found %s",retval)
found = 1
break
if found == 1:
break
tracer.debug('Function getItem returns %s',retval)
return retval

logger = logging.getLogger('XmlHistory')
handler = logging.FileHandler("Xmlhistory.trc",'a')
## handler = logging.StreamHandler(sys.stderr)
logger.addHandler(handler)
formatter = logging.Formatter("%(name)s %(asctime)s %(filename)s
%(lineno)d %(levelname)s %(message)s")
handler.setFormatter(formatter)
logger.setLevel(2)

fileName = "history.xml"
output = 'history.csv'
logger.info('Xml history generator version %s',versionStr)
logger.info('Starting history generation on file:%s',fileName)

packages = []
data = []

## Start XML processing

dataSource = parse(fileName)
print dataSource.documentElement.tagName
listCsomag = dataSource.getElementsByTagName("csomag")
size = listCsomag.length
logger.debug('Number of packages = %d',size)
for idx in xrange(size):
attrib = ""
package = None
serial = 0
date = ""
owner = ""
schema = ""
flag = False
logger.info('Parsing package id=%d',idx)
attrib = getItem(logger, listCsomag.item(idx),'sorszam')
if attrib <> "NUM" and attrib <> -1:
serial = int(attrib)
flag = True
logger.debug('Package serial set to %d',serial)
else:
logger.debug("Template package found.")
break
attrib = ""


What's the purpose of this line? You're not using 'attrib' before you
assign to it again. You're doing this repeatedly in the code.


attrib = getItem(logger,listCsomag.item(idx),"datum")
if attrib <> -1:
date = attrib
flag = flag and True


Whether 'flag' is False or True, this line won't change it. You're also
doing this repeatedly in the code.


logger.debug('Package date set to %s',date)
attrib = ""
attrib = getItem(logger,listCsomag.item(idx),"ki")
if attrib <> -1:
owner = attrib
flag = flag and True
logger.debug('Package owner set to %s',owner)
attrib = ""
attrib = getItem(logger,listCsomag.item(idx),"sema")
if attrib <> -1:
schema = attrib
flag = flag and True
logger.debug('Package schema set to %s',schema)

if flag <> True:


Clearer as:

if not flag:

or even clearer if you picked a better name than 'flag'.


logger.error('Package id=%d is inconsistent',idx)
break
else:
logger.info('Package id=%d is ok',idx)

package = Package(serial,date,owner,schema)

listItem = listCsomag.item(idx).getElementsByTagName("item")
itemSize = listItem.length
logger.d

Re: Docstrings considered too complicated

[Ben Finney]

Andreas Waldenburger  writes:

> On Mon, 01 Mar 2010 18:42:17 +0100 Jean-Michel Pichavant
>  wrote:
>
> > Andreas Waldenburger wrote:
> > [snip]
> > > Back in the software world: Those guys write code that works. It
> > > does what it's supposed to do. Why should we care where they put
> > > their comments?
> > >   
> > If you've bought the code and want to maintain it, you'd better make
> > sure it's possible.
> > 
> Fair enough, but we don't want to maintain it.

Do you want it maintained beyond the span of your agreement with the
current developers? Do you want to have free choice in who will maintain
it over the period that you need it maintained?

I understood “want to maintain it” in Jean-Michel's message to include
the possibility to get someone else to maintain it on your terms.

> It's not our concern.

Then I don't see what that problem is.

-- 
 \ “To save the world requires faith and courage: faith in reason, |
  `\and courage to proclaim what reason shows to be true.” |
_o__)—Bertrand Russell |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Call for Participation: CHR Summer School

[Jon Sneyers]

- Call for Participation -


First International Summer School on CHR:
Programming and Reasoning with Rules and Constraints

August 30 - September 3 2010
Leuven, Belgium

Website:   http://www.cs.kuleuven.be/~dtai/CHR/summerschool


* EARLY REGISTRATION DISCOUNT: When registering (including payment) before *
*   March 31, the registration fee will be reduced by 20 euro! *
*
*
* Additional early registration incentive: *
* The first 7 registrants get a FREE copy of the book  *
* "Constraint Handling Rules - Current Research Topics"*



The aim of the summer school is to familiarize the participants with
state-of-the-art high-level declarative programming with rules and
constraints as well as providing insights into the analysis of programs
based on these concepts. The courses cover a wide range from theory to
practice.

The summer school will be based on the advanced high-level rule-based
formalism and programming language Constraint Handling Rules (CHR)
http://constraint-handling-rules.org/



Intended Audience:

The summer school provides courses at various levels. It is open to
anyone interested. It aims at Phd. students, but also post-docs,
interested researchers and master students as well as interested parties
from industry. Besides a working knowledge of English, there are no
prerequisites. A basic knowledge of logic and Prolog that is usually
covered in undergraduate classes could be helpful.


Lectures and Courses:

The programming language CHR will be introduced by several lecturers
on the first day of the summer school.

- Slim Abdennadher, GUC, Egypt
Analysis of CHR Solvers
- Henning Christiansen, U. Roskilde, Denmark
Abduction and language processing with CHR
- Thom Fruehwirth, University Ulm, Germany
CHR - a common platform for rule-based approaches
- Jon Sneyers, K.U.Leuven, Belgium
Computability and Complexity of CHR
- Peter Van Weert, K.U.Leuven, Belgium
Implementation of CHR Systems

A final evaluation for each course is possible through a final exam or
project as determined by the instructor. The daily schedule admits
laboratory, recitation or working group activities to be organized in
addition to lectures.


Registration:

The registration fee for the School is 300 euro and includes teaching material
with book, as well as accomodation and coffee breaks. Meals are not included.
Attendance is limited to 20 students and will be allocated on a first-come-
first-served basis. Without accommodation the registration fee is reduced to
200 euro.


Location:

Leuven is a lively student town in Belgium with a very high density of
pubs offering hundreds of types of local beers.


Organization:

Thom Fruehwirth, University of Ulm, Germany
Jon Sneyers, K.U. Leuven, Belgium
Peter Van Weert, K.U. Leuven, Belgium


-- 

Looking for an H-912 (container).

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

Re: PyQt4.7 and PyQwt5.2.0

[Gib Bogle]

Gib Bogle wrote:
I installed the latest PyQt (4.7-1), then PyQwt 5.2.0, which was built 
with PyQt4.5.4.  This line


import PyQt4.Qwt5 as Qwt

fails to load the DLL.  Could this be the result of not using PyQt4 4.5.4?


I guess I can answer my own question.  As far as I can determine, PyQwt 5.2.0 
needs PyQt 4.5.4 to work.

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

Re: Variable definition

[Rhodri James]

On Mon, 01 Mar 2010 18:07:17 -, Raphael Mayoraz   
wrote:



Thanks for your answer.
However, your solution changes the key name in the dictionary.
That's not what I want I need to do. What I want is to define a new
variable which name is define as a string: 'myPrefx' + key. In the  
example

I give, I would get 3 variables:
myPrefixred = a
myPrefixgreen = b
myPrefixblue = c


I repeat my previous question: why?  What problem do you think this will  
solve that will not be more easily solved working with the language rather  
than against it?


--
Rhodri James *-* Wildebeeste Herder to the Masses
--
http://mail.python.org/mailman/listinfo/python-list

Re: Draft PEP on RSON configuration file format

[Erik Max Francis]

Daniel Fetchinson wrote:

it is my goal (which I may or may not be smart enough to reach) to
write a module that anybody would want to use;

But you are working on a solution in search of a problem.  The really
smart thing to do would be pick something more useful to work on.  We
don't need another configuration language.  I can't even say "yet
another" because there's already a "yet another" called yaml.


And in case you are new here let me assure you that Paul is saying
this with his full intention of being helpful to you. I also would
think that working on such a project might be fun and educational for
you but completely useless if you have users other than yourself in
mind. Again, I'm trying to be helpful here, so you can focus on a
project that is both fun/educational for you and also potentially
useful for others. This RSON business is not one of them.


Agreed.  Even YAML's acronym indicates that it is already a bridge too 
far; we don't need more.


--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
 San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Skype erikmaxfrancis
  It's better to be quotable than to be honest.
   -- Tom Stoppard
--
http://mail.python.org/mailman/listinfo/python-list

Re: Draft PEP on RSON configuration file format

[Erik Max Francis]

Patrick Maupin wrote:

On Mar 1, 12:03 pm, Paul Rubin  wrote:


But you are working on a solution in search of a problem.  The really
smart thing to do would be pick something more useful to work on.  We
don't need another configuration language.  I can't even say "yet
another" because there's already a "yet another" called yaml.


The only "in search of" here is that, instead of working on a point
solution for my particular problem, I am "in search of" a solution
that is a bit more elegant and general, and that might help solve
other people's problems too.  If you are not one of those that has
this sort of problem at this point in time, then feel free to kill-
file this thread.


Psst.  That you're allowed to present the idea that you think is good 
doesn't mean that other people aren't allowed to respond and point out 
that in their opinion it's not such a good idea.  You don't own this or 
any other thread.


--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
 San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Skype erikmaxfrancis
  It's better to be quotable than to be honest.
   -- Tom Stoppard
--
http://mail.python.org/mailman/listinfo/python-list

Re: Draft PEP on RSON configuration file format

[Erik Max Francis]

Patrick Maupin wrote:

On Feb 28, 9:18 pm, Steven D'Aprano > Wait a minute... if JSON is too
hard to edit, and RSON is a *superset* of

JSON, that means by definition every JSON file is also a valid RSON file.
Since JSON is too hard to manually edit, so is RSON.


Well, Python is essentially a superset of JSON, with string escape
handling being ever so slightly different, and using True instead of
true, False instead of false, and None instead of null.  YMMV, but I
find it possible, even probable, to write Python that is far easier to
edit than JSON, and in fact, I have used Python for configuration
files that are only to be edited by programmers or other technical
types.


This not only seriously stretching the meaning of the term "superset" 
(as Python is most definitely not even remotely a superset of JSON), but 
still doesn't address the question.  Is RSON and _actual_ superset of 
JSON, or are you just misusing the term there, as well?  If it is, then 
your rationale for not using JSON makes no sense if you're making a new 
format that's merely a superset of it.  Obviously JSON can't be that 
unreadable if you're _extending_ it to make your own "more readable" 
format.  If JSON is unreadable, so must be RSON.


--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
 San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Skype erikmaxfrancis
  It's better to be quotable than to be honest.
   -- Tom Stoppard
--
http://mail.python.org/mailman/listinfo/python-list

Re: taking python enterprise level?...

[mdipierro]

On Mar 1, 6:32 am, simn_stv  wrote:
...
>
> > You have to follow some tricks:
>
> > 1) have the web server serve static pages directly and set the pragma
> > cache expire to one month
> > 2) cache all pages that do not have forms for at least few minutes
> > 3) avoid database joins
>
> but this would probably be to the detriment of my database design,
> which is a no-no as far as im concerned. The way the tables would be
> structured requires 'joins' when querying the db; or could you
> elaborate a little??

Joins are the bottle neck of most web app that relay on relational
databases. That is why non-relational databases such as Google App
Engine, CouchDB, MongoDB do not even support Joins. You have to try to
minimize joins as much as possible by using tricks such as de-
normalization and caching.

> > 4) use a server with at least 512KB Ram.
>
> hmmm...!, still thinking about what you mean by this statement also.

I meant 512MB. The point is you need a lot of ram because you want to
run multiple python instances, cache in ram as much as possible and
also allow the database to buffer in ram as much as possible. You will
see Ram usage tends to spike when you have lots of concurrent
requests.

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

Re: Py2exe - Bad File Descriptor

[T]

On Feb 28, 10:00 pm, Dennis Lee Bieber  wrote:
> On Sun, 28 Feb 2010 13:22:19 -0800 (PST), T 
> declaimed the following in gmane.comp.python.general:
>
> > Sorry for the lack of code - yes, it does try to write to the
> > console.  From what I'm finding, this error may be due to the fact
> > that there is no "console" to write to when I'm logged off.  However,
> > I would like to be able to print to screen if I run the EXE in debug
> > mode (i.e. "myservice.exe debug").  Do you know of any way around
> > this?  Also, I need to get the output generated from an external EXE -
> > will subprocess.Popen cause problems if I use stdout=PIPE?  Thanks for
> > your help!
>
>         True services typically don't have interactive (console) type I/O...
> What is more likely to work is to have an open socket waiting for
> connections, and the use of a separate user-space client that connects
> to the socket...
> --
>         Wulfraed         Dennis Lee Bieber               KD6MOG
>         wlfr...@ix.netcom.com      HTTP://wlfraed.home.netcom.com/

So how would that work..would the program buffer all the "print"
output, then send it to the client when it connects?  Do you happen to
know of any available code that utilizes this method, or something
similar?  Thanks for your help.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Draft PEP on RSON configuration file format

[Patrick Maupin]

On Mar 1, 5:33 pm, Erik Max Francis  wrote:
> Psst.  That you're allowed to present the idea that you think is good
> doesn't mean that other people aren't allowed to respond and point out
> that in their opinion it's not such a good idea.  You don't own this or
> any other thread.

Absolutely, but I still do (and will always) express a clear
preference for opinions that have at least a modicum of reasoning
behind them.

Regards,
Pat
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Draft PEP on RSON configuration file format

[Patrick Maupin]

On Mar 1, 5:57 pm, Erik Max Francis  wrote:
> Patrick Maupin wrote:
> This not only seriously stretching the meaning of the term "superset"
> (as Python is most definitely not even remotely a superset of JSON), but

Well, you are entitled to that opinion, but seriously, if I take valid
JSON, replace unquoted true with True, unquoted false with False,
replace unquoted null with None, and take the quoted strings and
replace occurrences of \u with the appropriate unicode, then I do,
in fact, have valid Python.  But don't take my word for it -- try it
out!

But if you really want to be pedantic about it, JavaScript (rather
than Python) is, in fact a superset of JSON, and, despite the
disparagement JavaScript receives, in my opinion, it is possible to
write much better looking JavaScript than JSON for many tasks.

YAML, also, is a superset of JSON, and IMO, it is possible to write
much better looking YAML than JSON.

> still doesn't address the question.  Is RSON and _actual_ superset of
> JSON, or are you just misusing the term there, as well?

Yes, the RSON definition, in fact, a superset of JSON, just like the
YAML definition.  But RSON is a much smaller grammar than YAML.

  If it is, then
> your rationale for not using JSON makes no sense if you're making a new
> format that's merely a superset of it.  Obviously JSON can't be that
> unreadable if you're _extending_ it to make your own "more readable"
> format.  If JSON is unreadable, so must be RSON.

Well, we'll have to agree to disagree here.  Bearing in mind that the
definition of "unreadable" depends on the target application and user,
obviously, it will be *possible* to write unreadable RSON, just as it
is *possible* to write unreadable JavaScript or Python or YAML, but it
will be *possible* to write better looking RSON than is possible to
achieve with JSON, just as it is *possible* to write better looking
JavaScript or YAML or Python than it is *possible* to achieve with
pure JSON.

Best regards,
Pat
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Method / Functions - What are the differences?

[John Posner]

On 3/1/2010 2:59 PM, Bruno Desthuilliers wrote:


Answer here:

http://groups.google.com/group/comp.lang.python/tree/browse_frm/thread/bd71264b6022765c/3a77541bf9d6617d#doc_89d608d0854dada0

I really have to put this in the wiki :-/



Bruno, I performed a light copy-edit of your writeup and put in some 
reStructuredText (reST) markup. The result is at:


  http://cl1p.net/bruno_0301.rst/

The only sentence that I think needs work is:

  Having access to itself (of course), the
  instance (if there's one) and the class, it's easy for it
  to wrap all this into a **method** object.

Maybe this?

  With the instance object (if any) and class object available,
  it's easy to create a method object that wraps the function object.


Begging pardon for my presumptuousness,
John

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

Re: Draft PEP on RSON configuration file format

[Kirill Simonov]

Erik Max Francis wrote:

Daniel Fetchinson wrote:

it is my goal (which I may or may not be smart enough to reach) to
write a module that anybody would want to use;

But you are working on a solution in search of a problem.  The really
smart thing to do would be pick something more useful to work on.  We
don't need another configuration language.  I can't even say "yet
another" because there's already a "yet another" called yaml.


And in case you are new here let me assure you that Paul is saying
this with his full intention of being helpful to you. I also would
think that working on such a project might be fun and educational for
you but completely useless if you have users other than yourself in
mind. Again, I'm trying to be helpful here, so you can focus on a
project that is both fun/educational for you and also potentially
useful for others. This RSON business is not one of them.


Agreed.  Even YAML's acronym indicates that it is already a bridge too 
far; we don't need more.




Note that YA in the acronym doesn't mean Yet Another, YAML = YAML Ain't 
Markup Language.



Thanks,
Kirill
--
http://mail.python.org/mailman/listinfo/python-list

Re: Docstrings considered too complicated

[Roy Smith]

In article ,
 MRAB  wrote:

> Ah, yes, Star Trek (the original series).
> 
> If they transported down to a planet and there was a man in a red shirt
> who you'd never seen before, he'd be the one to die! :-)

Of course.  Everybody knows there's an endless supply of red shirts.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to use python to register a service (an existing .exe file)

[Eman]

On Feb 15, 4:10 pm, News123  wrote:
> Hi,
>
> Is there a python way to register new windows services.
>
> I am aware of the
> instsrv.exe program, which can be used to install services.
> I could use subprocess.Popen to call
>
> instsrv.exe "service_name" program.exe
>
> but wondered, whether there's already an existing function.
>
> Thans in advance and bye
>
> N


Try my favorite 3rd pary tools maker, Chilkatsoft.com.
http://www.chilkatsoft.com/refdoc/pythonCkServiceRef.html

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

Re: Draft PEP on RSON configuration file format

[Kirill Simonov]

Patrick Maupin wrote:

All:

Finding .ini configuration files too limiting, JSON and XML to hard to
manually edit, and YAML too complex to parse quickly, I have started
work on a new configuration file parser.


I'd like to note that with the optional libyaml bindings, the PyYAML 
parser is pretty fast.



I call the new format RSON (for "Readable Serial Object Notation"),
and it is designed to be a superset of JSON.

I would love for it to be considered valuable enough to be a part of
the standard library, but even if that does not come to pass, I would
be very interested in feedback to help me polish the specification,
and then possibly help for implementation and testing.

The documentation is in rst PEP form, at:

http://rson.googlecode.com/svn/trunk/doc/draftpep.txt


=== cut ===
Because YAML does allow for highly readable configuration files, it
is tempting to overlook its other flaws for the task.  But a fully
(or almost) compliant parser has to understand the whole YAML
specification, and this is apparently expensive.  Running the rst2pdf
testsuite, without sphinx or most of the other optional packages, in
"fast" mode (preloading all the modules, and then forking for every
test) generates 161 smallish PDF files, totaling around 2.5 MB.  On
one test system this process takes 22 seconds.  Disabling the _json C
scanner and reading the configuration files using the json pure Python
implementation adds about 0.3 seconds to the 22 seconds.  But using
pyyaml v. 3.09 instead of json adds 33 seconds to the 22 second process!
It might seem that this is an edge case, but it makes it unacceptable to
use YAML for this sort of testing, and taking 200 ms to read in 1000
lines of simple JSON will be unacceptable in many other application
domains as well.
=== cut ===

I'd question your testing methodology.  From your description, it looks 
like the _json speedup never was enabled.  Also PyYAML provides optional 
bindings to libyaml, which makes parsing and emitting yaml much faster. 
 In my tests, it parses a 10Mb file in 3 sec.


=== cut ===
RSON semantics are based on JSON.  Like JSON, an RSON document represents
either a single scalar object, or a DAG (Directed Acyclic Graph), which
may contain only a few simple data types.
=== cut ===

JSON doesn't represent a DAG, at least, not an arbitrary DAG since each 
node in the document has no more than one parent.  It would be more 
accurate to say that that it represents a tree-like structure.


=== cut ===
The YAML syntax for supporting back-references was considered and deemed
unsatisfactory. A human user who wants to put identical information in a
"ship to" and "bill to" address is much more likely to use cut and paste
than he is to understand and use backreferences, so the additional overhead
of supporting more complex document structures is unwarranted.

The concept of a "merge" in YAML, where two sub-trees of data can be
merged together (similar to a recursive Python dictionary update)
is quite useful, though, and will be copied.  This does not alter the
outcome that parsing a RSON file will result in a DAG, but does give
more flexibility in the syntax that can be used to achieve a particular
output DAG.
=== cut ===

This paragraph assumes the reader is familiar with intricate details of 
the YAML grammar and semantics.  I bet most of your audience are 
completely lost here.


=== cut ===
Enhanced example::

key1/key2a
key3a = Some random string
key3b = 42
key1/key2a
key3c
1
2
{}
key4a = anything
key4b = something else
[]
a
b
c
3
4
key1/key2b = [1, 2, 3, 4]
key5 = ""
   This is a multi-line string.  It is
  dedented to the farthest left
  column that is indented from
  the line containing "".
key6 = [""]
   This is an array of strings, one per line.
   Each string is dedented appropriately.
=== cut ===

Frankly, this is an example that only a mother could love.  I'd suggest 
you to add some real-world examples, make sure they look nice and put 
them to the introductory part of the document.  Examples is how the 
format will be evaluated by the readers, and yours don't stand a chance.


Seriously, the only reason YAML enjoys its moderate popularity despite 
its overcomplicated grammar, chronic lack of manpower and deficient 
implementations is because it's so cute.




Disclaimer: I'm the author of PyYAML and libyaml.

Thanks,
Kirill
--
http://mail.python.org/mailman/listinfo/python-list

Re: Draft PEP on RSON configuration file format

[Patrick Maupin]

Kirill:

Thank you for your constructive criticism.  This is the gem that made
it worthwhile to post my document.  I think all of your points are
spot-on, and I will be fixing the documentation.

I can well believe that the C implementation of YAML is much faster
than the Python one, but I am aiming for something that will be
reasonably quick in pure Python.  I will double-check the JSON C test
results, but something I probably did not make clear is that the 22
seconds is not spent parsing -- that is for the entire test, which
involves reading restructured text and generating some 160 separate
PDF files.

Best regards,
Pat


On Mon, Mar 1, 2010 at 8:02 PM, Kirill Simonov  wrote:
> Patrick Maupin wrote:
>>
>> All:
>>
>> Finding .ini configuration files too limiting, JSON and XML to hard to
>> manually edit, and YAML too complex to parse quickly, I have started
>> work on a new configuration file parser.
>
> I'd like to note that with the optional libyaml bindings, the PyYAML parser
> is pretty fast.
>
>> I call the new format RSON (for "Readable Serial Object Notation"),
>> and it is designed to be a superset of JSON.
>>
>> I would love for it to be considered valuable enough to be a part of
>> the standard library, but even if that does not come to pass, I would
>> be very interested in feedback to help me polish the specification,
>> and then possibly help for implementation and testing.
>>
>> The documentation is in rst PEP form, at:
>>
>> http://rson.googlecode.com/svn/trunk/doc/draftpep.txt
>
> === cut ===
> Because YAML does allow for highly readable configuration files, it
> is tempting to overlook its other flaws for the task.  But a fully
> (or almost) compliant parser has to understand the whole YAML
> specification, and this is apparently expensive.  Running the rst2pdf
> testsuite, without sphinx or most of the other optional packages, in
> "fast" mode (preloading all the modules, and then forking for every
> test) generates 161 smallish PDF files, totaling around 2.5 MB.  On
> one test system this process takes 22 seconds.  Disabling the _json C
> scanner and reading the configuration files using the json pure Python
> implementation adds about 0.3 seconds to the 22 seconds.  But using
> pyyaml v. 3.09 instead of json adds 33 seconds to the 22 second process!
> It might seem that this is an edge case, but it makes it unacceptable to
> use YAML for this sort of testing, and taking 200 ms to read in 1000
> lines of simple JSON will be unacceptable in many other application
> domains as well.
> === cut ===
>
> I'd question your testing methodology.  From your description, it looks like
> the _json speedup never was enabled.  Also PyYAML provides optional bindings
> to libyaml, which makes parsing and emitting yaml much faster.  In my tests,
> it parses a 10Mb file in 3 sec.
>
> === cut ===
> RSON semantics are based on JSON.  Like JSON, an RSON document represents
> either a single scalar object, or a DAG (Directed Acyclic Graph), which
> may contain only a few simple data types.
> === cut ===
>
> JSON doesn't represent a DAG, at least, not an arbitrary DAG since each node
> in the document has no more than one parent.  It would be more accurate to
> say that that it represents a tree-like structure.
>
> === cut ===
> The YAML syntax for supporting back-references was considered and deemed
> unsatisfactory. A human user who wants to put identical information in a
> "ship to" and "bill to" address is much more likely to use cut and paste
> than he is to understand and use backreferences, so the additional overhead
> of supporting more complex document structures is unwarranted.
>
> The concept of a "merge" in YAML, where two sub-trees of data can be
> merged together (similar to a recursive Python dictionary update)
> is quite useful, though, and will be copied.  This does not alter the
> outcome that parsing a RSON file will result in a DAG, but does give
> more flexibility in the syntax that can be used to achieve a particular
> output DAG.
> === cut ===
>
> This paragraph assumes the reader is familiar with intricate details of the
> YAML grammar and semantics.  I bet most of your audience are completely lost
> here.
>
> === cut ===
> Enhanced example::
>
>    key1/key2a
>        key3a = Some random string
>        key3b = 42
>    key1/key2a
>        key3c
>            1
>            2
>            {}
>                key4a = anything
>                key4b = something else
>            []
>                a
>                b
>                c
>            3
>            4
>    key1/key2b = [1, 2, 3, 4]
>    key5 = ""
>       This is a multi-line string.  It is
>          dedented to the farthest left
>          column that is indented from
>          the line containing "".
>    key6 = [""]
>       This is an array of strings, one per line.
>       Each string is dedented appropriately.
> === cut ===
>
> Frankly, this is an example that only a mother could love.  I'd suggest you
> to add some