🌐 Mailman 3 August 2004 - Python-list - python.org

building python extensions for windows : python23_d.lib file is missing
by Antoine Maillard Aug. 2, 2004

Aug. 2, 2004

Hi We're looking to make our own python modules for windows Python 23. We use swig and Visual Studio C++ for making the dlls. But when trying to compile, it says it's been missing a "Python23_d.lib" file. According to the tutorial we did (http://www.geocities.com/foetsch/python/extending_python.htm#abstract), it's a problem with the fact we use the release version of python and not a débug version. But we don't know how to go through this (perhaps recompiling a debug version ... but we don't know how to do). Did someone get this problem and walk throug it ? Thanks for your help Antoine Maillard & André Garenne

2 1

Re: transforming a list into a string
by Christopher T King Aug. 2, 2004

Aug. 2, 2004

On Sat, 31 Jul 2004, Tim Peters wrote: > Absolutely. Note that Peter Otten previously posted a lovely O(N) > solution in this thread, although it may be too clever for some > tastes: > > >>> from itertools import izip > >>> items = ['1','2','7','8','12','13'] > >>> it = iter(items) > >>> ",".join(["{%s,%s}" % i for i in izip(it, it)]) > '{1,2},{7,8},{12,13}' > >>> A bit too clever for mine, mostly because neither izip() nor zip() is guaranteed to process its arguments in a left-to-right order (although there's no reason for them not to). I'd rather do this: >>> from itertools import izip, islice >>> items = ['1','2','7','8','12','13'] >>> it1 = islice(items,0,None,2) >>> it2 = islice(items,1,None,2) >>> ",".join(["{%s,%s}" % i for i in izip(it1, it2)]) '{1,2},{7,8},{12,13}' Although it doesn't improve efficiency any (or have that 'slick' feel), it does prevent needless head-scratching :) Curious, why isn't slicing of generators defined, using islice(), so "it1 = iter(items)[0::2]" is valid?

3 2

(patch for Bash) list comprehension and filtering
by William Park Aug. 2, 2004

Aug. 2, 2004

1. Here is shell version of Python filter() for array. Essentially, you apply a command on each array element, and extract only those elements which it returns success (0). This is specialized form of list comprehension where you can contruct an array from another array, using some sort of test or filtering. Usage is arrayfilter [-a var] command array where 'command' is a function, shell script, or external executable, which takes one argument (ie. the array elements). If 'command' return success (0), then print the element; and, if it fails (non-zero), then skip the element. If -a option is given, then the output will be save into array variable 'var', instead of default stdout. For example, a=(1 a 2 b 3 c) func () { [[ $1 == [a-z] ]]; } arrayfilter func a --> a b c arrayfilter -a b func a --> b[1]=a b[3]=b b[5]=c 2. More generally, here is shell version of Python list comprehension. Idea is to apply some test or command on each array element, and collect the outputs as parameter expansion. So, for each element of array variable 'var', ${var| command } will expand to the output of 'command' which takes one argument. If 'command' returns NULL, then that element is skipped. Usage is very similar to other parameter expansion, and both '*' and '@' work as expected. For example, a=(1 a 2 b 3 c) func () { [[ $1 == [a-z] ]] && echo ".$1."; } func x --> .x. ${a[*]| func } --> .a. .b. .d. Ref: http://freshmeat.net/projects/bashdiff/ http://home.eol.ca/~parkw/index.html#bash help arrayfilter help '${var|' -- William Park, Open Geometry Consulting, <opengeometry(a)yahoo.ca> Toronto, Ontario, Canada

1 0

(patch for Bash) try-block and exception
by William Park Aug. 2, 2004

Aug. 2, 2004

(crossposted to comp.lang.python, because this may be of interest to them.) Python has try-block, within which you can raise exception. Once it's raised, execution breaks out of the try-block and is caught at the end of try-block. Now, Bash has similiar feature. I've added try-block and 'raise' builtin into Bash-3.0. Typical usage would go something like try echo a raise echo b done or try echo a raise 2 echo b done in 0) echo okey ;; 1) echo raised 1 ;; 2) echo raised 2 ;; *) echo really bad ;; esac The exception is positive integer and is raised by 'raise' builtin, just like 'break' for the for/while/until loops. And, it can be caught by using optional case-like statement. Ref: http://freshmeat.net/projects/bashdiff/ help try help raise -- William Park, Open Geometry Consulting, <opengeometry(a)yahoo.ca> Toronto, Ontario, Canada

4 6

Recommendations for books on Python and XML
by enjoylife_95135＠hotmail.com Aug. 2, 2004

Aug. 2, 2004

Hi, I'm looking for recommendations for Python/XML books. Amazon.com had 2 relevant books, Python&XML by Christopher Jones (from O'Reilly) and XML processing with Python by Sean McGrath.The O'Reilly book seemed to have better reviews. But it concerns me that both books are rather old! Does anyone have any newer references? Otherwise does the relative age of the books (+3 years) really matter? About myself, I'm a C and Perl programmer from a while back. I'm learning Python and I want to get started with using it to manipulate XML. I don't know much about XML either, but I'm familiar with HTML. Thanks! S

5 6

Need Help Differentiating Bad Commands From Incomplete Commands
by timstanka＠bluefrog.com Aug. 2, 2004

Aug. 2, 2004

