Are ActivePython scripts compatible with Linux?

[A.M]

Hi,



I am planning to develop python applications on windows and run them on 
Linux. Are ActivePython scripts compatible with Linux? Is there any 
guideline that explains the compatibility issues between python in different 
platforms?



What would be the best approach for what I am trying to do?



Any help would be appreciated,

Alan


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

Oracle Data Access in Python

[A.M]

Hi,



I am familiar with Perl's DBI programming.



In Python, do we access to Oracle by using DBI? Is Oracle DBD driver 
included with Python distributions?



What is the most common strategy for accessing to Oracle data through 
Python?





Any help would be appreciated,

Alan




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

Re: Are ActivePython scripts compatible with Linux?

[A.M]

Thanks alot Larry for your comprehensive answer.

"Larry Bates" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Short answer: yes
>
> Things to watch out for:
>
> 1) Versions on both Windows/Linux need to be compatible.  If Linux
> has same or later version, you are normally OK.  If Linux version
> is older, you will have to use only Python Libraries and functions
> that are in the oldest version.
>
> 2) Don't use OS-specific constructs.  Things like backslashes
> in filenames, etc.  Use os.path.join, os.path.basename, etc. to work
> with paths.  Linux has OS-specific code that handles all the
> cross-OS problems for you if you use these methods.  Don't hard
> code drive letters in your code, Linux/Mac don't have drive letters.
>
> 3) Obviously you can't use Python Windows extensions, which won't
> port.  You can't move something that is written as COM object or
> as a Windows service (sorry those were probably too obvious ;-).
>
> 4) If you use GUI, use something that is cross-platform (like
> wxWindows, TK, etc.).  You can't use Windows-specific GUI calls.
>
> 5) You can be affected by word length issues if you move from
> 32-bit Windows to 64-bit Linux.  Normally this is only only
> a problem if you use struct module to pack/unpack buffers or if
> you do bit shift operations (e.g. <<, >>).
>
> 6) Don't depend on Windows line endings in files.  Linux/Mac
> use different ones than Windows.
>
> 7) Some Linux machine have different endian storage of bytes.
> If you do bit shifting or struct pack/unpack you will need to
> take that into account.
>
> 8) If you have OS-specific "things" in your code, put them in
> a function or class that can easily be rewritten for the
> specific OS you are porting to.  Don't spread them out all
> through your code.  It is much easier to rewrite a couple of
> functions/classes that are OS-specific than it is to try to
> find problems all over your program.
>
> Hope info helps at least a little.
>
> -Larry
>
>
> A.M wrote:
>> Hi,
>>
>>
>>
>> I am planning to develop python applications on windows and run them on
>> Linux. Are ActivePython scripts compatible with Linux? Is there any
>> guideline that explains the compatibility issues between python in 
>> different
>> platforms?
>>
>>
>>
>> What would be the best approach for what I am trying to do?
>>
>>
>>
>> Any help would be appreciated,
>>
>> Alan
>>
>> 


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

Re: Oracle Data Access in Python

[A.M]

"Bill Scherer" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> A.M wrote:
>
>> Hi,
>>
>>
>>
>> I am familiar with Perl's DBI programming.
>>
>>
>>
>> In Python, do we access to Oracle by using DBI?
>>
> No.
>
>> Is Oracle DBD driver included with Python distributions?
>>
> No.
>
>> What is the most common strategy for accessing to Oracle data through
>> Python?
>>
> cx_Oracle seems to be the leading module for Oracle access today. It works 
> well.
>
>http://www.cxtools.net/default.aspx?nav=cxorlb
>
>
> You'll need the apropriate Oracle client installed for it to work, of 
> course. Oracle's "Instant Client" is probably the easiest way to get what 
> you need for that.
>
>
> Hope that helps,
>
> Bill

Thanks Bill for help.
I also learned about DCOracle2 at this page:
http://www.python.org/doc/topics/database/modules/

What do you think about DCOracle2? It seems to be based on Python Database 
API Specification.

Thanks again,
Ali



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

DB-API: how can I find the column names in a cursor?

[A.M]

Hi



I use a code similar to this to retrieve data from Oracle database:



import cx_Oracle



con = cx_Oracle.connect("me/[EMAIL PROTECTED]")

cur = con.cursor()

outcur = con.cursor()

cur.execute("""

 BEGIN

 MyPkg.MyProc(:cur);

 END;""", cur=outcur)



for row in out_cur:

 print row





The problem is I don't know how to find out what are the column name and 
type that comes out of query (each row in cursor).



Is there any possibility that my Python code can find out the column name 
and type in each row in cursor?



The other problem is accessing data in each row by column name. In Ruby I 
can say:



Print row["ColName"]



In Python; however, I must access to row contents by integer index, like 
PRINT ROW[0], which reduces my program's readability.



Can I access to row's contents by column name?



Any help would be appreciated,

Alan


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

Re: DB-API: how can I find the column names in a cursor?

[A.M]

Thank you Fredrik for help.

Would you be able to help with the second part of question:

The other problem is accessing data in each row by column name. In Ruby I
can say:

Print row["ColName"]

In Python; however, I must access to row contents by integer index, like
PRINT ROW[0], which reduces my program's readability.

Can I access to row's contents by column name?

Thanks again,
Alan



"Fredrik Lundh" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> "A.M" wrote:
>
>> The problem is I don't know how to find out what are the column name and 
>> type that comes out of query (each row in cursor).
>>
>> Is there any possibility that my Python code can find out the column name 
>> and type in each row in cursor?
>
>>From "cursor objects" in the DB-API documentation:
>
>.description
>
>"This read-only attribute is a sequence of 7-item
>sequences.  Each of these sequences contains information
>describing one result column: (name, type_code,
>display_size, internal_size, precision, scale,
>null_ok). The first two items (name and type_code) are
>mandatory, the other five are optional and must be set to
>None if meaningfull values are not provided."
>
> The full spec is available here: http://www.python.org/dev/peps/pep-0249/
>
> 
>
> 


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

New to Python: Do we have the concept of Hash in Python?

[A.M]

Hi,



I am new to Python, with C#/Java background



Is there any built-in Hash implementation in Python? I am looking for a 
container that I can access to it's items by name. Something like this:



Print container["memeberName"]





I am asking this because I learned that DB-API in Python doesn't offer 
access to cursor columns by name. The only option is access by index. I hope 
that I've got it wrong!



I learned Ruby perfectly supports that.





Thank you,

Alan


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

Python for Visual Basic or C# programmers

[A.M]

Hi,



I am trying to find the equivalent functions  such as vb's str or asc in 
Python. Is there any resource that help me to find these kinds of functions 
in Python faster?



Thank you,

Alan


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

Re: New to Python: Do we have the concept of Hash in Python?

[A.M]

"Fredrik Lundh" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> "A.M" wrote:
>
>> I am new to Python, with C#/Java background
>
> that's not really much of an excuse for not reading *any* Python tutorial 
> before
> you jump in...

Hi Fredrik,

1st of all, I am really impressed by this Python community. Answers are 
helpful and I am having excellent progress. I appreciate everybody's help.



This is my 1st day that I am seriously diving into Python and I have to 
finish this application by the end of today. Maybe it wasn't a good idea to 
choose the language that I don't know when I have to deliver my work in such 
short time. I understand that my question might seems very trivial to you, 
but please consider the fact that I am in time pressure and I cannot go 
through a 400 book today. I promises I'll do that this weekend ;) Wish luck 
for me!



Thank you for your post,

Alan



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

Member index in toples

[A.M]

Hi,



I have a tuple like this:



T = ("One","Two","Three","Four")



Is there any built-in way to find what is the index of "Two" withouot 
looping within the tuple?



Is the same feature available for lists or dictionaries?



Thank you,

Alan


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

How to format datetime values

[A.M]

Hi,



I have a datetime value and want to format it to "June 1, 2006" shape. How 
can I do that?



Thank you,

Alan




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

Using print instead of file.write(str)

[A.M]

Hi,



I found print much more flexible that write method. Can I use print instead 
of file.write method?



Thank you,

Alan


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

Re: How to format datetime values

[A.M]

"BartlebyScrivener" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Are you trying to get banned, or what?
>
> It's the equivalent of me asking you:
>
> Hey, does Ruby have anything like dictionaries and will you teach me
> about strings?  Oh, and what's an object?
>
> Go read the bleeping tutorial.
>
> rd
>

Well, I did investigate all tutorial and google and I wasn't able to find 
any built-in way for datetime formatting in Python. In fact I cannot find 
any way to format a long integer into 99,999, format. I know how to 
format strings with C printf like formatter, but I am sure what I am trying 
to do can't be done with C printf formatting.



I also found that mx.DateTime perfectly does date formatting and much more, 
but I don't want to add another step to the deployment process.



>> It's the equivalent of me asking you:
>> and will you teach me about strings?  Oh, and what's an object?



The answer to this post could be just a function name. I don't think I asked 
about broad concepts such as the object or strings. What I am asking here is 
just a clue.


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

Re: New to Python: Do we have the concept of Hash in Python?

[A.M]

"Fredrik Lundh" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> A.M wrote:
>
>> This is my 1st day that I am seriously diving into Python and I have to 
>> finish this application by the end of today. Maybe it wasn't a good idea 
>> to choose the language that I don't know when I have to deliver my work 
>> in such short time.
>
> are your boss aware of this ?
>
> 
>


> are your boss aware of this ?

What is wrong with *this*?
Yes, they are aware of *this*.
The application is not mission critical system. It is just a simple 
reporting tool. 


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

Re: New to Python: Do we have the concept of Hash in Python?

[A.M]

"Fredrik Lundh" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> A.M wrote:
>
>> This is my 1st day that I am seriously diving into Python and I have to 
>> finish this application by the end of today. Maybe it wasn't a good idea 
>> to choose the language that I don't know when I have to deliver my work 
>> in such short time.
>
> are your boss aware of this ?
>
> 
>


> are your boss aware of this ?

In fact my boss is quite impressed with my progress so far.



I am a little confused about the fact that you got frustrated with my posts 
today. I am not asking for a big tutorial or

deepest philosophy behind the concepts. The answer to this post could be 
just the word "Dictionary" which is 10 key stroke !

Does this hurt?






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

Re: Using print instead of file.write(str)

[A.M]

Yes, it saved my time big time.

Thank you Bruno.



I use the print >>>file to generate HTML files. print is very flexible and 
nice.



The dictionary formatting that Brunto said is awesome!



Thanks again,

Alan





"Jon Clements" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
Didn't know of the >> syntax:  lovely to know about it Bruno - thank
you.

To the OP - I find the print statement useful for something like:
print 'this','is','a','test'
>>> 'this is a test'
(with implicit newline and implicit spacing between parameters)

If you want more control (more flexibility, perhaps?) over the
formatting of the output: be it spacing between parameters or newline
control, use the methods Bruno describes below.

I'm not sure if you can suppress the spacing between elements (would
love to be corrected though); to stop the implicit newline use
something like
print 'testing',
>>> 'testing'
(but - with the leading comma, the newline is suppressed)

I personally find that print is convenient for sentences (or writing
'lines').

Thought it worth pointing this out in case, like some I know, you come
across a cropper with certain output streams.

All the best,

Jon.



Bruno Desthuilliers wrote:
> A.M a écrit :
> > Hi,
> >
> >
> > I found print much more flexible that write method. Can I use print 
> > instead
> > of file.write method?
> >
>
> f = open("/path/to/file")
> print >> f, "this is my %s message" % "first"
> f.close()
>
> To print to stderr:
>
> import sys
> print >> sys.stderr, "oops"
>
> FWIW, you and use string formating anywhere, not only in print statements:
>
> s = "some %s and % formating" % ("nice", "cool")
> print s
>
> You can also use "dict formating":
>
> names = {"other": "A.M.", "me" : "bruno"}
> s = "hello %(other)s, my name is %(me)s" % names


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

Conditional Expressions in Python 2.4

[A.M]

Hi,



I am using Python 2.4. I read the PEP 308 at:

http://www.python.org/dev/peps/pep-0308/



I tried the statement:



a= "Yes" if 1==1 else "No"



but the interpreter doesn't accept it.



Do we have the conditional expressions in Python 2.4?



Thank you,

Alan


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

Can Python format long integer 123456789 to 12,3456,789 ?

[A.M]

Hi,

Is there any built in feature in Python that can format long integer 
123456789 to 12,3456,789 ?

Thank you,
Alan



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

Re: Can Python format long integer 123456789 to 12,3456,789 ?

[A.M]

Thanks for help. Is there any comprehensive library for number formatting 
available on the net?



Alan




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

Re: New to Python: Do we have the concept of Hash in Python?

[A.M]

Well the work is done now. I arrived home at 10:30 PM.



The application takes data from Oracle 10g stored procedures and renders 
data to both HTML and CSV formats. The HTML reports have summary and 
grouping sections and the HTML files are Excel friendly. The application is 
modular and consists of reusable modules. The application is called every 
night by scheduled task. The CSV and HTML files are being deployed to Apache 
for internal employee access.



This isn't a complex and big system. Tomorrow, I'll add the email 
functionality to the application and re-use it's components for more 
reports.



Now that I finished the 1st part of the application, I have to admit that 
choosing Python was an excellent decision. Python is an awesome programming 
language with comprehensive library and great community support.



I am not that new to Python anymore.. I had a productive day. Thanks 
everybody for help.





"gregarican" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Dear A.M.,
>
> The day is complete. My TPS reports still aren't on my desk. Either
> with or without cover sheets. Not a good time to try to teach yourself
> a new language. Please gather your belongings and move down to basement
> storage C.
>
> That'd be great,
> Bill Lumberg
>
> John Machin wrote:
>> A.M wrote:
>>
>> > The application is not mission critical system. It is just a simple
>> > reporting tool.
>>
>> Famous last words.
> 


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

Re: New to Python: Do we have the concept of Hash in Python?

[A.M]

"Sion Arrowsmith" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> gregarican <[EMAIL PROTECTED]> wrote:
>>I came from using Ruby about a year or so [ ... ]
>
> That's an interesting way round. Why did you consider Python if
> you already knew Ruby, and which is now your preferred language?
> (I've no interest in learning Ruby, but from what I've seen of it
> I similarly can't imagine what would motivate me to learn Python.)
>
> -- 
> \S -- [EMAIL PROTECTED] -- http://www.chaos.org.uk/~sion/
>  ___  |  "Frankly I have no feelings towards penguins one way or the 
> other"
>  \X/  |-- Arthur C. Clarke
>   her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump

My decision wasn't based on which language I am most comfortable with. I can 
do the same application in Java in one hour. We are looking for a scripting 
language to use across our organization. This is a strategic decision. Out 
1st choice is Python, the second one is Perl and the last one is Ruby. 
Yesterday I proof that Python is way to go.



The programming language aspects of Ruby is a brilliant, but the language 
itself is not everything. I encountered some problem with Ruby and I found 
it is not there yet. Here is some of problems I have with ruby: (consider 
the fact that it is my personal opinion)



1)  Ruby community feel that there is strong database access support. I 
personally didn't find DBI distribution and documentation very organized and 
at the production level. For example, DBI:OCI8 is at experimental state. 
http://www.jiubao.org/ruby-oci8/ Oracle data access support is very 
important for me and DBI:OCI8 is the only way you can get data from Oracle 
stored procedures.

2)  Komodo (my favorite scripting IDE) crashes when I debug certain type 
of Ruby scripts. Moreover there is no ActiveRuby from ActiveState **yet**.

3)  You can find lots of excellent Python books from OREILLY. You don't 
have much option for Ruby **yet**.

4)  Ruby became famous because of Rails. Rails is a great idea, but I am 
so focused on ASP.NET and J2EE and I am going to stay there. Rails doesn't 
have a production level support for IIS. So I am not very interested in 
Rails.



In essence, Ruby language is the best, but Ruby platform is too young for 
me. I'll give Ruby another two years and come back to it again.



I found the Python language quite powerful and easy. With mature and strong 
community support.








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

Re: Conditional Expressions in Python 2.4

[A.M]

>> a = 1 == 1 and "Yes" or "No"
>> a = ("No", "Yes")[1 == 1]

Smart! Thanks alot.


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

Open Source Charting Tool

[A.M]

Hi,



I developed a HTML reporting tool that renders Oracle data to HTML and 
Oracle.



At this point I have to add charts (3d bars and pie charts) to this 
application. I don't think that I have to do it from scratch.



Is there any open source charting tool that help me create charts in JPG or 
gif format?



Thanks,

Alan


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

Re: Open Source Charting Tool

[A.M]

Hi Larry,



I can't browse to www.reporlab.org, but I found http://www.reportlab.com/ 
which has a  commercial charting product. Is that what you referring to?



Thanks,

Alan



"Larry Bates" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> ReportLab Graphics can do 2D and pie charts, but I don't think it does
> 3D charts yet.
>
> www.reporlab.org
>
>
> Larry Bates
>
> A.M wrote:
>> Hi,
>>
>>
>>
>> I developed a HTML reporting tool that renders Oracle data to HTML and
>> Oracle.
>>
>>
>>
>> At this point I have to add charts (3d bars and pie charts) to this
>> application. I don't think that I have to do it from scratch.
>>
>>
>>
>> Is there any open source charting tool that help me create charts in JPG 
>> or
>> gif format?
>>
>>
>>
>> Thanks,
>>
>> Alan
>>
>> 


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

os.system and command output

[A.M]

Hi,



How can I run an OS command and have the command's output (to stdout) in my 
string variable?



For example in windows, this command should return a list of files within 
directory:



os.system("DIR")



I am looking for an alternative function that returns the DIR command output 
in a string



Thanks,

Alan


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

Re: os.system and command output

[A.M]

> Try:
>
> s = os.popen("DIR").read()
>
Thanks Steve.

Is there anyway I can get the exit code (what os.system returns) from
os.popen? 


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

Win XP Error: There is not enough space on the disk

[A.M]

Hi,



I am using ActivePython 2.4.on windows XP



I created test.py that contains the following simple script:





import os

os.system("dir *.py")





When I run the script, it works fine. But, when I run the following command 
on windows XP:



Test.py > file.txt



I receive this error: "There is not enough space on the disk." Which is not 
correct.



I am translating dos batch files to python scripts and I redirect the stdout 
output of all scripts to a LOG file. With this error, I cannot have a log 
file for my Python scripts.



Is there any way that I can fix this problem?



Thanks,

Alan




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

Win XP: Problem with shell scripting in Python

[A.M]

Hi,



I am having difficulty with shell scripting in Python.



I use the following command to run a DOS command and put the return value in 
a Python variable:



print os.popen('DIR').read()



It works very fine with DIR command, but for commands like "MD :" it doesn't 
return the error message into the string:



print os.popen('MD :').read()

# No error message



When I use Ruby, it works perfect:



`md :`

The filename, directory name, or volume label syntax is incorrect.



I am also having problem with redirecting the python script output to a 
file: That means I can redirect the output to a file by using pipes like 
this:



Python.exe script.py >file.txt



But the sequence of contents in file.txt  doesn't match with command 
execution sequence!

When I don't use pipes, the output sequence is fine when I see the output on 
the monitor screen.



Am I missing anything? Considering the fact that Ruby doesn't have any 
problem with redirecting STDOUT into files or string variables, is Python 
the right tool for this kinds of shell scripting?



Any help would be appreciated,

Alan




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

Re: Win XP: Problem with shell scripting in Python

[A.M]

"Fredrik Lundh" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> A.M wrote:
>
>
> in python, "MD" is spelled os.mkdir.
>
>> Am I missing anything?
>
> the difference between STDOUT and STDERR, and the difference between 
> buffered output and non-buffered output, and perhaps a few other things 
> related to how STDIO behaves on modern computers...  however, if you want 
> to pretend that STDOUT and STDERR are the same thing, you can use 
> os.popen4:
>
> >>> o, i = os.popen4("md :")
> >>> i.read()
> 'The filename, directory name, or volume label syntax is incorrect.\n'
>
> or the subprocess module.
>
>> Considering the fact that Ruby doesn't have any problem with redirecting
> > STDOUT into files or string variables, is Python the right tool for
> > this kinds of shell scripting?
>
> rewriting BAT files as a series of os.system or os.popen calls isn't 
> exactly optimal (neither for the computer nor the programmer nor the 
> future user); better take an hour to skim the "generic operating system 
> services" section in the library reference, and use built-in functions 
> wherever you can:
>
> http://docs.python.org/lib/allos.html
>
> the following modules are especially useful:
>
> http://docs.python.org/lib/module-os.html
> http://docs.python.org/lib/module-os.path.html
> http://docs.python.org/lib/module-glob.html
> http://docs.python.org/lib/module-shutil.html
>
> by using the built-in tools, you get better performance in many cases, 
> better error handling, and code that's a lot easier to reuse (also on 
> non-Windows platforms).
>
> 
>