Thanks in advance for any responses. I have an application which embeds Python. I also have a command window for using Python interactively. The last piece I have left is to detect incomplete (ie "for x in range(10):") vs bad ("fer x in ronge(10):") input. Basically I read a line of input from my command window and feed it to PyRun_SimpleString(command). This command returns 0 on a good, complete command ("a = 10") but returns non-zero on bad and incomplete commands. I need to do something else to differentiate between the last two. I did find a section in the FAQ docs which gave some sample code: n = PyParser_ParseString(m_python_command, &_PyParser_Grammar,Py_file_input, &e); Problem is _PyParser_Grammar gives me an "unresolved external" error. I did some searching through the .h files and the actual source code and I could not find this symbol. I did some searching on the web and found a little snippit that indicated it was an extern which used to be defined in a .c file. The C-API manual doesn't list PyParser_ParseString() as a function. I'm thinking it might have been a wrapper for another function. Does anyone have a code snippit I could use for my purpose? Thanks, Tim

2 1

written improvement on ftplib.FTP(); relevant questions
by dbickett＠gmail.com Aug. 2, 2004

Aug. 2, 2004

in my inability to find a working ftp program for my mac, i decided to write one in python. i wrote a class (link at end of post) that inherited ftplib.FTP and made the process slightly less involved, but it brought up a few questions: using the sendcmd() method to do a simple "LIST" command returns an error explaining that a data connection could not be opened, just as if you connected to a ftp server using telnet. so, you use the method retrlines() with "LIST", and everything's fine. the whole module, in my opinion, seems like a piece of work. every method gives the appearance of a workaround. i get the impression it would be enormously easier to manipulate and comprehend if you simply wrote it on your own with sockets. so what i'm saying is i want to write my own ftp class, but i don't know how to handle the two seperate data/command sockets. i started to read the rfc, but i'm so sick of those things lately. if it isn't a simple explanation, could someone point me to an appropriate document, or the relevant page of the rfc, that will explain the process of the command connection versus the data connection in general programatic terms? I'd appreciate that. anyway, if anyone's interested, i'll link to the class i wrote. it uses a queue to store messages from the server and general program messages, with the intention of having a seperate thread to sit and interpret/output. in addition, the class is intentionally completely detached from the fate of the program, that way it could be more universal. with that in mind, when something fatal involving the connection has occured, it pushes a simple "exit" string to the queue -- one that could be changed to a numeric representation of an error message or whatever, to be "interpreted" so to speak. its right here: http://216.67.238.18/~bar/misc/BetterFTP.py Beeyah

1 0

RE: The term "Protocol"
by Robert Brewer Aug. 2, 2004

Aug. 2, 2004

Bruce Eckel wrote: > Sunday, August 1, 2004, 6:51:15 PM, Tim Peters wrote: > > > Iteration is a protocol, not a type. > > I know the term "protocol" has been used to describe a language > feature in a number of languages, but since we have no official > "protocol" support in Python I'm interested in what "we" mean by this > term. I'm going to guess that a protocol is like an interface in Java, > except that it doesn't have a concrete definition anywhere, but it is > implied through convention and use. Thus a protocol is a "latent > interface." Am I close? I'd like to understand this term better. In my (short) experience with the Python community, I've found that Pythonistas use the term "protocol" to mean a convention which is stated in the docs, as opposed to enforced via syntax. In the case of iter, your object either responds to those calls (__iter__ and next) or it does not--no inspection (or enforcement) of class or signature necessary. Note that this does *not* imply that a protocol "doesn't have a concrete definition". Python simply lands on the side of convention more often than many of what are called the "B&D" languages (which love to enforce convention in syntax), and technical terms like "protocol" naturally get bent to accomodate that. ;) Robert Brewer MIS Amor Ministries fumanchu(a)amor.org

1 0

Re: transforming a list into a string
by Christopher T King Aug. 2, 2004

Aug. 2, 2004

On Sun, 1 Aug 2004, Tim Peters wrote: > [Christopher T King] > > ... > > Curious, why isn't slicing of generators defined, using islice(), so "it1 > > = iter(items)[0::2]" is valid? > > If only some iterators implement it (like generator-iterators), then the > general interchangeability of iterable objects we enjoy today would be > damaged too. Ah, I see your point. But most functions that expect iterators use iter() on them first (to iterize sequences), do they not? So long as iter() supplies the necessary __getslice__ implementation, the world would be happy. This situation would mirror the situation with list(): though a user-defined sequence might not implement __getslice__ (and still be usable as a list), the object returned by list() is guaranteed to.

4 3

Re: transforming a list into a string
by Christopher T King Aug. 2, 2004

Aug. 2, 2004

On Sun, 1 Aug 2004, Tim Peters wrote: > The difference is that list() creates a concrete list object from its > argument, but there's no such thing as "a concrete iter object". You've got me there. > Iteration is a protocol, not a type. iter(obj) invokes > obj.__iter__(), Only if obj.__iter__() is defined; otherwise it makes something up using __getitem__ as appropriate. > and I don't know of any existing __iter__ implementation that returns an > object that supports slicing. True. Built-in classes (such as list & tupleiterator) would have to be extended with this function (trivial if they all subclass from a common base class). As to user classes, I'm proposing this on the assumption that a programmer would implement their own __getitem__ (I've been saying __getslice__ previously, __getitem__ is what I should be saying) if the functionality is so desired, which can be as trivial as setting __getitem__=islice, provided islice is extended to accept slice objects. Though, this would break __getitem__ in the case of getting a single item (I can see where this is heading)... > The only thing required of __iter__ is that it return an object that > supports the iteration protocol (meaning an object that supports next() > and __iter__() methods). So again, adding the ability to slice too > would mean requiring more of __iter__ methods -- or changing the > implementation of iter() to ignore __iter__ methods and make something > up itself. It's A Visible Change no matter how you cut it. You've made your point. I guess this will just have to go on the "it would be neat if it worked this way, but it just doesn't" list for now ;)

1 0