Thanks Fredrik for help.



The "MD :" is just a sample. The actual script contains different commands.



The actual script that I am "translating" consolidates huge table data from 
multiple SQL Server database into Oracle. I have to use BCP command line at 
the SQL server side and SQL*Loader at the Oracle side.



I must capture the stdout/stderr output of command lines into log files for 
future inspection/troubleshooting. Beside the issue with stdout/stderror, 
the main stressful problem that I have is the fact that Python captures 
command line's output somehow differently. For example, popen captures BCP's 
command output completely wrong. Some part of summary is at the top and the 
progress percentages are at the bottom and more.! This is just stdout 
output.



I am going to investigate other popen4 and other popen forms per your 
suggestion and try to fix the stdout sequence problem.



Regards,

Alan




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

Re: Win XP: Problem with shell scripting in Python

[A.M]

> I dare hardly suggest this, but might it not be better to use Python's
> database functionality to perform the task? The language can access both 
> databases, and you might find it quicker. Then again, if your database 
> experience is limited, you may not ...
>
> regards
>  Steve
> -- 
> Steve Holden   +44 150 684 7255  +1 800 494 3119
> Holden Web LLC/Ltd  http://www.holdenweb.com
> Love me, love my blog  http://holdenweb.blogspot.com
> Recent Ramblings http://del.icio.us/steve.holden
>

Hi Steven,



Based on my experience, the fastest possible way to import raw data into 
Oracle is SQL*Loader. Similarly, the fastest way to extract raw data from 
SQL server is BCP.



My script transfers 40,000,000 records (actually big records) from sql 
server to oracle in 20 Min. I tried ODBC to do the same work. I turned off 
all record locking and transactions through query hints. The actual program 
was a C# program. After 12 hours, I just stopped the program.



I created DOS batch files to control BCP and SQL*Loader steps. It is faster 
than any fancy GUI tools. Now I am using Python.



I am thinking to add comprehensive logging to the ETL (extract transform 
load) process. All details command line outputs will be stored in database. 
System administrators can query database and watch how the ETL job is 
working.



At this point I have quite challenge with capturing BCP's stdout/stderr 
output to string variables in Python program.



I'll post the final outcome here.



Regards, Alan


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

Re: Win XP: Problem with shell scripting in Python

[A.M]

Here is what I came up with after John and Fredrik's help.



import os

import sys



def Execute(shell_command,logStream = sys.stdout):

print >>logStream, shell_command

child_stdin, child_stdout_and_stderr  = os.popen4(shell_command)

commad_output = child_stdout_and_stderr.read()

print >>logStream,  commad_output

return_code = child_stdout_and_stderr.close()

return_code = return_code or child_stdin.close()

print  >>logStream, "Return Code: " , return_code



Execute ("DIR")

Execute ("MD :")



I tested it and so far it behaves the way that I want.



The tricky part is that when you use popen4, you have to close both returned 
streams to be able to get the return code. I wasn't able to find that in the 
documentation.



Alan




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

Re: Win XP: Problem with shell scripting in Python

[A.M]

>Does it overcome the problem that you reported earlier, that the
contents of the output file from BCP were out of order?



Yes, it does. But, to be honest, I don't know how!!!





"John Machin" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> On 10/06/2006 3:00 AM, A.M wrote:
>> Here is what I came up with after John and Fredrik's help.
>>
>> import os
>> import sys
>> def Execute(shell_command,logStream = sys.stdout):
>> print >>logStream, shell_command
>> child_stdin, child_stdout_and_stderr  = os.popen4(shell_command)
>> commad_output = child_stdout_and_stderr.read()
>> print >>logStream,  commad_output
>> return_code = child_stdout_and_stderr.close()
>> return_code = return_code or child_stdin.close()
>> print  >>logStream, "Return Code: " , return_code
>>
>> Execute ("DIR")
>>
>> Execute ("MD :")
>>
>> I tested it and so far it behaves the way that I want.
>>
>
> Does it overcome the problem that you reported earlier, that the contents 
> of the output file from BCP were out of order? If not, you may like to try 
> popen3(). It's quite possible (and indeed desirable) that the child's 
> stderr is not buffered (so that error messages appear immediately) but the 
> child's stdout is buffered (for efficiency), and when the buffer is 
> flushed governs the order of appearance in a single output stream.
>>
>>
>> The tricky part is that when you use popen4, you have to close both 
>> returned streams to be able to get the return code. I wasn't able to find 
>> that in the documentation.
>
> In general it is good practice to hand back resources (e.g. close files) 
> explicitly as soon as you are finished with them. This is especially 
> important for files open for writing, in case there are problems like out 
> of disk space, device not functioning etc. Also when you are dealing with 
> a child process it makes some sense to close its stdin first just in case 
> it is waiting for that, and will then write something to stdout, which may 
> fail, causing it to write to stderr. So I guess that the documenter didn't 
> stumble onto the "tricky part" :-)
>
> The "tricky part" for popen and friends seems to be that the return code 
> is handed back upon close of the *last* file:
>
> |>>> h = os.popen3('md : ')
> |>>> [h[x].close() for x in 2, 1, 0]
> [None, None, 1]
>
> Looks like you get to report a documentation "problem" after all :-)
>
> Cheers,
> John
>
> 


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

Looking for examples related to advanced python string, list and map operations

[A.M]

Hi,



Is there any online resource that gives examples about advanced python 
string, list and map operations?



Today I saw this and I found that I have to work more on mentioned topics:



numbers = [72, 101, 108, 108, 111, 44, 32, 119, 111, 114, 108, 100, 33]

print filter(lambda n: n % 2 == 0, numbers)



numbers = [72, 101, 108, 108, 111, 44, 32, 119, 111, 114, 108, 100, 33]

print reduce(lambda x, y: x+y, numbers)



Thank you,

Alan


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

Re: How to insert in a string @ a index

[a.m.]

Thanks guys for you help. I ended up doing this way (for the
records)...

t1 = "hello world hello. hello. \nwhy world hello"

while indexhttp://mail.python.org/mailman/listinfo/python-list

question on python syntax

[a.m.]

If I type this in shell

$ ./yourfile.py 12:34 PM &

What does '$', '.', '/' and '& means in this succession? Note: 12:34
PM is a argument to the yourfile.py.

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

Python sample code for PLSQL REF CURSORS

[A.M]

Hi,



I am having hard time to find a sample that shows me how to return an OUT 
REF CURSOR from my oracle stored procedure to my python program.



The technique is explained here for Java and Visual Basic:

http://www.oracle-base.com/articles/8i/UsingRefCursorsToReturnRecordsets.php



I am looking for similar code for Python



Any help would be appreciated,

Alan


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

Python for Perl programmers

[A.M]

Hi,



Is there any efficient online resource or book that help experienced Perl 
programmers to Python?



Thank you,

Alan


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

Re: Python sample code for PLSQL REF CURSORS

[A.M]

Exactly what I was looking for.

Thanks alot


"Gerhard Häring" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> A.M wrote:
>> Hi,
>>
>> I am having hard time to find a sample that shows me how to return an OUT 
>> REF CURSOR from my oracle stored procedure to my python program. [...]
>
> import cx_Oracle
>
> con = cx_Oracle.connect("me/[EMAIL PROTECTED]")
> cur = con.cursor()
> outcur = con.cursor()
> cur.execute("""
> BEGIN
> MyPkg.MyProc(:cur);
> END;""", cur=outcur)
>
> for row in out_cur:
> print row
>
> HTH,
>
> -- Gerhard 


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

Re: C#3.0 and lambdas

[A.M. Kuchling]

On Fri, 23 Sep 2005 15:46:54 +0530, 
Ganesan Rajagopal <[EMAIL PROTECTED]> wrote:
> I agree. I am a lurker in this list and the python-devel list and I've also
> noticed that increasingly big discussions happen over fairly minor
> things. Python's DB API is still stuck at 2.0 and we can't even agree on a
> single parameter style while C# is innovating and moving ahead with the "big
> picture" stuff.

The group of committers is a diverse group of people, and not every one of
them uses a relational database; that effort would be better done on the
DB-SIG mailing list, because the people there presumably do all use an
RDBMS.  (Now, if you wanted to include SQLite in core Python, that *would*
be a python-dev topic, and ISTR it's been brought up in the past.) 

This is also something the PSF might fund.  The next time the PSF calls for
grant proposals, someone could request funding to edit a new revision of the
DB-API.

> I'd like to see the DB API move forward, and experimental new innovations
> like static typing (with automatic type inferencing), stackless python
> etc. If the experiments don't survive, fine. It's still better than
> quibbling over minor syntactic detail.

Agreed; python-dev has gotten pretty boring with all the endless discussions
over some minor point.  Of course, it's much easier and lower-effort to
propose a syntax or nitpick a small point issue than to tackle a big
complicated issue like static typing.  

Similar things happen on the catalog SIG: people suggest, or even implement,
an automatic package management system, But bring up the question of whether
it should be called PyPI or Cheeseshop or the Catalog, and *everyone* can make
a suggestion.

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

Reminder: PyCon proposal deadline is Oct. 31st

[A.M. Kuchling]

The deadline for PyCon proposals is now three weeks away;
proposals must be received by Oct. 31st.

Read the call for proposals for what we're looking for and how to submit:
<http://www.python.org/pycon/2006/cfp>

The proposal submission site is <http://submit.python.org>.

A.M. Kuchling
Chair, PyCon 2006
[EMAIL PROTECTED]

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

Reminder: PyCon proposals due in a week

[A.M. Kuchling]

The deadline for PyCon 2006 submissions is now only a week away.  
If you've been procrastinating about putting your outline together, 
now's the time to get going...

Call for Proposals: 
http://www.python.org/pycon/2006/cfp

Proposal submission site:
http://submit.python.org/

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

PyCon: suggestions for tutorial speakers wanted

[A.M. Kuchling]

A planned new addition to PyCon 2006 is a day of tutorials before the
conference; tutorials will cost extra and give attendees a chance to
take a 3-hour introduction to Python (or some other topic) before they
leap into conference-going.

A Call for Tutorials will be posted soon. It'll go to
comp.lang.python.announce as usual, but we'll also send it directly to
various people who do Python training professionally. Which leads to
my request...

Have you taken a Python-related course from a professional who turned
out to be really good? We'd like to know about such people so that we
can send them a copy of the Call for Tutorials. Please let me know,
either here or in private e-mail.

If you're interested in giving a tutorial, you can also express an
interest in order to receive the CFT; just drop me a line and I'll
save your e-mail.  You should plan for a 3-hour session, interrupted
by a break halfway through. Further details and requirements will be
in the CFT when it appears; I'm hoping it'll go out next week.

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

PyCon: proposal deadline is today

[A.M. Kuchling]

Today is your last chance to get in your PyCon 2006 submissions.  (If
you can't finish an outline today, you can still submit a summary and
provide the outline in a few days.)

Conference site:http://www.python.org/pycon/2006/
Call for Proposals: http://www.python.org/pycon/2006/cfp
Submission site:http://submit.python.org


A.M. Kuchling
Chair, PyCon 2006
[EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python.org offline

[A.M. Kuchling]

On Tue, 1 Nov 2005 18:18:06 +0100, 
Sybren Stuvel <[EMAIL PROTECTED]> wrote:
> Yes, I can read. My question is: does anyone know why this happens so
> often lately?

I suspect this is teething problems related to the move to a new
server.  I've bumped up the number of Apache processes, so we'll see
if that alleviates the problem.

--amk

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

PyCon 2006 Call for Tutorials

[A.M. Kuchling]

PyCon 2006 Call for Tutorials
--

Enjoy teaching classes or tutorials? PyCon 2006 is looking for
proposals for a pre-conference tutorials day.  PyCon 2006 will be held
February 24-26 in Addison, Texas (near Dallas).  Tutorials will be held
on February 23, at the same location.

Tutorial sessions will be a half day (3 hours, with a 15-minute break);
presenters may request two sessions in order to make up a full day.
Tutorials may be on any topic, but obviously should be instructional in
nature. Providing take-home materials for attendees is encouraged, and
tutorial presenters will receive $50 per student registered for theirsession 
(with a minimum payment of $500, and a maximum of $1500).

Extra consideration will be given to presenters with prior experience
teaching classes or giving conference tutorials. Please provide one
reference or evidence of such prior experience (sessions taught at
OSCON, EuroPython, local user groups, etc.).

PyCon attendees will register for tutorials.  We reserve the right to
cancel tutorials with low attendance; presenters will not be paid for
cancelled tutorials.

Example tutorial topics can be found at:
http://us.pycon.org/TX2006/Tutorials

Important Dates
===

* Submission deadline: November 15, 2005
* Acceptance deadline: November 22, 2005
* Cancellation date: January 15, 2006  (for inadequate attendance)

Submission Format


Proposals should be 250 to 1000 words long (i.e., one to four pages in
manuscript format), containing the following information:

* Author name(s)
* Contact Information
* (Recommended) At least one previous presentation/teaching engagement
reference
* Summary of proposed presentation
* Presentation outline
* Intended audience (non-programmers, beginning programmers, advanced
  users, CPython developers, etc.)

E-mail your proposal to <[EMAIL PROTECTED]>.

ASCII format is preferred (plain or reST), with HTML as a secondary
alternative. If you have any questions about submission, please send
mail to the conference organizers at [EMAIL PROTECTED]
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Why are there no ordered dictionaries?

[A.M. Kuchling]

On 22 Nov 2005 01:41:44 -0800, 
Kay Schluehr <[EMAIL PROTECTED]> wrote:
> Does anyone actually use this site? While the Vaults offered a nice
> place and a nice interface the Cheese Shop has the appeal of a code
> slum. 

Looking at the Cheese Shop's home page at
http://cheeseshop.python.org/pypi, which lists recent package updates,
three packages were updated on 11/22, and three on 11/21.  Two on
11/20, six on 11/19 (someone was busy!).

Looking at the Vaults's 'latest' page at
http://py.vaults.ca/apyllo.py?a=l, two packages were updated on 08/23,
and five on 08/06.  

What would improve the Cheese Shop's interface for you?

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

Re: XML and namespaces

[A.M. Kuchling]

On 30 Nov 2005 07:22:56 -0800, 
[EMAIL PROTECTED] <[EMAIL PROTECTED]> quoted:
> >>> element = document.createElementNS("DAV:", "href")

This call is incorrect; the signature is createElementNS(namespaceURI,
qualifiedName).  If you call .createElementNS('whatever', 'DAV:href'),
the output is the expected:


It doesn't look like there's any code in minidom that will
automatically create an 'xmlns:DAV="whatever"' attribute for you.  Is
this automatic creation an expected behaviour?  

(I assume not.  Section 1.3.3 of the DOM Level 3 says "Similarly,
creating a node with a namespace prefix and namespace URI, or changing
the namespace prefix of a node, does not result in any addition,
removal, or modification of any special attributes for declaring the
appropriate XML namespaces."  So the DOM can create XML documents that
aren't well-formed w.r.t. namespaces, I think.)

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

Re: XML and namespaces

[A.M. Kuchling]

On 2 Dec 2005 06:16:29 -0800, 
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Of course.  Minidom implements level 2 (thus the "NS" at the end of the
> method name), which means that its APIs should all be namespace aware.
> The bug is that writexml() and thus toxml() are not so.

Hm, OK.  Filed as bug #1371937 in the Python bug tracker.  Maybe I'll
look at this during the bug day this Sunday.

--amk

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

Re: Dr. Dobb's Python-URL! - weekly Python news and links (Dec 2)

[A.M. Kuchling]

On 5 Dec 2005 14:10:00 -0800, 
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Well, I was running Python-2.4.1 so I upgraded to 2.4.2 and guess
> what?  The docs still reference the old Howto.  Perhaps you meant
> to say "will be fixed in 2.5" rather than "has been fixed"?

The docs reference the sorting howto?  Can someone please tell me
where so that I can check that the URL is correct?  (grep doesn't turn
it up, so I suspect you're talking about something other than the
Python documentation.)

--amk

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

Re: Bitching about the documentation...

[A.M. Kuchling]

On Mon, 05 Dec 2005 20:56:50 GMT, 
Bengt Richter <[EMAIL PROTECTED]> wrote:
> A little more effort could present the referrer page with clickable
> paragraphs and other elements, to zoom in to what the commenter
> wants to comment on. And an automatic diff could be prepared for
> editors, and the submitted info could go in a structured file for
> automated secure web access by editors to ease review and presumably
> sometimes pretty automatic docs update. Adherence to submission
> guidelines could be enforced somewhat by form checks etc.

"A *little* more effort"?  This is obviously some strange new
definition of "little".  I'd love to see such a system, but it would
be a significant effort to build such a system, and the Python
developers do not have the spare manpower to do it.  It would be a
great volunteer project for someone to undertake, but I don't think
Fred Drake or anyone else has the spare CPU cycles to work on it.

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

Re: Bitching about the documentation...

[A.M. Kuchling]

On Tue, 6 Dec 2005 00:05:38 -0500, 
François Pinard <[EMAIL PROTECTED]> wrote:
> It's a relatively recent phenomenon that maintainers go berzerk, foaming 
> at the mouth over forms, borders, colors, and various other mania!  :-)

It's largely to ensure that the ideas aren't lost.  E-mail sits around
in an inbox until it gets deliberately deleted or gets lost in a disk
crash or system upgrade gone wrong.  Usenet posts fall out of the news
spool and get buried in Google's archives.

For example, here are the oldest messages in my mailbox:

   1 Mar 24 Whitesell, Ken  (3.5K) [PyCON-Organizers] Feedback from a first-
   2 Mar 28 Martin Maney(1.4K) Improving "The Python DB-API interface"
   3   T Mar 28 MW Mike Weiner  (1.0K) RE: [Pycon2005-attendees] Found items
   4   + Mar 28 Mark Wittner(0.8K)  *¬>
   5   + Mar 29 Anna Ravenscrof (0.9K)   >
   6  s+ Mar 28 David Goodger   (1.4K) Re: Q. about Emacs on MacOS
   7   + Apr 04 Neal Norwitz(250K) Re: PyCon treasury question
   8 Apr 28 Thorsten Leemhu (0.7K) python-crypto RIPEMD160 and SHA256 not 64
   9   + May 01 nemir nemiria   (0.4K) regular expression how-to suggestion.
  10 May 07 Brian Hook  (0.3K) pycrypto
  11 May 23 John Lambert (W (3.7K) python howto: regular expressions - issue
  12   T Jun 01 Tim Parkin  (2.5K) pydotorg redesign
  13   T Jun 02 Neal Norwitz(2.3K) Re: [Python-Dev] Vestigial code in thread
  14   + Jun 09 Jacob Rus   (0.5K) python regular expression howto
  15 Jun 17 Zed Lopez   (0.5K) [pct] decrypting a ciphertext with an RSA
  16 Jun 21 Skip Montanaro  (1.3K) Re: [Pydotorg] Python Homepage: possible
  17 Jun 27 Osvaldo Santana (0.7K) [marketing-python] Python Powered in Core
  18   + Jul 09 Martin Kirst(0.3K) pycrypto pre build binaries for windows,
  19 Jul 10 Jeff Rush   (0.9K) [PyCON-Organizers] Two Good Developments
  20 Jul 13 [EMAIL PROTECTED]  (2.5K) Re: [Quixote-users] Quixote 2 Docs
  21   T Jul 15 Nick Jacobson   (0.4K) py3k

#2 from Martin Maney is a suggestion about a web page I have on the DB-API.  
#8 is a pycrypto bug report; I think the bug is fixed now, but would have 
to check.
#9 and #11 are suggestions for the regex HOWTO.
#10, #15, #18 could be suggestions, bug reports, or questions; hope
they're not questions or bugs, because the chance of them being
answered is zero at this point.

You may suggest that I should process my e-mail more promptly.  True,
but that's very hard; there's always newer e-mail coming in.  Do less?
I'd love to, but that doesn't seem to be a viable option.

I could just delete all this mail, but I still have the hope of
someday doing a rewrite pass on, say, the regex howto, going through
all the suggestions and making some changes accordingly.  I am,
however, drifting toward the Linus Torvalds approach of mail handling:
delete messages after six months.  If the message was important,
they'll resend it.  A pity that it means Martin's suggestions, and
Thorsten's bug, and Nemir's suggestion, get discarded.

This is why things need to go into public trackers, or wiki pages.
There, at least their content is available to someone else; if
someday, someone else does a new regex howto, they could use the
suggestions and patches that have accumulated over time.  

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

Documentation suggestions

[A.M. Kuchling]

Here are some thoughts on reorganizing Python's documentation, with
one big suggestion.

The tutorial seems to be in pretty good shape because Raymond
Hettinger has been keeping it up to date.  It doesn't cover
everything, but it's a solid introduction, and if people don't find it
works for them, they have lots of alternative books.  No suggestions
here.

There are endless minor bugs in the library reference, but that seems
unavoidable.  It documents many different and shifting modules, and
what to document is itself a contentious issue, so I don't think the
stream of small problems will ever cease.

There's another struggle within the LibRef: is it a reference or a
tutorial?  Does it list methods in alphabetical order so you can look
them up, or does it list them in a pedagogically useful order?  I
think it has to be a reference; if each section were to be a tutorial,
the manual would be huge.  Here I think the solution is to encourage
separate tutorials and HOWTOs, and link to them from the LibRef.

The library reference has so many modules that the table of contents
is very large.  Again, not really a problem that we can fix; splitting
it up into separate manuals doesn't seem like it would help.

The Extending/Embedding manual isn't great, but only advanced users
will come in contact with it, so I don't think it's a critical factor.
(Michael Hudson's new manual is a promising replacement.)

I suspect the Achilles' heel of the docs is the Language Reference.
Put aside the fact that it's not up to date with new-style classes and
other stuff; that would be fixable with some effort.

To some degree, the guide is trying to be very formal; it's written
like a specification for an implementor, not a document that people
would read through.  But there's no other way for people to learn
about all the special object methods like __add__; the tutorial can't
cover them all, and the LibRef doesn't describe them.  So the newbie
is stuck.

For example, I noticed this passing reference in Tim Bray's weblog:
http://www.tbray.org/ongoing/When/200x/2005/08/27/Ruby

Based on first impressions and light exposure (a basis that
matters a lot) Ruby seems better-documented and easier to get
into than Python. I've actually written (a little)
production code in Python, but I always had the feeling that
there was lots of stuff going on I didn't understand; a
couple of days in, I think I have a better grasp on what
Ruby's up to, even where I'm not looking.

I don't know exactly what Bray meant, but suspect that a more readable
reference guide would have helped him understand what was going on.

Perhaps we need a friendlier counterpart to the RefGuide, something
like the 20-page introduction to Python at the beginning of Beazley's 
Essential Reference:

  * go over the statements one-by-one
  * go over the basic types and their methods
  * go over object semantics
  * cover some of the lexical material in chapter 2 of the RefGuide
  * overarching principles: go into a fair bit of detail, but
not every corner case; make the text readable, not meticulously 
precise.

(I should point out: this suggestion is not entirely different from
some of the suggestions that X*h L** has made.  He (?) makes his
suggestions in a venomous style, and with his own eccentric
terminology, but that doesn't mean he's always wrong, e.g. his
complaints about the re module's documentation are well-placed in the
main.)

One problem with such a friendly document: it might make the Ref Guide
even more irrelevant, if we always updated the friendly document
(which is easy) and left the RefGuide to drift even further out of
date (because it's hard to update).  I don't know if this is an
argument for not having a friendly guide, or for dumping the RefGuide
entirely.

Dumping the RefGuide means there isn't a more formal-style description
of Python's semantics.  I don't know if this matters.  In theory, the
implementors of Jython or IronPython could be using the RefGuide to
know what they need to implement, but in practice I suspect
implementors use the test suite and existing library as checks.  Maybe
we don't really need a tediously precise description of Python.

What do people think?  

--amk

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

Re: Documentation suggestions

[A.M. Kuchling]

On Tue, 6 Dec 2005 11:28:12 -0600, 
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Somehow I think Guido would eventually put his (16-ton) foot down. ;-)

Maybe, but he hasn't put his foot down on new-style classes yet, which
were added in 2.2.  It would be all to the good if the BDFL (or the
release manager -- not sure whose decision this is) said that 2.5
can't be released until the docs are up-to-date.

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

Re: Documentation suggestions

[A.M. Kuchling]

On Tue, 6 Dec 2005 18:33:05 +0100, 
> I've proposed adding support for semi-automatic linking to external
> documents, based on a simple tagging model, a couple of times, e.g.
> 
> http://mail.python.org/pipermail/python-list/2005-May/280751.html

Very interesting.  There could be a manually-maintained list of feed
URLs stored in a file in the Doc/ subdirectory.  That way, anyone with
Python SVN access could add a feed, and it's not trapped in some
database on python.org that half the pydotorg group doesn't know
about.

A Makefile target could then update the list of available examples,
and check timestamps to only update the list every 24 hours or so,
avoiding hitting the feeds every time you do "make lib".  Fred Drake
would have some "make updatefeed" target for forcing an update when he
makes the release tarballs.

ISTM getting the example into the HTML is the hard bit.  Maybe the
simplest solution is to put

% start auto-feeds
% end auto-feeds 

into LaTeX source files, and have a script insert the examples between
the markers with the right LaTeX markup.  

Hm, but then 'svn diff' will show lots of changes.  Maybe an '\input
-examples could be used instead, storing the examples in a
separate file.  Something like
'\InputFileExists{examples/select.tex}'...  Having some examples be
for'atexit' and some specifically for 'atexit.register' seems
difficult with this approach.  

Assembling a patch for this would make an interesting evening's
project.  

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

Re: Documentation suggestions

[A.M. Kuchling]

On 6 Dec 2005 10:10:09 -0800, 
Ian Bicking <[EMAIL PROTECTED]> wrote:
> stable personal pages that should be linked in .  But I do think that
> we should encourage some specific process for new or revised
> tutorial/howto contributions, like encouraging people put such material
> in the wiki.  

To this end, I've moved the howtos off their separate SourceForge
project, and into Doc/howto in Python SVN.  The sorting howto seemed
small enough and incomplete enough that it would be better as a wiki.
There's another small one, doanddont.tex, that might also be good as a
wiki page.  I'm currently not planning to convert any of the larger
documents, such as the curses or regex ones, to wiki format.

--amk

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

Re: Documentation suggestions

[A.M. Kuchling]

On Tue, 06 Dec 2005 10:29:33 -0800, 
Michael Spencer <[EMAIL PROTECTED]> wrote:
> not that helpful.  "Miscellaneous Services", in particular, gives no clue to 
> treasures it contains.  I would prefer, for example, to see the data 
> structure modules: collections, heapq, array etc... given their own section. 
> Documentation/testing, cmd/options might be other candidates to draw together
> currently related material more meaningfully.

You're right; "Miscellaneous Services" is a grab-bag of stuff, and so
are 'Generic OS Services' and 'Optional OS Services'.  These chapters
should be rearranged into more, smaller chapters.  

A patch for a draft reorganization is at http://www.python.org/sf/1375417

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

Re: Documentation suggestions

[A.M. Kuchling]

On Wed, 7 Dec 2005 09:36:24 +0100, 
Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> or just add a marker (in some for me unknown way), and postprocess
> the HTML files.  I'm not sure the links does necessarily belong in e.g.
> PDF renderings of the documentation, but that's of course up to the
> documentation maintainers.

I'm just scared of hacking the LaTeX2HTML translator customizations,
and would rather do things to the LaTeX input.

> if anyone wants some data to play with, I've posted a simple seealso file
> here:

Thanks!  I've written a little parser and output script; they're in
Python SVN at sandbox/trunk/seealso.  (Browseable at
http://svn.python.org/view/sandbox/trunk/seealso/).

With a patch to the Makefile and the module's *.tex file, it's
possible to use these scripts to pull in examples.  Modifying all the
*.tex files is tedious, but I suspect we can make it an automatic part
of the seealso environment.  I'll talk to Fred about it and begin
assembling a patch.

--amk

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

Re: Documentation suggestions

[A.M. Kuchling]

On Wed, 7 Dec 2005 07:45:13 -0600, 
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Just because that audience is small doesn't mean they are unimportant.
> There are currently four actively maintained/developed implementations of
> Python.  A common language reference manual is important for them, and
> indirectly for the people who use the four implementations.

They're not unimportant, but I don't think the reference manual *is*
important to them because they've gotten this far with an outdated
one; the code may be resource enough.  This is why I think that the
effort expended to update a document aimed at them might be better
spent on something more widely useful.

I remembered another problem from the weekend with documenting
new-style classes.  It seemed reasonable to begin with PEP 252, and
see if any bits of the PEP can be migrated into the RefGuide, but then
I found this comment in the abstract:

[Editor's note: the ideas described in this PEP have been
 incorporated into Python.  The PEP no longer accurately
 describes the implementation.]

So now we're *really* stuck.  The RefGuide doesn't describe the rules;
the PEP no longer describes them either; and probably only Guido can
write the new text for the RefGuide.  (Or are the semantics the same
and only some trivial details are different?)

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

Re: Documentation suggestions

[A.M. Kuchling]

On 7 Dec 2005 05:51:45 -0800, 
Iain King <[EMAIL PROTECTED]> wrote:
> Argh, you made me look at the html again - at least now I know *why* it
> is so disgusting.  I understand there's a new version coming out soon,
> hopefully in html 4 strict or xhtml.  I'm sure at that point it'll be
> easier to use.  I can wait. :)

A new version of LaTeX2HTML, you mean?  Can you provide a pointer?  

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

Re: Documentation suggestions

[A.M. Kuchling]

On Wed, 07 Dec 2005 12:10:18 -0500, 
Kent Johnson <[EMAIL PROTECTED]> wrote:
> OK I'll bite. That Beginners Guide page has bugged me for a long time. 
> It's a wiki page but it is marked as immutable so I can't change it. 
> Here are some immediate suggestions:

Good suggestions; thanks!  I've applied most of them.

> - Change the sentence "Read BeginnersGuide/Overview to learn the key 
> points." to "Read BeginnersGuide/Overview to learn what makes Python 
> special." Or maybe get rid of it completely - I'm not sure evangelism 
> belongs on this page.

Yes, it does; fairly often the webmaster alias receives e-mails that
ask "so what is Python?"

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

Re: Documentation suggestions

[A.M. Kuchling]

On Wed, 07 Dec 2005 12:58:36 -0800, 
Michael Spencer <[EMAIL PROTECTED]> wrote:
> I experimented with some more re-organization, but I don't see away
> to attach the resulting file in the SF comments, so I'll post it
> here instead.

I've attached your file to the patch.  Some comments:

> \input{libstruct}   % also/better in File Formats?

Struct operates on string input and produces string output, so I think
it belongs in the string chapter where you've placed it.  We need to
add more cross-references, so File Formats should mention struct as a
related module.

> % Functions, Functional, Generators and Iterators
> \input{libitertools}
> \input{libfunctional}
> \input{liboperator}   % from runtime - better with itertools and 
> functional

> % encoding stuff
  ...
> \input{libxdrlib}

XDR is really more similar to struct or marshal, I think, but on the
other hand it is an Internet RFC (#1014).   Not sure where it should go...

> \input{libsomeos}   % Optional Operating System Services
> \input{libselect}
> \input{libthread}
> \input{libthreading}
> \input{libdummythread}
> \input{libdummythreading}
> \input{libmmap}
> \input{libreadline}
> \input{librlcompleter}



> \input{libunix} % UNIX Specific Services
> \input{libposix}
> \input{libpwd}
> \input{libspwd}
> \input{libgrp}
> \input{libcrypt}
> \input{libdl}
> \input{libtermios}
> \input{libtty}
> \input{libpty}
> \input{libfcntl}
> \input{libpipes}
> \input{libposixfile}
> \input{libresource}
> \input{libnis}
> \input{libsyslog}
> \input{libcommands}
> 

> \input{internet}% Internet Protocols

I wonder if the Internet chapter should be split into "HTTP/Web Tools"
(webbrowser, cgi, cgitb, httplib, urllib) and "Non-Web Protocols"
(ftplib, gopherlib, smtp, all the rest).

> \input{distutils}

Distutils should probably be in Program Frameworks.  Or it could just
have a chapter of its own, or maybe there are enough modules for an
"Application Support" chapter.

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

Re: Documentation suggestions

[A.M. Kuchling]

On Wed, 07 Dec 2005 10:36:52 -0600, 
A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> of the seealso environment.  I'll talk to Fred about it and begin
> assembling a patch.

Patch #1376361: http://www.python.org/sf/1376361 .  I still need to talk
to Fred about this.

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

Re: Documentation suggestions

[A.M. Kuchling]

On Thu, 8 Dec 2005 18:17:59 +0100, 
Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> cool.  can you post a sample page somewhere?

It's not terribly interesting at the moment.  The generated LaTeX looks like 
this:

\seeurl{http://effbot.org/librarybook/zlib.htm}{The zlib module}

And that gets formatted like other URL links.

BThe associated text currently isn't very helpful, but I'm not sure how
to make it better.  Maybe it could be "'', from ''
by ".  Then the text for your file would be "'The zlib module', 
from '(the eff-bot guide to) The Standard Python Library' by Fredrik Lundh."

Can I safely treat the dc:identifier field as the URL for the work as
a whole?  Then I could turn the book title into a hyperlink.

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

Re: PyCon Preliminary Program Announced!

[A.M. Kuchling]

On Thu, 20 Jan 2005 22:52:13 -0500, 
Tim Peters <[EMAIL PROTECTED]> wrote:
> The web page needs better formatting.  In general, there are no more

Suggestions for improvement are welcome.  Perhaps the Wiki version of 
the schedule, at http://www.python.org/moin/PyConDC2005/Schedule,
may be better.

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

Re: What YAML engine do you use?

[A.M. Kuchling]

On Fri, 21 Jan 2005 18:30:47 +0100, 
rm <[EMAIL PROTECTED]> wrote:
> Nowadays, people are trying to create binary XML, XML databases, 
> graphics in XML (btw, I'm quite impressed by SVG), you have XSLT, you 
> have XSL-FO, ... .

Which is an argument in favor of XML -- it's where the activity is, so it's
quite likely you'll encounter the need to know XML. Few projects use YAML,
so the chance of having to know its syntactic details is small.  

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

Re: What YAML engine do you use?

[A.M. Kuchling]

On Fri, 21 Jan 2005 18:54:50 +0100, 
Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> judging from http://yaml.org/spec/current.html (750k), the YAML designers are
> clearly insane.  that's the most absurd software specification I've ever 
> seen.  they
> need help, not users.

IMHO that's a bit extreme.  Specifications are written to be detailed, so
consequently they're torture to read.  Seen the ReStructured Text spec
lately?

The basic idea -- a data dumping format that's human-readable -- isn't a bad
one.  OTOH, I can't recall wanting such a thing -- when I want readable
output I'm happy using
unreadable pickle files, unpickling the object and calling a .dump() or
.as_text() method.)

But YAML seems to have started out with the goal of being human-writable,
something you would write in Emacs, and that seems to have gotten lost; the
format is now just as complicated as Restructured Text, but more cryptic
(the URI namespacing for tags, for example), not really simpler than
XML and in some ways weaker (e.g. only two encodings supported, more
complicated escaping rules).

For a pure Python application, I can't see a need for YAML; use
pickle/cPickle instead, because they're already there.  Exchanging
serialized objects between Python/Perl/Ruby scripts might be a good use case
for YAML, but XML has wider software support and S-expressions are simpler,
so my inclination would be to use them instead of YAML.

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

Re: rotor replacement

[A.M. Kuchling]

On 22 Jan 2005 04:50:30 -0800, 
Paul Rubin  wrote:
> Martin, do you know more about this?  I remember being disappointed
> about the decisions since I had done some work on a new block cipher

It was discussed in this thread:
http://mail.python.org/pipermail/python-dev/2003-April/034959.html

Guido and M.-A. Lemburg were leaning against including crypto; everyone else
was positive.  But Guido's the BDFL, so I interpreted his vote as being the
critical one.

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

Re: how to write a tutorial

[A.M. Kuchling]

On Wed, 2 Feb 2005 12:22:24 -0500, 
Dan Perl <[EMAIL PROTECTED]> quoted:
> "Xah Lee" <[EMAIL PROTECTED]> wrote in message 
>> I suggest it be dropped in both places. The mentioning of this book in
>> the Perl/Python community is mostly a fawning behavior and confession
>> that the author is among "in the know". This book and its mentioning is
>> a cultish behavior among OpenSource morons.

Not to mention that the reference to the book in the regex howto is hardly 
"fawning":

  The most complete book on regular expressions is almost certainly
  Jeffrey Friedl's Mastering Regular Expressions, published by
  O'Reilly. Unfortunately, it exclusively concentrates on Perl and
  Java's flavours of regular expressions, and doesn't contain any
  Python material at all, so it won't be useful as a reference for
  programming in Python. (The first edition covered Python's
  now-obsolete regex module, which won't help you much.) Consider
  checking it out from your library.

(I like how Lee extols Python, but also says its documentation was written 
by "opensource morons".  Honestly, you couldn't pay for this much
entertainment.)

--amk


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

Reminder: bug day on Saturday the 25th

[A.M. Kuchling]

The Python bug day is coming up tomorrow, Saturday June 25th, running from
1PM to 7PM UTC (9AM to 3PM Eastern).  Stop by the IRC channel (#python-dev
on irc.freenode.net) and join in!  For more info, see
.

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

Re: When someone from Britain speaks, Americans hear a "British accent"...

[A.M. Kuchling]

On Wed, 29 Jun 2005 03:14:26 -, 
Grant Edwards <[EMAIL PROTECTED]> wrote:
>> cool because you have to bet a lot of money. Anyway, if you
>> insist on making distinctions between the backwoods of
>> apalachia and european aristocracy,
>
> What, you think they sound the same?

I think that backwoods American speech is more archaic, and therefore is
possibly closer to historical European speech.  Susan Cooper uses this as a
minor plot point in her juvenile novel "King of Shadows", which is about a
20th-century Southern kid who goes back to Elizabethan times and ends up
acting with Shakespeare; his accent ensures that he doesn't sound *too*
strange in 16th-century London.

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

Accepted Summer of Code proposals

[A.M. Kuchling]

For anyone who's interested: the Python wiki now contains a list of the
PSF-mentored proposals that were accepted for Google's Summer of Code:
http://wiki.python.org/moin/SummerOfCode

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

Re: Accepted Summer of Code proposals

[A.M. Kuchling]

On Fri, 1 Jul 2005 14:22:51 -0400, 
Terry Reedy <[EMAIL PROTECTED]> wrote:
> Thanks for posting this and thanks for coordinating the PSF effort. 

I did little beyond writing up that wiki page.  David Ascher 
has been the primary coordinator for the PSF.

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

Re: Python -- (just) a successful experiment?

[A.M. Kuchling]

On Mon, 08 Aug 2005 16:58:40 GMT, 
Bengt Richter <[EMAIL PROTECTED]> wrote:
> It occurs to me that we have the PEP process for core python, but no PEP 
> process
> for the python app/lib environment. What about starting a PEEP process
> (Python Environment Enhancement Proposals) modeled on PEPs, where those 
> motivated
> to formalize their pet projects or feature requests could collaborate to 
> create
> a spec to document and guide development?

The PEP process could be used for some of this. There are existing
informational PEPs that aren't connected to the core language, but just
specify some interface for the community's use:

 IR  216  Docstring Format
 IF  248  Python Database API Specification v1.0  
 IF  249  Python Database API Specification v2.0  
 I   333  Python Web Server Gateway Interface v1.0

Other PEPs describe how to modernize code (PEP 290) and hack the code (290,
339).  This is similar to RFCs: there are normative RFCs that actually
specify something, and informative RFCs that publish information about an
experimental protocol or system.

PEPs would be especially good for things like WSGI that are intended to be
supported by many different projects; it's less useful to document how a pet
project works.

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

Re: Pre-PEP Proposal: Codetags

[A.M. Kuchling]

On Thu, 11 Aug 2005 08:47:37 +0200, 
Martin v. Löwis <[EMAIL PROTECTED]> wrote:
> I think you somewhat misunderstood the purpose of the PEP process.
> This is meant primarily for enhancements to Python (the language
> and its library), ...

PEP 0 disagrees:

 PEP stands for Python Enhancement Proposal.  A PEP is a design
 document providing information to the Python community, or describing
 a new feature for Python.  The PEP should provide a concise technical
 specification of the feature and a rationale for the feature.

 ...
 
 There are two kinds of PEPs.  A Standards Track PEP describes a new
 feature or implementation for Python.  An Informational PEP describes
 a Python design issue, or provides general guidelines or information
 to the Python community, but does not propose a new feature.

Most of PEP 0 is concerned with describing the workflow for Standards Track
PEPs, of course, but I guess there's not much to say for informational PEPs.
("Publish your PEP.  Eventually, freeze the PEP and stop making changes to it."
would be about the sum of it.)

I think we need to encourage writing detailed specifications of interfaces
for the community's use, such as the WSGI interface (PEP 333, IIRC), so
using the PEP repository for this purpose is a good idea.  If such things
are deemed off-topic for PEPs, then I think we should have a separate set of
documents for this (perhaps the suggested PEEPS: Python Environment
Enhancement Proposals).  

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

Re: Database of non standard library modules...

[A.M. Kuchling]

On Fri, 19 Aug 2005 10:33:16 +0100, 
Steve Holden <[EMAIL PROTECTED]> wrote:
> While cheeseshop might resonate with the Monty Python fans I have to say 
> I think the name sucks in terms of explaining what to expect. If I ask 
> someone where I can find a piece of code and the direct me to the cheese 
> shop, I might look for another language.

Point them at the Python Package Index: ,
which is just proxying for cheeseshop.python.org.

Many names were brought up (I think all this discussion was on the catalog
SIG), but none of them was widely liked.  So Richard Jones, the maintainer,
got to choose.

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

Re: Sanitizing untrusted code for eval()

[A.M. Kuchling]

On Mon, 22 Aug 2005 13:55:45 GMT, 
Jim Washington <[EMAIL PROTECTED]> wrote:
> I'm still working on yet another parser for JSON (http://json.org).  

See http://python.ca/nas/log/200507/index.html#21_001 for another parser. I
don't know if it uses eval() or not, but would bet on "not" because Neil is
pretty security-conscious.

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

Re: OpenSource documentation problems

[A.M. Kuchling]

On Wed, 31 Aug 2005 12:14:35 GMT, 
> I use dir() all the time; help() not so much. Typing help(help)
> shows:
>
>  Help on _Helper in module site:
>
>  Type help() for interactive help, or help(object) for help
>  about object.
>
> That strikes me as not-particularly-helpful. Surely it should at
> least direct the user to 'pydoc.help'.

help *is* pydoc.help, or at least a trivial wrapper around it, so I don't
see the purpose of mentioning that.  The purpose of the wrapper is so naive
user can just type 'help' at an interpreter prompt:

>>> help
Type help() for interactive help, or help(object) for help about object.
>>>

What additions to that string would you suggest?

> Three weeks ago, in trying to explain a point about Python's
> zlib module, I discovered that the doc was wrong.
> http://groups.google.com/group/comp.lang.python/msg/20609fff71a2ed02

I don't think I'd change the Python docs to try to explain this, because I
have no confidence that we can get the details correct. BerkeleyDB, curses,
and the 'os' module pose similar problems.  For example, people sometimes
ask for more detail about POSIX functions, but no one wants to write a
Python-specific version of "Advanced Programming in the Unix Environment".  

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

Re: OpenSource documentation problems

[A.M. Kuchling]

On 1 Sep 2005 05:04:33 -0700, 
Paul Boddie <[EMAIL PROTECTED]> wrote:
> Please note that I'm not labelling you as a troll.

No, he's simply barking mad.  I was amused by a rec.arts.sf.written 
discussion [1] where Lee complains that Jonathan Swift (1667-1745)'s writing
was unclear in style; apparently he's not aware that conventions and styles
change over time.

--amk

[1] http://groups.google.com/group/alt.usage.english/msg/0ec9871395fc90d3
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: OpenSource documentation problems

[A.M. Kuchling]

On Wed, 31 Aug 2005 19:57:00 GMT, 
Bryan Olson <[EMAIL PROTECTED]> wrote:
> Since "help *is* pydoc.help, or at least...", the call could
> show the same thing as help(pydoc.help), or at least inform the
> user that more of the story is available from help(pydoc.help).

But, given that the help message encourages the user to type help(), I don't
think this odd corner case matters very much.

> How about to fix the error?

That's now done; I've struck the sentence from the CVS version, and pointed
readers toward the zlib manual.

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

Re: OpenSource documentation problems

[A.M. Kuchling]

On Thu, 1 Sep 2005 17:09:27 +0200, 
Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> the useredit approach I'm using over at the librarybook site works
> pretty well.  for example, if you go to

That looks pleasantly simple.

I don't consider the pydoc.amk.ca experiment to have been really successful.
It was a half-hour hack that's usable with some pain, but the JavaScript and
frame display needs quite a bit of polishing to be usable by a random
newbie.

There's a Firefox extension (http://www.wikalong.org/) that allows wiki
annotation, but a browser-specific annotation tool doesn't solve the general
problem.

I suspect the best solution is something Python-doc-specific that runs the
generated HTML for the docs through a preprocessor that inserts comments and
an editing form.  It would be a great topic for a user group sprint or
weekend project.

(If someone volunteers to do this: if you decide to use an RDBMS, please use
PostgreSQL, because it's already installed on one of the python.org
servers.)

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

Re: OpenSource documentation problems

[A.M. Kuchling]

On Fri, 02 Sep 2005 06:19:16 GMT, 
Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:
>   My attempts at simple came in closer to the life insurance than
> Lincoln -- forget about Hemingway; the only way I could approach his
> writing was to stick to: Hello World; Good day; See you later; Bye.

A quote I like:

  I like long and unusual words, and anybody who does not share my tastes is
  not compelled to read me. Policemen and politicians are under some
  obligation to make themselves comprehensible to the intellectually
  stunted, but not I. Let my prose be tenebrous and rebarbative; let my
  pennyworth of thought be muffled in gorgeous habilements; lovers of Basic
  English will look to me in vain. 
-- Robertson Davies, _Marchbanks' Garland_

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

Re: OpenSource documentation problems

[A.M. Kuchling]

On Thu, 1 Sep 2005 23:08:18 -0400, 
Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
> Ideally, emails to docs at python.org would result in issues being created 
> somewhere, simply so they don't get lost.  It probably doesn't make sense for 
> those to land in SourceForge automatically, since then everyone has to read 
> every plea for a printable version of the documents.

As a stop-gap, could we encourage people to record issues on a wiki page?
Then someone could periodically look at the page and act on the suggestions
there.

The problem is that Wikis aren't really newbie-friendly, either; while you
don't need to register for the Python wiki any more, many people don't
realize the pages are editable.  Still, it might be worth a try.

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

Re: OpenSource documentation problems

[A.M. Kuchling]

On Fri, 2 Sep 2005 01:28:22 -0500, 
Terry Hancock <[EMAIL PROTECTED]> wrote:
> Hmm. Still sounds like "there ought to be a wiki".  I've seen references
> to two different ones on this thread. One was then debunked as a "failed
> experiment".  The other just gave me a DNS lookup failure (maybe the
> URL was wrong).

The Python wiki is at ; I didn't see the
earlier posting and don't know if it gave the right URL or not.

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

Re: Why do Pythoneers reinvent the wheel?

[A.M. Kuchling]

On Sat, 10 Sep 2005 08:53:24 +0200, 
Stefano Masini <[EMAIL PROTECTED]> wrote:
> Well, so we might as well learn a little more and rewrite os.path, the
> time module and pickle. Right? :)

And in fact people have done all of these:
os.path: path.py (http://www.jorendorff.com/articles/python/path/)
time: mxDateTime, the stdlib's datetime.
pickle: XML serialization, YAML.

> So, let's talk about a way to more effectively present available
> solutions to our good programmers! :)

PEP 206 (http://www.python.org/peps/pep-0206.html) suggests assembling an
advanced library for particular problem domains (e.g. web programming, 
scientific programming), and then providing a script that pulls the relevant
packages off PyPI.  I'd like to hear suggestions of application domains and
of the packages that should be included.

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

Re: Why do Pythoneers reinvent the wheel?

[A.M. Kuchling]

On Sat, 10 Sep 2005 12:35:37 -0400, 
Mike Meyer <[EMAIL PROTECTED]> wrote:
> I think the manual does need a section on how to find code other than
> the library. But where do you put it?

The tutorial's final section (http://docs.python.org/tut/node14.html) 
mentions PyPI.  A link to the ASPN cookbook should also be added; anything
else that should go in this section of the tutorial?

Similar text could be added to the introductory section of the library
reference, but I doubt that many users would see it because people probably
dive into the LibRef for a particular module instead of reading it straight
through.

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

Zeroconf article

[A.M. Kuchling]

I've written a little introductory article on using the Zeroconf protocol
with Python.  Zeroconf allows servers running on one machine to publish
their existence to other machines on the local network; applications can 
then locate available servers.

The article is:
http://www.amk.ca/python/zeroconf

(Some people will have already seen this article on my weblog or on the
daily Python-URL.  The only change is that a new release of PyZeroconf has
been made, and the text has been updated to mention this.)

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

Re: PyZeroConf Question

[A.M. Kuchling]

On Thu, 17 Mar 2005 14:48:03 -0800, 
djw <[EMAIL PROTECTED]> wrote:
> The list of printers is returned, but every call to getServiceInfo() in 
> the Listener objectresults in a timeout and None being returned.

I suggest compiling Apple's mDNSMonitor and looking at the sequence of
packets.  It seems that some Zeroconf services don't respond to the
.getServiceInfo() calls; maybe that's what's happening here.

> Also, at the end of the list, the code seems to hang.

That makes sense.  The threads that monitor Zeroconf aren't marked as
daemonic, so as long as they're running the main thread doesn't exist.  I've
hacked my copy of zeroconf.py to mark the threads as daemonic.

--amk

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

Re: collaborative editing

[A.M. Kuchling]

On 10 Dec 2004 05:20:42 -0800, 
Michele Simionato <[EMAIL PROTECTED]> wrote:
> welcome. Does something like that already exists? Alternatively, I would need
> some hierarchical Wiki with the ability of printing its contents in an
> structured way. 

At least one book, Eric van der Vlist's RELAX NG book, was written using a
Wiki; see http://books.xmlschemata.org/relaxng/pr01s05.html/ .

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

Re: Boo who? (was Re: newbie question)

[A.M. Kuchling]

On Tue, 21 Dec 2004 08:22:51 -0800, 
Roger Binns <[EMAIL PROTECTED]> wrote:
> That work died due to "a crisis of faith":
>   http://mylist.net/archives/spry-dev/2004-November/72.html

 Soon it will be possible to become a well-known programmer
without writing any code at all; just issue grandiose manifestos and plans
until everyone is suitably impressed.  

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

Re: PyPI errors?

[A.M. Kuchling]

On Mon, 21 Mar 2005 04:24:16 + (UTC), 
Daniel Yoo <[EMAIL PROTECTED]> wrote:
> Does anyone know why PyPI's doesn't like my PKG-INFO file?  Here's
> what I have:

The PyPI code is being modified at the PyCon sprints; clearly this is a bug 
that was introduced yesterday.  I expect it'll get fixed today.

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

Re: Documentation suggestions

[A.M. Kuchling]

On Sat, 10 Dec 2005 11:45:12 +0100, 
Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>> to make it better.  Maybe it could be "'', from ''
>> by ".  Then the text for your file would be "'The zlib module',
>> from '(the eff-bot guide to) The Standard Python Library' by Fredrik Lundh."
> 
> that should work.

Now implemented in SVN.

> the DC documentation is a bit convoluted, but if I understand things
> correctly, the dc:identifier field should, by default, contain an URI.

That's what I assumed.  You could theoretically supply something like
urn:isbn:1234567890, but then what are you linking to?  I implemented
your suggested check.

I've written Fred Drake about this, but haven't received a reply yet.
Fred is in the same area as me, so I'm hoping we can talk about
various doc things over coffee (example links being one of them).

--amk

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

Re: Documentation suggestions

[A.M. Kuchling]

On 8 Dec 2005 08:00:25 -0800, 
BartlebyScrivener <[EMAIL PROTECTED]> wrote:
> The bulleted points in BeginnersGuide/Overview are, again, things that
> are important to programmers ("Automatic garbage collection frees you
> from the hassles of memory management" means nothing to me, even now
> after reading a Python book and several tutorials).

I've reworked Overview to use more straightforward language, and to
break out the programming-language features into a separate list.
Maybe that will help.

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

Re: Which Python web framework is most like Ruby on Rails?

[A.M. Kuchling]

On Thu, 15 Dec 2005 20:15:17 -0800, 
Alex Martelli <[EMAIL PROTECTED]> wrote:
> If you claim there's a web project that's unfeasible to do in Ruby,
> you'd better come up with a strong example.  If you're making no such
> claim, which would be counter to the claims of the Ruby community, then
> there aren't gonna be any web projects unfeasible with Rails, either.

I believe Rails assumes you're using a relational database, not an
object database like Durus or the ZODB.  It seems to me Django is
similarly focused; are there hooks that would allow replacing an RDBMS
commit with a custom commit callback?

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

Re: Which Python web framework is most like Ruby on Rails?

[A.M. Kuchling]

On 20 Dec 2005 15:05:15 -0800, 
Michael Tobis <[EMAIL PROTECTED]> wrote:
> Python people don't really think that way. As a community we really
> seem to inherit the open source dysfunction of trying harder to impress
> each other than to reach out to the rest of the world. The problem is

Yes; I've long worried about this, but have no idea how to fix the
problem.  Python users largely talk to other Python users, not to the
world at large.

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

Re: Which Python web framework is most like Ruby on Rails?

[A.M. Kuchling]

On Thu, 22 Dec 2005 14:05:08 +, 
Ed Singleton <[EMAIL PROTECTED]> wrote:
>> Yes; I've long worried about this, but have no idea how to fix the
>> problem.  Python users largely talk to other Python users, not to the
>> world at large.
> 
> A good start would be for there to be a way for newbies to get heard
> more easily.

I don't see the connection between "Python users talk too much to
other Python users" and "newbies don't get heard".

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

Re: OT: Degrees as barriers to entry [was Re: - E04 - Leadership! Google, Guido van Rossum, PSF]

[A.M. Kuchling]

On Tue, 10 Jan 2006 23:13:01 +, 
Steve Holden <[EMAIL PROTECTED]> wrote:
> attempt to draw direct comparisons. Maybe having an uncle helped you in 
> to the trade, but it didn't cut you much slack in terms of required 
> standards, hence the absence of cathedral-shaped heaps of rubble. York 
> Minster was built in the 1400s, for example, and doesn't look like 
> falling down any time soon.

Googling for "cathedral collapse" finds an interesting page at
:

... As a matter of structural fact there is almost no argument
possible. The decay sensed by the eye after about 1250 stems
from a slow relaxation of the firm structural grasp that had
been acquired during the preceding hundred years.

...

Beauvais seems to have been particularly unfortunate. The apse
and choir were started in 1247, and finished in 1272. On 29
November 1284 the vault fell... Whatever the actual reason, it
was certainly believed at the time that the pier spacing was
too large, and the repairs over the next 50 years included the
intercalation of piers between these originally built for the
choir, so that the bays were halved from about 9m to about
4.5m. ...

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

Re: New Python.org website ?

[A.M. Kuchling]

On Thu, 19 Jan 2006 18:34:21 +0100, 
Gerhard Häring <[EMAIL PROTECTED]> wrote:
> If I see this correctly, Fredrik would volonteer to (help) implement 
> something that imports the current python.org content into a Wiki.

First question I have: which wiki?  Does this go into the existing
Python wiki, or into a fresh new wiki that contains *only*
Python.org-destined content?

Second question: how do we maintain the sidebar links in a wiki?
(i.e. the list of links in the blue sidebar on the existing
www.python.org).  These links vary from directory to directory on the
site.  In the file-based system, there's a file in every directory
that lists the links, and an individual .ht file can supply its own
list of links that's added in on top of the directory-wide links.  One
minor refinement: the link to the current page is greyed out in the
sidebar.

Are there existing Wiki-based sites that do this sort of sidebar
thing?

> MoinMoin 1.5 sounds perfect for the wiki. It supports ReST if we want 
> that, and now also a JavaScript-GUI based WYSIWYG editor.

Ah... sounds like it's time to upgrade the wiki software on python.org.

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

Re: New Python.org website ?

[A.M. Kuchling]

On Thu, 19 Jan 2006 19:20:37 +0100, 
Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> I'd prefer a separate wiki (at least initially).  Do we have enough
> admin resources to set up an 1.5 instance ?

I doubt it's practical to run 1.3 alongside 1.5.  python.org uses
mod_python, so unless the MoinMoin developers changed their software's
package name from 'MoinMoin' to something version specific like
'MoinMoin15', I think the Apache processes would get confused.  

Easier just to upgrade all the existing Wikis to 1.5, I think.  I'll
raise a flag about this; maybe it can get done over the weekend.

>> Second question: how do we maintain the sidebar links in a wiki?
>> (i.e. the list of links in the blue sidebar on the existing
>> www.python.org).  These links vary from directory to directory on the
>> site.  In the file-based system, there's a file in every directory
>> that lists the links, and an individual .ht file can supply its own
>> list of links that's added in on top of the directory-wide links.  One
>> minor refinement: the link to the current page is greyed out in the
>> sidebar.
> 
> The renderer/template engine can deal with that.

Um... yeah, but how?  We can group pages into folders ('Doc/whatever',
'SuccessStories/Whatever'), and then say it'll retrieve 'Doc/Sidebar'
for the sidebar.  But how could a particular page add more stuff to
the sidebar?  Maybe some kind of '#sidebar-links' directive that pulls
in a third wiki page, or maybe a separate page that associates page
titles with sidebars.

--amk



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

Re: EuroPython 2006 and Py3.0

[A.M. Kuchling]

On Fri, 14 Jul 2006 18:45:07 +0200, 
Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> 
>> This attitude may have some downsides. The Python developers don't know
>> everything, other people can have some experience of computer languages
>> too.
> 
> "some experience of computer languages" != "experience of language 
> design and implementation"
> 
> as long as most of the traffic on py3k is bikeshed stuff and hyper- 
> generalizations, most people who do hard stuff will spend their time 
> elsewhere.

Paul Prescod once wrote in c.l.py:

  If Python strays into trying to be something completely new it will
  fail, like Scheme, K and Smalltalk. There are both technical and
  sociological reasons for this. If you stray too far technically, you
  make mistakes: either you make modelling mistakes because you don't
  have an underlying logical model (i.e. C++ inheritance) or you make
  interface mistakes because you don't understand how your new paradigm
  will be used by real programmers.

  Let research languages innovate. Python integrates.

If Python 3000 turns into a let's-try-all-sorts-of-goofy-new-ideas
language, at least some of those ideas will turn out to have been
mistakes, and then we'll need a Python 3000++ to clean things up.

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

Re: Python to use a non open source bug tracker?

[A.M. Kuchling]

On 04 Oct 2006 06:44:24 -0700, 
Paul Rubin <> wrote:
> Right now there is not even agreement on what the goal is.  

The goal is a new tracker for python.org that the developers like
better; the original call lists 3 reasons (bad interface; lack of
reliability; lack of workflow controls).

> The surprise people are expressing is because they thought one of the
> goals of a big open source project would be to avoid reliance on
> closed tools.

I don't think Python has ever had this as a goal.  Python's license
lets it be embedded in closed-source products; Windows binaries are
built using closed-source tools (MS Visual C), and on some platforms
we use a closed-source system compiler; python.org used to be a
Solaris box, and now uses SourceForge which runs on top of DB/2...

IMHO, using Jira presents risks that are manageable:

* A data export is available if we decide to switch.  Writing a script to
  take this export and convert to a new tracker is non-trivial, but the 
  same is true of any other tracker we might choose; switching from 
  Roundup to Trac or Trac to Launchpad is also going to require some
  effort.  Therefore, I don't think our data is locked-in any more 
  than any other tracker.

* The offer of hosting means this won't consume very much
  administrative time. Perhaps the hosting offered will be found to be
  unreliable.  If that's the case, we can reconsider the choice of
  tracker, or (less likely) host Jira ourselves.

* There are no Bitkeeper-like licensing issues like the non-compete
  clause, so that isn't a factor; Roundup and Trac developers can file
  bugs and use the tracker just like anyone else.

* The interface is very flexible and lots of customization can be done
  through the web.  This means we don't have to hack the code at all,
  and upgrades should theoretically go smoothly.

It would be nice to have the additional tick-box feature 'is open
source', but the upsides are large enough that I can let go of 
that issue with only slight regret.

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