Re: Python To Send Emails Via Outlook Express
I wish I new why google doesn't show nicely aligned python code when you paste the script. Anyways, in case this helps someone else you can download the script from http://www.kirbyfooty.com/simplemapi.py Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: Python To Send Emails Via Outlook Express
Hi Lenard,
You just beat me to it.
Suprise, suprise, I discovered the answer myself this time.
I have modified the script to allow the attachment(s) to still be
passed as a string.
Some error checking is also done to verify the attachment file exists.
I have also modified it so it can be used for multiple email addresses.
Here is the updated working script ...
-
import os
from ctypes import *
FLAGS = c_ulong
LHANDLE = c_ulong
LPLHANDLE = POINTER(LHANDLE)
# Return codes
SUCCESS_SUCCESS = 0
# Recipient class
MAPI_ORIG = 0
MAPI_TO = 1
NULL = c_void_p(None)
class MapiRecipDesc(Structure):
_fields_ = [('ulReserved', c_ulong),
('ulRecipClass', c_ulong),
('lpszName', c_char_p),
('lpszAddress', c_char_p),
('ulEIDSize', c_ulong),
('lpEntryID', c_void_p),
]
lpMapiRecipDesc = POINTER(MapiRecipDesc)
class MapiFileDesc(Structure):
_fields_ = [('ulReserved', c_ulong),
('flFlags', c_ulong),
('nPosition', c_ulong),
('lpszPathName', c_char_p),
('lpszFileName', c_char_p),
('lpFileType', c_void_p),
]
lpMapiFileDesc = POINTER(MapiFileDesc)
class MapiMessage(Structure):
_fields_ = [('ulReserved', c_ulong),
('lpszSubject', c_char_p),
('lpszNoteText', c_char_p),
('lpszMessageType', c_char_p),
('lpszDateReceived', c_char_p),
('lpszConversationID', c_char_p),
('flFlags', FLAGS),
('lpOriginator', lpMapiRecipDesc), # ignored?
('nRecipCount', c_ulong),
('lpRecips', lpMapiRecipDesc),
('nFileCount', c_ulong),
('lpFiles', lpMapiFileDesc),
]
lpMapiMessage = POINTER(MapiMessage)
MAPI = windll.mapi32
MAPISendMail=MAPI.MAPISendMail
MAPISendMail.restype = c_ulong # Error code
MAPISendMail.argtypes = (LHANDLE, # lhSession
c_ulong, # ulUIParam
lpMapiMessage, # lpMessage
FLAGS, # lpFlags
c_ulong, # ulReserved
)
def SendMail(recipient, subject, body, attachfiles):
"""Post an e-mail message using Simple MAPI
recipient - string: address to send to (multiple address sperated
with a semicolin)
subject - string: subject header
body - string: message text
attach - string: files to attach (multiple attachments sperated
with a semicolin)
Example usage
import simplemapi
simplemapi.SendMail("[EMAIL PROTECTED];[EMAIL PROTECTED]","My
Subject","My message body","c:\attachment1.txt;c:\attchment2")
"""
# get list of file attachments
attach = []
AttachWork = attachfiles.split(';')
#verify the attachment file exists
for file in AttachWork:
if os.path.exists(file):
attach.append(file)
attach = map( os.path.abspath, attach )
nFileCount = len(attach)
if attach:
MapiFileDesc_A = MapiFileDesc * len(attach)
fda = MapiFileDesc_A()
for fd, fa in zip(fda, attach):
fd.ulReserved = 0
fd.flFlags = 0
fd.nPosition = -1
fd.lpszPathName = fa
fd.lpszFileName = None
fd.lpFileType = None
lpFiles = fda
else:
# No attachments
lpFiles = cast(NULL, lpMapiFileDesc) # Make NULL
# Get the number of recipients
RecipWork = recipient.split(';')
RecipCnt = len(RecipWork)
# Formulate the recipients
MapiRecipDesc_A = MapiRecipDesc * len(RecipWork)
rda = MapiRecipDesc_A()
for rd, ra in zip(rda, RecipWork):
rd.ulReserved = 0
rd.ulRecipClass = MAPI_TO
rd.lpszName = None
rd.lpszAddress = ra
rd.ulEIDSize = 0
rd.lpEntryID = None
recip = rda
# send the message
msg = MapiMessage(0, subject, body, None, None, None, 0,
cast(NULL, lpMapiRecipDesc), RecipCnt, recip,
nFileCount, lpFiles)
rc = MAPISendMail(0, 0, byref(msg), 0, 0)
if rc != SUCCESS_SUCCESS:
raise WindowsError, "MAPI error %i" % rc
---
--
http://mail.python.org/mailman/listinfo/python-list
Re: regular expression: perl ==> python
Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> the undocumented sre.Scanner provides a ready-made mechanism for this
> kind of RE matching; see
>
> http://aspn.activestate.com/ASPN/Mail/Message/python-dev/1614344
>
> for some discussion.
>
> here's (a slight variation of) the code example they're talking about:
>
> def s_ident(scanner, token): return token
> def s_operator(scanner, token): return "op%s" % token
> def s_float(scanner, token): return float(token)
> def s_int(scanner, token): return int(token)
>
> scanner = sre.Scanner([
> (r"[a-zA-Z_]\w*", s_ident),
> (r"\d+\.\d*", s_float),
> (r"\d+", s_int),
> (r"=|\+|-|\*|/", s_operator),
> (r"\s+", None),
> ])
>
> >>> print scanner.scan("sum = 3*foo + 312.50 + bar")
> (['sum', 'op=', 3, 'op*', 'foo', 'op+', 312.5, 'op+', 'bar'],
> '')
That is very cool - exactly the kind of problem I come across quite
often!
I've found the online documentation (using pydoc) for re / sre in
general to be a bit lacking.
For instance nowhere in
pydoc sre
Does it tell you what methods a match object has (or even what type it
is). To find this out you have to look at the HTML documentation.
This is probably what Windows people look at by default but Unix
hackers like me expect everything (or at least a hint) to be in the
man/pydoc pages.
Just noticed in pydoc2.4 a new section
MODULE DOCS
http://www.python.org/doc/current/lib/module-sre.html
Which is at least a hint that you are looking in the wrong place!
...however that page doesn't exist ;-)
--
Nick Craig-Wood <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick
--
http://mail.python.org/mailman/listinfo/python-list
[PIL] is there a downloadable docs for PIL
sometimes a have no internet access, but want to work :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python To Send Emails Via Outlook Express
[EMAIL PROTECTED] writes:
> Hello again,
> Thanks for the advice!
> Unfortunately I still cannot get it to send attachments.
> It comes up with the following windows error..
> (I have a feeling it has something to do with the file count)
>
> >>> import simplemapi
> >>> simplemapi.SendMail("[EMAIL PROTECTED]","The Subject","The
> body","c:\ian\ian.txt")
> nFileCount 14
> Traceback (most recent call last):
> File "", line 1, in ?
> File "simplemapi.py", line 111, in SendMail
> raise WindowsError, "MAPI error %i" % rc
> WindowsError: MAPI error 2
>
Two problems:
1) SendMail is looking for a list of attachment files.
2) SendMail wants the attachments to be in the current
working directory; that is what the:
attach = map( os.path.abspath, attach )
is about, right?
Try this:
import simplemapi
import os
os.chdir("c:\ian")
simplemapi.SendMail("[EMAIL PROTECTED]", "The Subject",
"The body", ["ian.txt"])
>
> This is the updated script..
>
> --
> import os
> from ctypes import *
>
> FLAGS = c_ulong
> LHANDLE = c_ulong
> LPLHANDLE = POINTER(LHANDLE)
>
>
> # Return codes
> SUCCESS_SUCCESS = 0
> # Recipient class
> MAPI_ORIG = 0
> MAPI_TO = 1
>
>
> NULL = c_void_p(None)
>
>
> class MapiRecipDesc(Structure):
> _fields_ = [('ulReserved', c_ulong),
> ('ulRecipClass', c_ulong),
> ('lpszName', c_char_p),
> ('lpszAddress', c_char_p),
> ('ulEIDSize', c_ulong),
> ('lpEntryID', c_void_p),
> ]
> lpMapiRecipDesc = POINTER(MapiRecipDesc)
>
>
> class MapiFileDesc(Structure):
> _fields_ = [('ulReserved', c_ulong),
> ('flFlags', c_ulong),
> ('nPosition', c_ulong),
> ('lpszPathName', c_char_p),
> ('lpszFileName', c_char_p),
> ('lpFileType', c_void_p),
> ]
> lpMapiFileDesc = POINTER(MapiFileDesc)
>
>
> class MapiMessage(Structure):
> _fields_ = [('ulReserved', c_ulong),
> ('lpszSubject', c_char_p),
> ('lpszNoteText', c_char_p),
> ('lpszMessageType', c_char_p),
> ('lpszDateReceived', c_char_p),
> ('lpszConversationID', c_char_p),
> ('flFlags', FLAGS),
> ('lpOriginator', lpMapiRecipDesc), # ignored?
> ('nRecipCount', c_ulong),
> ('lpRecips', lpMapiRecipDesc),
> ('nFileCount', c_ulong),
> ('lpFiles', lpMapiFileDesc),
> ]
> lpMapiMessage = POINTER(MapiMessage)
>
>
> MAPI = windll.mapi32
>
>
> MAPISendMail=MAPI.MAPISendMail
> MAPISendMail.restype = c_ulong # Error code
> MAPISendMail.argtypes = (LHANDLE, # lhSession
> c_ulong, # ulUIParam
> lpMapiMessage, # lpMessage
> FLAGS, # lpFlags
> c_ulong, # ulReserved
> )
>
>
> def SendMail(recipient, subject, body, attach=[]):
> """Post an e-mail message using Simple MAPI
>
>
> recipient - string: address to send to
> subject - string: subject header
> body - string: message text
> attach - string: files to attach
> """
> attach = map( os.path.abspath, attach )
> nFileCount = len(attach)
> if attach:
> MapiFileDesc_A = MapiFileDesc * len(attach)
> fda = MapiFileDesc_A()
> for fd, fa in zip(fda, attach):
> fd.ulReserved = 0
> fd.flFlags = 0
> fd.nPosition = -1
> fd.lpszPathName = fa
> fd.lpszFileName = None
> fd.lpFileType = None
> lpFiles = fda
> else:
> # No attachments
> lpFiles = cast(NULL, lpMapiFileDesc) # Make NULL
>
> print "nFileCount ",nFileCount
>
>
> recip = MapiRecipDesc(0, MAPI_TO, None, recipient, 0, None)
> #msg = MapiMessage(0, subject, body, None, None, None, 0,
> # cast(NULL, lpMapiRecipDesc), 1, pointer(recip),
> # nFileCount, cast(NULL, lpMapiFileDesc))
> msg = MapiMessage(0, subject, body, None, None, None, 0,
> cast(NULL, lpMapiRecipDesc), 1, pointer(recip),
> nFileCount, lpFiles)
>
>
> rc = MAPISendMail(0, 0, byref(msg), 0, 0)
> if rc != SUCCESS_SUCCESS:
> raise WindowsError, "MAPI error %i" % rc
>
> --
>
> Thanks again for your help so far on this. I really appreciate it!
> Have a safe and very merry Christmas.
>
And the same to you.
Lenard Lindstrom
<[EMAIL PROTECTED]>
--
http://mail.python.org/mailman/listinfo/python-list
Re: Koolaid (was Re: Optional Static Typing)
Peter Hansen <[EMAIL PROTECTED]> wrote: > > John Roth wrote: > > "Rocco Moretti" <[EMAIL PROTECTED]> wrote: > >> The question is, should Guido state "TDD is the one true way to > >> program in Python.", or should concessions be made in the language > >> design for those who don't "drink the TDD Kool-aide". > > > > Neither one. I hope you didn't mean that people > > who advocate TDD are suicidal fanatics, because > > that's exactly what "drink the kool-aid" means. > > I always thought the connotation was more that those who > "drank the Kool-Aid" were unthinking drones, following what > others told them to do. I thought it was an allusion to "The Electric Kool-Aid Acid test" by Tom Wolfe - see http://en.wikipedia.org/wiki/The_Electric_Kool_Aid_Acid_Test Tim C -- http://mail.python.org/mailman/listinfo/python-list
Re: Global variables and modules
Add these lines to test1.py and see what you get: import test2 print 'test2.glbl postinc ', test2.glbl This will work as you expect. Next try chaning glbl in test2 to a list (a mutable type). test2.py: glbl = [25] def inc_glbl(): global glbl glbl[0] = glbl[0] + 1 def get_glbl(): global glbl return glbl[0] test1.py: from test2 import glbl, inc_glbl, get_glbl print 'glbl orig ', glbl[0] inc_glbl() print 'glbl postinc ', glbl[0] new = get_glbl() print 'glbl from func ', new import test2 print 'test2.glbl postinc ', test2.glbl [EMAIL PROTECTED] kbinu]$ python2.2 test.py glbl orig 25 glbl postinc26 glbl from func 26 test2.glbl postinc[26] On 23 Dec 2004 21:43:40 -0800, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > I have a newby type question on how global variables work between > modules. > > I have a module test2.py that defines a global variable as well as two > functions to operate on that variable. A script test1.py imports the > three names and prints out values of the global between operations, and > the results aren't what I expected. > > Here is the module, test2.py > > glbl = 25 > > def inc_glbl(): > global glbl > glbl += 1 > > def get_glbl(): > global glbl > return glbl > > > and here is the test script, test1.py > - > > from test2 import glbl, inc_glbl, get_glbl > > print 'glbl orig ', glbl > > inc_glbl() > print 'glbl postinc ', glbl > > new = get_glbl() > print 'glbl from func ', new > -- > I would expect the three values to be ( 25, 26, 26 ), but what I get is > c:\projects\pitcher_model>test1.py > glbl orig 25 > glbl postinc25 > glbl from func 26 > > - > It seems that the references to 'glbl' are seeing a local copy, rather > than the original. This is not what the literature says should be > happening. I am looking for a way to share data between modules. Can > you advise me on my error? I am using Python 2.3.2 from ActiveState, > on Windows XP Pro. > > Thank you > David > > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: String backslash characters
PD wrote: > Hello, > > I am new to python, but i am quite curious about the following. > > suppose you had > > print '\378' > > which should not work because \377 is the max. then it displays two > characters (an 8 and a heart in my case...). What else does'nt quite > make sense is that if this is an octal why is an 8 accepted? Because 8 isn't an octal digit, so it's not part of the escape sequence, but a separate character. It's just like print 'This string\47s escape sequence does not include the s.' Your example displays two characters because it is two characters: '\037' and '8'. -- http://mail.python.org/mailman/listinfo/python-list
Global variables and modules
I have a newby type question on how global variables work between modules. I have a module test2.py that defines a global variable as well as two functions to operate on that variable. A script test1.py imports the three names and prints out values of the global between operations, and the results aren't what I expected. Here is the module, test2.py glbl = 25 def inc_glbl(): global glbl glbl += 1 def get_glbl(): global glbl return glbl and here is the test script, test1.py - from test2 import glbl, inc_glbl, get_glbl print 'glbl orig ', glbl inc_glbl() print 'glbl postinc ', glbl new = get_glbl() print 'glbl from func ', new -- I would expect the three values to be ( 25, 26, 26 ), but what I get is c:\projects\pitcher_model>test1.py glbl orig 25 glbl postinc25 glbl from func 26 - It seems that the references to 'glbl' are seeing a local copy, rather than the original. This is not what the literature says should be happening. I am looking for a way to share data between modules. Can you advise me on my error? I am using Python 2.3.2 from ActiveState, on Windows XP Pro. Thank you David -- http://mail.python.org/mailman/listinfo/python-list
Re: String backslash characters
PD wrote: I am new to python, but i am quite curious about the following. print '\378' which should not work because \377 is the max. then it displays two characters (an 8 and a heart in my case...). What else does'nt quite make sense is that if this is an octal why is an 8 accepted? It would appear that the parser reads \377 as a single character and \378 as two (\37 and the "8" character). I'm somewhat surprised you're seeing a heart and an 8. What OS/language combination are you using? If you're using English Windows you can get a heart and an "8" with "print '\38'". -- Benji York [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: String backslash characters
'\378' becomes a two character string. The first character is '\37' and the second character is '8'. >>> str = '\378' >>> str[0] '\x1f' >>> str[1] '8' >>> On 23 Dec 2004 20:53:13 -0800, PD <[EMAIL PROTECTED]> wrote: > Hello, > > I am new to python, but i am quite curious about the following. > > suppose you had > > print '\378' > > which should not work because \377 is the max. then it displays two > characters (an 8 and a heart in my case...). What else does'nt quite > make sense is that if this is an octal why is an 8 accepted? > > for instance is 378 really 11, 111, 1000 which is then the two > characters: <0001>,<000>. And why is this accepted? > > I apologize if this has been discussed or if it is obvious. I would > appreciate it if someone could clear me up. > > Yours, > PD > > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
String backslash characters
Hello, I am new to python, but i am quite curious about the following. suppose you had print '\378' which should not work because \377 is the max. then it displays two characters (an 8 and a heart in my case...). What else does'nt quite make sense is that if this is an octal why is an 8 accepted? for instance is 378 really 11, 111, 1000 which is then the two characters: <0001>,<000>. And why is this accepted? I apologize if this has been discussed or if it is obvious. I would appreciate it if someone could clear me up. Yours, PD -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows XP - cron or scheduler for Python?
Hi, I thought I'd throw in my 2 cents worth. I have written a freeware task scheduler that might be of interest to you. It's called Kirby Alarm And Task Scheduler. Over 16000 people around the world use it. Kirby Alarm will run a program, pop up a note, play a sound, or send an email at whatever intervals you like. Have a look at http://www.kirbyfooty.com/ or read what others have to say about it at http://www.download.com/Kirby-Alarm-And-Task-Scheduler/3000-2084_4-10260143.html?tag=stbc.gp To run a python script just put the following into the program name. (The quotes MUST be included wherever there are spaces in the command line) "C:\Python23\python.exe" "d:\mypython\Say Time.py" Have a great Christmas! God bless Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: Best GUI for small-scale accounting app?
Web browser "widgets" seem pretty limited to me, though. You don't even have something as simple as a combo box (i.e. an editable entry with a drop down), let alone the rich set of widgets something like wxwidgets offers. Also web development doesn't seem as coherent to me as development with a good GUI framework. I think it depends on your target audience. Many people love simplicity. wxPython has an HTML control that lets you do most of your UI web-like and just drop in the other wxWidgets kinds of controls here and there if you need to. The html control does most of the rendering and such, and you can do most of the user interaction with standard clickable links, etc, but you can also mix in the full boat of high-powered gizmos to perplex the users when you run out of other tactics and annoyances. Is it pretty? As a conglomerate with features of a desktop app and features of a browser-based app, it's kind of pretty like a platypus. Platypus, penguin, or python, there's many a way to lay an egg. Al -- http://mail.python.org/mailman/listinfo/python-list
converting octal strings to unicode
I have several ascii files that contain '\ooo' strings which represent
the octal value for a character. I want to convert these files to
unicode, and I came up with the following script. But it seems to me
that there must be a much simpler way to do it. Could someone more
experienced suggest some improvements?
I want to convert a file eg. containing:
hello \326du
with the unicode file containing:
hello Ödu
--8<---
#!/usr/bin/python
import re, string, sys
if len(sys.argv) > 1:
file = open(sys.argv[1],'r')
lines = file.readlines()
file.close()
else:
print "give a filename"
sys.exit()
def to_unichr(str):
oct = string.atoi(str.group(1),8)
return unichr(oct)
for line in lines:
line = string.rstrip(unicode(line,'Latin-1'))
if re.compile(r'\\\d\d\d').search(line):
line = re.sub(r'\\(\d\d\d)', to_unichr, line)
line = line.encode('utf-8')
print line
--8<---
--
http://mail.python.org/mailman/listinfo/python-list
RE: Lambda going out of fashion
Stephen Thorne wrote: > Lambdas contain only a single expression. Even the py3k > wiki page ignores this critical difference. A single expression > means no statements of any kind can be included. Assignment, > if/elif/else, while, for, try/except, etc are not catered > for in lambdas. That's been the only serious use case I've had for lambdas: a way to have an Expression object, in effect. If we had a more rigorous syntax specifically for first-class expressions, lambda could go away forever in my book. Robert Brewer MIS Amor Ministries [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
RE: Lambda going out of fashion
Nick Coghlan wrote: > ...rather than pushing to retain lambda for Py3K, it might > be more productive to find a better statement -> expression > translation for function definitions. Guido seems to prefer > named functions, so it would still be tough to gain his > acceptance. However, a more Pythonic syntax is the only way > I can see anonymous functions making into 3.0 > > The current best example of a statement->expression translation > is generator expressions: > > def squares(seq) >for x in seq: > yield x * x > > total = sum(squares(seq)) > > versus: > > total = sum(x * x for x in seq) > > If we consider a function definition (omitting decorators > and docstrings) we get: > > def foo(a, b, c): >return f(a) + o(b) - o(c) > > accepts_func(foo) > > What would a Pythonic 'function as expression' look like? Or simply: accepts_func( (f(a) + o(b) - o(c) for a, b, c) ) ...but that would give whomever writes the parser a headache. ;) Robert Brewer MIS Amor Ministries [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Guido & Optional Static Typing
Sorry... I just realized that somebody else already had started a thread on this... -- http://mail.python.org/mailman/listinfo/python-list
Guido & Optional Static Typing
Hi folks, This is an interesting new article (published today Dec. 23). Guido discusses the possibility of adding optional static typing to Python: http://www.artima.com/weblogs/viewpost.jsp?thread=85551 -- http://mail.python.org/mailman/listinfo/python-list
Python and Delphi
I'm curious about the long term trends chart on the TIOBE Programming Community Index chart at http://www.tiobe.com/tpci.htm. It shows the prevalence of Delphi and Python have tracked roughly equivalent usage paths for some years now. Does anyone know why, or is this just an interesting but insignificant anomaly? Kristofer Carlson -- http://mail.python.org/mailman/listinfo/python-list
Re: Python To Send Emails Via Outlook Express
Hello again,
Thanks for the advice!
Unfortunately I still cannot get it to send attachments.
It comes up with the following windows error..
(I have a feeling it has something to do with the file count)
>>> import simplemapi
>>> simplemapi.SendMail("[EMAIL PROTECTED]","The Subject","The
body","c:\ian\ian.txt")
nFileCount 14
Traceback (most recent call last):
File "", line 1, in ?
File "simplemapi.py", line 111, in SendMail
raise WindowsError, "MAPI error %i" % rc
WindowsError: MAPI error 2
This is the updated script..
--
import os
from ctypes import *
FLAGS = c_ulong
LHANDLE = c_ulong
LPLHANDLE = POINTER(LHANDLE)
# Return codes
SUCCESS_SUCCESS = 0
# Recipient class
MAPI_ORIG = 0
MAPI_TO = 1
NULL = c_void_p(None)
class MapiRecipDesc(Structure):
_fields_ = [('ulReserved', c_ulong),
('ulRecipClass', c_ulong),
('lpszName', c_char_p),
('lpszAddress', c_char_p),
('ulEIDSize', c_ulong),
('lpEntryID', c_void_p),
]
lpMapiRecipDesc = POINTER(MapiRecipDesc)
class MapiFileDesc(Structure):
_fields_ = [('ulReserved', c_ulong),
('flFlags', c_ulong),
('nPosition', c_ulong),
('lpszPathName', c_char_p),
('lpszFileName', c_char_p),
('lpFileType', c_void_p),
]
lpMapiFileDesc = POINTER(MapiFileDesc)
class MapiMessage(Structure):
_fields_ = [('ulReserved', c_ulong),
('lpszSubject', c_char_p),
('lpszNoteText', c_char_p),
('lpszMessageType', c_char_p),
('lpszDateReceived', c_char_p),
('lpszConversationID', c_char_p),
('flFlags', FLAGS),
('lpOriginator', lpMapiRecipDesc), # ignored?
('nRecipCount', c_ulong),
('lpRecips', lpMapiRecipDesc),
('nFileCount', c_ulong),
('lpFiles', lpMapiFileDesc),
]
lpMapiMessage = POINTER(MapiMessage)
MAPI = windll.mapi32
MAPISendMail=MAPI.MAPISendMail
MAPISendMail.restype = c_ulong # Error code
MAPISendMail.argtypes = (LHANDLE, # lhSession
c_ulong, # ulUIParam
lpMapiMessage, # lpMessage
FLAGS, # lpFlags
c_ulong, # ulReserved
)
def SendMail(recipient, subject, body, attach=[]):
"""Post an e-mail message using Simple MAPI
recipient - string: address to send to
subject - string: subject header
body - string: message text
attach - string: files to attach
"""
attach = map( os.path.abspath, attach )
nFileCount = len(attach)
if attach:
MapiFileDesc_A = MapiFileDesc * len(attach)
fda = MapiFileDesc_A()
for fd, fa in zip(fda, attach):
fd.ulReserved = 0
fd.flFlags = 0
fd.nPosition = -1
fd.lpszPathName = fa
fd.lpszFileName = None
fd.lpFileType = None
lpFiles = fda
else:
# No attachments
lpFiles = cast(NULL, lpMapiFileDesc) # Make NULL
print "nFileCount ",nFileCount
recip = MapiRecipDesc(0, MAPI_TO, None, recipient, 0, None)
#msg = MapiMessage(0, subject, body, None, None, None, 0,
# cast(NULL, lpMapiRecipDesc), 1, pointer(recip),
# nFileCount, cast(NULL, lpMapiFileDesc))
msg = MapiMessage(0, subject, body, None, None, None, 0,
cast(NULL, lpMapiRecipDesc), 1, pointer(recip),
nFileCount, lpFiles)
rc = MAPISendMail(0, 0, byref(msg), 0, 0)
if rc != SUCCESS_SUCCESS:
raise WindowsError, "MAPI error %i" % rc
--
Thanks again for your help so far on this. I really appreciate it!
Have a safe and very merry Christmas.
God bless!!
Ian
--
http://mail.python.org/mailman/listinfo/python-list
Re: Creating Image Maps
Hello Aaron, You need to check the demo that comes with wxPython if you don't have it get it. Look under wxHtmlWindow and click the demo tab then just scroll down and there is a link to it that says IMAGEMAP. Or in other words RTFD ;) M.E.Farmer -- http://mail.python.org/mailman/listinfo/python-list
Re: PHP vs. Python
"Stephen" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >I like the idea of being able to port specific sections to C ... Python > seems more flexible than PHP ... scalable. If you want portions of your code in C, then wrap them with Swig. That way they can be available in any number of languages including Python, PHP, Java and Perl. http://www.swig.org/compare.html Roger -- http://mail.python.org/mailman/listinfo/python-list
Re: sql server support from linux
> I considered doing exactly the same thing a while ago, but was worried > about running into an annoyance like that. FWIW, The synchronous Pyro server performed much faster than the multithreaded version, even under heavy use from 3 machines. It appeared that while the database queries were serialized, network IO was not. I infered this from the observation that a large result set would take around 15 seconds to complete, yet other smaller queries were able to run about 2-3 seconds after the large query was started. Sw. -- http://mail.python.org/mailman/listinfo/python-list
Creating Image Maps
I know this is a thing used primarily on websites..but since python can do anything ;) I'm trying to make a clickable image map for my wxPython program. Basically, I know how to organize the images into one large image in a panel, but how do I make the individual pieces clickable like webpage links(in wxPython)? The goal is to add an event handler that displays the image piece in a different panel, along with attributes. Which I could do if only I could make the pieces clickable Any ideas? Also, if you have any hard to find links on the general area I'm talking about, I'd like to learn as much as possible. -thanks -- http://mail.python.org/mailman/listinfo/python-list
Re: How about "pure virtual methods"?
Mike Meyer <[EMAIL PROTECTED]> wrote: > Noam Raphael <[EMAIL PROTECTED]> writes: > > > The answer is that a subclass is guaranteed to have the same > > *interface* as the base class. And that's what matters. > > This is false. For instance: > > class A(object): > def method(self, a): > print a > > class B(A): > def method(self, a, b): >print a, b > > B implements a different interface than A. Statically typed OO > languages either use multi-methods or disallow changing the signature > of an overridden method. > > A tool to detect such cases would probably be almost as useful as the > tool you've proposed. Agreed, and besides, the two tools can usefully be one. Look at the inspect module for signature checking helpers... Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: How about "pure virtual methods"?
Noam Raphael <[EMAIL PROTECTED]> wrote: > However, I'm not sure if this solves my practical problem - testing > whether all abstract methods were implemented. I think that usually, you > can't write a test which checks whether an abstract method did what it > should have, since different implementations do different things. I Still, there must be some _protocol_ about what those abstract methods are all about... otherwise you _are_ just talking about an *interface*, the way I use the terms (I didn't invent that usage, I just find it very useful in practice). An interface is "just syntax" -- method names and signatures; a protocol adds semantics and pragmatics (the distinction between the last two may only be meaningful to somebody with a background in linguistics, and it's not important here anyway). If some method is a hook which may do anything including nothing then it's most often more useful not to make it abstract (or absent) in the base class, but rather to define it there as a no-op. This way, you reduce the boilerplate in all subclasses: they only override the methods they NEED to override. Besides no-op, this could also apply to other semantics that were "a very likely possibility" -- but it's unusual for any given semantics to be "very likely", except "first, do no harm";-) When you design a protocol, _make it testable_. Say that you start with the idea of the protocol having two methods: def frambozzle(self): ''' must make the instance frambozzled ''' def unframbozzle(self): ''' must make the instance not-frambozzled ''' This protocol is not complete. Add a third method: def isframbozzled(self): ''' return a true value iff the instance is frambozzled ''' NOW you have a testable protocol! Sorry for the toy-ness of the example, but I don't want to post for hundreds of lines. Beyond the direct advantages of being able to write much better tests, experience teaches that a testable protocol tends to have extra resilience and usefulness for perfectly reasonable uses that the protocol designer might not have anticipated. E.g., with the testable protocol one can write def toggle_frambozzling(some_instance): if some_instance.isframbozzled(): some_instance.unframbozzle() else: some_instance.frambozzle() Note that we're only using semantics here, aka abstract semantics, not pragmatics (just to illuminate the semi-relevant distinction I was using above). Abstract semantics are those you can fully capture by axioms related to methods that are part of the protocol itself, without for example needing to refer to the external world, or other objects. You get pragmatics when such references are there, e.g., informal specs of the kind "the shipping costs of a frambozzled instance are expected to not exceed that of an unframbozzled instance, and normally to be below; on the other hand, frambozzled instances need only be marshalable on a single platform and version of Python and of this framework, while unframbozzled instances must ensure marshaling cross-platform on any version of Python >= 2.3.4 and version of this framework >= 0.8.2". In practice, only projects with relatively high formality tend to write things down to this level, of course, but generally there is some less formal pragmatic understanding of what it's all about. For example, in a recent thread about hashing &c I pointed out that adding a method such as "def __hash__(self): return 23" can ensure semantically correct hashing of any class; OTOH, it DOES badly violate pragmatics (and produces horrid performance!-), because hash values are MEANT to "differentiate" among different instances (they don't _hafta_, but they're expected to do SOME level of reasonable effort!-). > don't even know how you can test whether an abstract method was > implemented - should you run it and see if it raises a > NotImplementedError? Makes sense to me, yes. assertRaises seems good;-). > But with what arguments? If you're going to use your abstract base class for ANY purpose, you'd better have SOME idea of the signature with which you can call those methods which its subclasses must implement! Otherwise, it's all for naught: you get zero polymorphism, period. Say that subclass A has def whoa(self): ... while subclass B has def whoa(self, andmore): ... then you can NEVER call whoa without knowing which subclass you have an instance of -- no polymorphism! It's fine if a subclass wants to have a WIDER signature (add OPTIONAL args to those specified in the base class, even a *any if you wish), but there must be SOME commonality. Well then, call according to that commonality, just like any USE of you abstract base class will do. This points out that, if you wish to do checks at 'class' statement time which determine whether a class is instantiable, the signature of the methods should be part of those checks. Fortunately, module inspect makes it reasonably easy to get and check method
Re: Best GUI for small-scale accounting app?
Dave Cook <[EMAIL PROTECTED]> writes: > > You might not care. > > And in that case Tk is much simpler than just about anything else, unless > looks are really important. I've used tk and I don't think it's simpler than html. > Takes up twice as much space and is potentially confusing as the dropdowns > tend to look like real combo boxes in IE and Mozilla (only Konquerer seems > to make it visually clear that you can't edit the text.) I guess I'm not clear on when this is needed. > >> Also web development doesn't seem as coherent to me as development > >> with a good GUI framework. > > > > I'm not sure what that means. > > Basically it means that I find it harder and less intuitive. I > don't think I'm stupid, just pragmatically lazy. I don't think you're stupid either, but it looks like what's intuitive for you might be less intuitive for (some) other people, and vice versa. -- http://mail.python.org/mailman/listinfo/python-list
Re: How about "pure virtual methods"?
Mike Meyer wrote: Noam Raphael <[EMAIL PROTECTED]> writes: The answer is that a subclass is guaranteed to have the same *interface* as the base class. And that's what matters. This is false. For instance: class A(object): def method(self, a): print a class B(A): def method(self, a, b): print a, b B implements a different interface than A. Statically typed OO languages either use multi-methods or disallow changing the signature of an overridden method. A tool to detect such cases would probably be almost as useful as the tool you've proposed. I agree that such a tool would be very useful. In fact, I think it exists - I'm sure pychecker checks for mistakes like that. I understand that it checks for not implementing functions which just raise an exception too, so you can say, "why all this mess? Run pychecker and everything will be good." However, I think that there is a difference between these two tests, which explains why one should be done by the language itself and one should be done by an analysis tool. The difference is that handling arguments, in Python, can be seen as a part of the *implementation*, not the interface. The reason is that you can write a method which simply gets a (*args, **kwargs), and raises a TypeError if the number of args isn't two, and it would be completely equivalent to a function which is defined using def f(a, b). Of course, even in statically typed languages, you can't enforce an implementation to do what it should (too bad - it would have made debugging so much easier...) So checking whether the argument list of a method of a subclass suits the argument list of the original implementation is nice, but should be left to external analysis tools, but checking whether a method is defined at all can be done easily by the language itself. Noam -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda going out of fashion
<[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Well, you can say apply() is 'deprecated' now, What is deprecated is the spelling, not the concept or functionality. As far as I know, apply(func, args) is exactly equivalent to func(*args). If the latter had been invented in the beginning and you had learned it as Python's spelling of the apply concept, you might never miss the 'apply' spelling. Terry J. Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: list Integer indexing dies??
On Fri, 24 Dec 2004 02:59:40 +1030, Ishwor <[EMAIL PROTECTED]> wrote: > >>> 123[0] + 2 > 3 TypeError: unsubscriptable object > > > in which basically python can infer from the object type and print out > > > 1 instead of coughing up those errors? > > > > Why do you feel it should cough up 1? > > > > >>>123232[0] #hypothetical 0th position in the integer. > 1 TypeError: unsubscriptable object > > Suppose I write a number in octal notation. > > > > What should 035[0] cough up? Be carefull it should > > >>>035[0] > 3 # my own opinion. TypeError: unsubscriptable object > > cough up the same as 29[0]. > > >>>29[0] > 2 #again my own opinion TypeError: unsubscriptable object Just-in-my-own-opinion-ly y'rs Stephen Thorne -- http://mail.python.org/mailman/listinfo/python-list
Re: How about "pure virtual methods"?
Jp Calderone wrote: This lets you avoid duplicate test code as well as easily test new concrete implementations. It's an ideal approach for frameworks which mandate application-level implementations of a particular interface and want to ease the application developer's task. Jp It's a great way for sharing tests between different subclasses of a class. Thank you for teaching me. However, I'm not sure if this solves my practical problem - testing whether all abstract methods were implemented. I think that usually, you can't write a test which checks whether an abstract method did what it should have, since different implementations do different things. I don't even know how you can test whether an abstract method was implemented - should you run it and see if it raises a NotImplementedError? But with what arguments? And even if you find a way to test whether a method was implemented, I still think that the duplication of code isn't very nice - you have both in your class definition and in your test suite a section which says only "method so-and-so should be implemented." I think that making abstract methods a different object really makes sense - they are just something else. Functions (and methods) define what the computer should do. Abstract methods define what the *programmer* should do. Again, thanks for enlightening me. Noam -- http://mail.python.org/mailman/listinfo/python-list
Re: PHP vs. Python
I like the idea of being able to port specific sections to C ... Python seems more flexible than PHP ... scalable. We're mainly using it to drive dynamic web apps ... online store ... etc. Thanks Again! Stephen -- http://mail.python.org/mailman/listinfo/python-list
Re: urllib and sites that require passwds
Ishwor wrote: > On 23 Dec 2004 06:46:50 -0800, Fuzzyman <[EMAIL PROTECTED]> wrote: > > damn... I'm losing my leading spaces indentation should be obvious > We'll forgive you for that. It was from "top-of-your-head" ~;-) > Hey - I put the indentation in there... it just got stripped out when it was posted ! :-) > > anyway... (everything below except is indented at least one step). > > Fuzzy > Its nice that urllib2 returns errcode to process further. doesn't > urllib do that? The OP is saying that it hangs rather than returning an error. I haven't tested it. In general urllib2.urlopen is much better than urllib.urlopen. urllib has some useful other functions though. > Anyway i wanted to know if any website which is similar to CPAN > library website? I mean i want to be able find modules n stuff for > Python.. It would be really great to know. > There is PyPi and the Vaults of Parnassus. Neither are really like CPAN. There has been lots of talk about it recently - everyone agrees we need one... but no one is offering the bandwidth or the code. There are lots of modules available though - and usually not too hard to track down. Regards, Fuzzy http://www.voidspace.org.uk/python/index.shtml > Thanks. > > -- > cheers, > Ishwor Gurung -- http://mail.python.org/mailman/listinfo/python-list
Re: Keyword arguments - strange behaviour?
Steven Bethard wrote: > Fuzzyman wrote: > >>>Steven Bethard wrote: > > So, one of my really common use cases that takes advantage of the > fact that default parameters are evaluated at function definition > time: > > def foo(bar, baz, matcher=re.compile(r'...')): > ... > text = matcher.sub(r'...', text) > ... > > Sure.. but you also gave an example of an alternative that was complex, > > Interesting. I would have thought that my example was pretty simple. > Maybe it would be helpful to generalize it to: > > def foo(bar, baz, spam=badger(x, y, z)): > ... > > All it does is use a default value that was produced by a function call. > I'm surprised you haven't run into this situation before... > > Of course, what is complex or simple is a matter of personal opinion. I > use this pattern so often that it's quite simple to me, but I guess I > can understand that if you don't use such a pattern, it might seem > foreign to you. > > Steve Hello Steve, It wasn't that part of the example that I thought was over complex. (although it's not a 'pattern' I use often). You suggested that if we had dynamic evaluation of default values, you would have to replace it with : class foo(object): matcher=re.compile(r'...') def __new__(self, bar, baz, matcher=None): if matcher is None: matcher = self.matcher ... text = matcher.sub(r'...', text) ... Now that I thought was over complex... when all you wanted to do was put a constant into your default value ! Having said that I see Steve's point about not knowing the namespace when the function will be called. Regards, Fuzzy http://www.voidspace.org.uk/python/index.shtml -- http://mail.python.org/mailman/listinfo/python-list
Re: odbc script
Steve Holden wrote: you might want to look at www.egenix.com and think about installing the mxODBC module, which I have used with very good results. I'd also recommend checking out the imaginatively named adodbapi (http://adodbapi.sourceforge.net/) which allows you to use any ODBC driver through ADO. It presents a standard DB-API 2.0 interface. I've had good luck with it. -- Benji York -- http://mail.python.org/mailman/listinfo/python-list
RE: Metaclasses
Bob Cowdery wrote: > Thanks for your help Robert. I'm still not > understanding what I am seeing. I've forgotten > about the objective for the moment. I just want > to understand metaclasses. All right; then I'll skip the speech about how metaclasses are not the solution you're looking for. ;) They rarely are. > Two things I don't understand. __init__ gets called > when I import api, not when I create an instance of > API so the capability is set in stone on the import > and I can't change it. Correct. autoprop.__init__ is executed when the API class definition has finished executing. This is an important point about Python in general: class definitions are not declared so much as executed. Your API class, for example, has three statements that happen to be executed within the scope of a class definition; otherwise, they're normal Python statements and are executed like any other. The statements in autoprop.__init__ are executed after the last statement in the API class definition has executed. Anyway, if you want your code (which binds capability methods) to occur per-instance, it should most likely be executed within API.__init__, and you don't need metaclasses at all. autoprop.__init__ is executed once per *class*, not once per instance. That is, if someone were to make a subclass of API, then autoprop.__init__ would fire again, receiving that subclass instead of the API class as its first argument. > Second when I try to read attribute 'mode' > (or any other valid attribute) I get an error. > If I set it to some value and read it it's there. When you set the value, you're not going through the property--it's just setting a new attribute on the object as you can with any Python object. >>> class Thing(object): pass ... >>> t = Thing() >>> t.stuff = 4, 5, 6 >>> t.stuff (4, 5, 6) I think the first thing you need to do is stop using __private members, which mangle their own names. ;) Drop them, get your metaclass (or other solution) working, then go back to __private names if you want. At the moment, it's confusing the issue greatly. But why don't you just dynamically set attributes (like 'mode') instead of methods (like '_get_mode')? Will some of these be read-only? Robert Brewer MIS Amor Ministries [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: sql server support from linux
Simon Wittber wrote: If you can get the DB-API wrappers running on Win2k, how about doing that locally and then writing a quickie socket server which your linux client can connect to? I've exposed the DB API using Pyro. I had to turn multithreading off, as the server leaked memory on every query. I considered doing exactly the same thing a while ago, but was worried about running into an annoyance like that. Instead, I looked around some and found ODBTP (http://odbtp.sourceforge.net/) which allows you to access ODBC drivers on a Windows box from a cross-platform C library. A service is installed on a Windows box that has ODBC drivers for the target database and the client connects to the ODBTP service instead of directly to the database. The service then connects to the database. You end up with something like this: Client (Linux perhaps) > Windows Service > DB Note that the ODBTP service can run on the same machine as the database, or not. I've used it with three different machines, each running different operating systems. The client was Linux, the service ran on Windows (of course), and the database was on a minicomputer. Unless the volume of data you're transferring is very large, it works quite well. If all this sounds like it would be useful for your situation take a look at the Python bindings I wrote up: http://benjiyork.com/odbtp.html. A new version will be released soon with lots of improvements, and it'll be merged into the main ODBTP project sometime after the new year. -- Benji York -- http://mail.python.org/mailman/listinfo/python-list
Re: Best GUI for small-scale accounting app?
On 2004-12-21, Paul Rubin wrote: > Dave Cook <[EMAIL PROTECTED]> writes: >> Web browser "widgets" seem pretty limited to me, though. > > You might not care. And in that case Tk is much simpler than just about anything else, unless looks are really important. >> You don't even have something as simple as a combo box (i.e. an >> editable entry with a drop down), > > Just put an input field and a dropdown on the page. Takes up twice as much space and is potentially confusing as the dropdowns tend to look like real combo boxes in IE and Mozilla (only Konquerer seems to make it visually clear that you can't edit the text.) >> Also web development doesn't seem as coherent to me as development >> with a good GUI framework. > > I'm not sure what that means. Basically it means that I find it harder and less intuitive. I don't think I'm stupid, just pragmatically lazy. Dave Cook -- http://mail.python.org/mailman/listinfo/python-list
Re: odbc for solid
flupke wrote: On winsdows i could get by by using ODBC and the dll's to access the solid database but i want to eventually run it on a linux server. ODBTP (http://odbtp.sourceforge.net/) allows you to hit Windows ODBC drivers over the network from any machine with a C compiler. If it sounds like something you'd want to use, download my python interface (being merged into the main project soon-ish) from http://benjiyork.com/odbtp.html. -- Benji York -- http://mail.python.org/mailman/listinfo/python-list
Koolaid (was Re: Optional Static Typing)
John Roth wrote: "Rocco Moretti" <[EMAIL PROTECTED]> wrote: The question is, should Guido state "TDD is the one true way to program in Python.", or should concessions be made in the language design for those who don't "drink the TDD Kool-aide". Neither one. I hope you didn't mean that people who advocate TDD are suicidal fanatics, because that's exactly what "drink the kool-aid" means. I always thought the connotation was more that those who "drank the Kool-Aid" were unthinking drones, following what others told them to do. Reading Wikipedia's account of Jonestown, it seems that the truth is a mix of both the blind loyalty thing and the suicidal fanatic thing. I've heard this applied most often in recent years to XML, and while I can imagine some people who apply the phrase to those overusing XML might think they are effectively committing suicide, I'm pretty sure most times it is just used to mean "you are blindly doing what everybody else does without thinking about whether it's the right thing to do". -Peter P.S.: The ironic thing about all this is that it was actually something called "Flavor Aid", made by a company called Jel Sert (http://www.jelsert.com), and not Kool-Aid at all. What would be even funnier is if the expression doesn't derive from the Jonestown suicides and I've always just assumed it did... -- http://mail.python.org/mailman/listinfo/python-list
PyCon Registration Opens Today!
Dear Python User: Following my last message, I am pleased to be able to announce that you can register for PyCon DC 2005 on the web at http://www.python.org/pycon/2005/register.html starting at 1700 EST today (December 23). Thanks to George Belotsky of Open Light Software for assistance in preparing the credit card processing software. As always, further information about PyCon is available in the usual places: http://www.pycon.org/ http://www.python.org/pycon/ I look forward to meeting you at PyCON DC 2005. In the meantime please let me offer my best wishes for a happy and peaceful holiday season. regards Steve Holden Chairman, PyCON DC 2005 -- PyCon DC 2005: The third Python Community Conference http://www.pycon.org/ http://www.python.org/pycon/ The scoop on Python implementations and applications -- http://mail.python.org/mailman/listinfo/python-list
Re: list Integer indexing dies??
Jeff Shannon wrote: > Ishwor wrote: > > >On Thu, 23 Dec 2004 13:33:16 -0300, Batista, Facundo > ><[EMAIL PROTECTED]> wrote: > > > > > >>[Ishwor] > >> > >>#- > What should 035[0] cough up? Be carefull it should > >>#- > >>#- >>>035[0] > >>#- 3 # my own opinion. > >> > >> > >why 3? The reason we get 3 and not 0 here is the *fact* that Python > >knows that its an octal rep. and not decimal ;-) > > > > > > Except that, at the point where the indexing takes place, Python > *doesn't* know that it's an octal rep. All integer literals, regardless > of representation, generate exactly the same bytecode. > > >>> def f(): > ... x = 035 > ... y = 29 > ... > >>> dis.dis(f) > 0 SET_LINENO 1 > > 3 SET_LINENO 2 > 6 LOAD_CONST 1 (29) > 9 STORE_FAST 1 (x) > > 12 SET_LINENO 3 > 15 LOAD_CONST 1 (29) > 18 STORE_FAST 0 (y) > 21 LOAD_CONST 0 (None) > 24 RETURN_VALUE > >>> > > Given that Python may not even have access to the .py file, only the > .pyc (which has lost all record of the source representation), there's > no way for the interpreter to do what you suggest. And even if there was, what should (104 + 0x68 + 0150)[0] print? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Interactive Shell - outputting to stdout?
Hey Steve, I did write a program to deal with the windows command interpreter, and it works. I don't need to do this, but a friend of mine needed to issue commands to the interpreter via pipes from a non python program, and he has a fully functional component for using pipes, and has done it with other interpreters before. I guess I'll have to separate the std's and continue from there. Thanks for your input. Avi. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda going out of fashion
<[EMAIL PROTECTED]> wrote: > Thanks. :-) Two remarks. > o One-liner fits the eyes & brains of a portion of people. True! So, personally, I'd rather code, e.g., def bools(lst): return map(bool, lst) rather than breal this one-liner into two lines at the colon, as per standard Python style. However, uniformity has its advantages, too; I'm ready for the one-liner style to be outlawed in Python 3.0, purely in the advantage of uniformity. Note that lambda is utterly useless here, be it for one-liners or not. Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Python To Send Emails Via Outlook Express
[EMAIL PROTECTED] writes: > Hi Lenard, > > As the risk of severely embarassing myself can I ask for your help one > more time. > I have tried changing your script to include attachments, but guess > what, (and this should come as no suprise) I can't do it. > So > Here is my feeble attempt at changing the script.. Actually the only real problem is with the lpFiles argument to the MapiMessage constructor call. > [snip] > > def SendMail(recipient, subject, body, attach=[]): > """Post an e-mail message using Simple MAPI > > > recipient - string: address to send to > subject - string: subject header > body - string: message text > attach - string: files to attach > """ > attach = map( os.path.abspath, attach ) > nFileCount = len(attach) > if attach: > MapiFileDesc_A = MapiFileDesc * len(attach) > fda = MapiFileDesc_A() > for fd, fa in zip(fda, attach): > fd.ulReserved = 0 > fd.flFlags = 0 > fd.nPosition = -1 > fd.lpszPathName = fa > fd.lpszFileName = None > fd.lpFileType = None > lpFiles = fda Add this else clause to the "if attach:" else: # No attachments lpFiles = cast(NULL, lpMapiFileDesc) # Make NULL > > > recip = MapiRecipDesc(0, MAPI_TO, None, recipient, 0, None) > #msg = MapiMessage(0, subject, body, None, None, None, 0, > # cast(NULL, lpMapiRecipDesc), 1, pointer(recip), > # nFileCount, cast(NULL, lpMapiFileDesc)) > msg = MapiMessage(0, subject, body, None, None, None, 0, > cast(NULL, lpMapiRecipDesc), 1, pointer(recip), > nFileCount, cast(NULL, lpFiles)) Replace "cast(NULL, lpFiles)" with "lpFiles". > > > rc = MAPISendMail(0, 0, byref(msg), 0, 0) > if rc != SUCCESS_SUCCESS: > raise WindowsError, "MAPI error %i" % rc And that is it. The "cast(NULL, lpFiles)" was a way of assigning a null value to the lpFiles member of the MapiMessage structure. Using None did not work. But recasting a c_void_p(None) did. Lenard Lindstrom <[EMAIL PROTECTED]> -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda going out of fashion
Jp Calderone <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
> On Thu, 23 Dec 2004 13:36:08 GMT, rzed <[EMAIL PROTECTED]> wrote:
>>Stephen Thorne <[EMAIL PROTECTED]> wrote in
>> news:[EMAIL PROTECTED]:
>> > [snip]
>> >
>> > {
>> > 'one': lambda x:x.blat(),
>> > 'two': lambda x:x.blah(),
>> > }.get(someValue, lambda x:0)(someOtherValue)
>> >
>> > The alternatives to this, reletively simple pattern, which is
>> > a rough parallel to the 'switch' statement in C, involve
>> > creating named functions, and remove the code from the
>> > context it is to be called from (my major gripe).
>> >
>> > [snip]
>>
>> Not addressing lambdas per se, but something similar to your
>> pseudo- switch statement can be done without using them at all.
>> One way might be to use a function dictionary wrapped in an
>> accessor function, such as this:
>>
>> def dofns(key):
>> fd2 = {
>> 0:'print "Key 0"',
>> 1:'print "one"',
>> 4:"\n".join(['for ix in range(15):',
>> ' print "%s%d" % (" "*ix,ix)']),
>> }
>> try:
>> exec(fd2[key])
>> except KeyError:
>> print 'Key',key,'not found'
>>
>
> I hate to be nasty, but *ugh* what a horrible way to start the
> day.
>
> There are so many things wrong with this.
>
> By exec'ing code strings you lose compile-time _syntax_
> checking. I'm all for dynamicism, but it really is nice to let
> the compiler do _something_ things for you.
>
> By exec'ing code strings you slow down the entire function
> by forcing a slower name-lookup code path in the interpreter.
>
> By exec'ing code strings you lose the ability to pass values
> back to your caller (oh, you could "return" in one of those, but
> *ugg* that'd be even more terrible, and probably not what you
> want in most cases, since it doesn't let you get at the value
> except from your caller. you could also set names in the local
> namespace but that's pretty messed up too, python already has a
> function return convention, making up your own is no fun).
Thanks for your comments. I'll not argue that I would actually put
exactly this code into anything I intended for public consumption;
it was to illustrate that there were in fact alternatives to
lambda.
In point of fact, though, there might be reasons to do something
similar (addressing at least a couple of your objections). I don't
think speed of execution is going to be a factor unless the main
processing in the program centers on this snippet. It's a way to
dummy up a switch statement, and while that could mean it was
central to the program, it seems to me more likely to be relatively
peripheral.
In a switching application, the dynamic code shown would more
likely be function invocations, but it could on occasion be useful
to implement a script processor (I've used them for various
reasons). Generally they seem most useful for interacting with
humans (and hence with human speed limitations).
One class of applications where such a technique could be useful
would be in allowing various groups to access a database and
perform operations on the data specific to their function. Dynamic
searches, for instance, ad hoc reporting and the like. Not all
groups would have the same needs or privileges, and using separate
function tables is one way to limit activities to a specified
range.
It's fairly trivial to allow passing and returning data; the main
difficulty (apart from security concerns) is choosing the
convention to use.
>
> There are probably more reasons this is bad too.
>
> Even using `def' to define a function for each of these would
> be
> preferable.
>
> Aside from that, exec() isn't a function. You "exec foo", not
> "exec(foo)". The latter works simply because parens act as to
> set precedent instead of as part of function call syntax when
> used this way.
>
> Also, you should do the dictionary lookup first, in a
> try/except,
> and then execute it later, _outside_ the try/except, otherwise
> you risk masking KeyErrors from exec'd code.
>
> Jp
>
Good points, which I'll take to heart when I'm putting this stuff
into production code.
--
rzed
--
http://mail.python.org/mailman/listinfo/python-list
Re: Lambda going out of fashion
Robin Becker wrote: Alex Martelli wrote: . By the way, if that's very important to you, you might enjoy Mozart (http://www.mozart-oz.org/) .very interesting, but it wants to make me install emacs. :( Apparently you can also use oz with a compiler and runtime engine...see http://www.mozart-oz.org/documentation/apptut/index.html Kent -- http://mail.python.org/mailman/listinfo/python-list
Re: BASIC vs Python
In article <[EMAIL PROTECTED]>, Alan Gauld <[EMAIL PROTECTED]> wrote: > I dunno. Here in the UK there was a small home computer called (I > think) the Oric(*) which had a membrane keyboard, 4K or RAM and > ran Forth.It had a small cult following before dying out. It > looked a bit like the early Sinclair/Timex ZX81 and I think the > developers came from that stable. > I believe my learned friend refers to the Jupiter Ace. -- Remove luncheon meat to reply. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Interactive Shell - outputting to stdout?
Avi Berkovich wrote: Hello, I was unable to use popen2.popen4 to grab python.exe's (2.3) output, for starts, it doesn't show the version information at the beginning and won't return anything when writing to the stdin pipe, it seems that if I give it some error nous expression, the pipe would return the exception data, though nothing else comes through. A friend of mine also tried this using win32api on delphi, and got the same result. I also tried "python.exe > data.txt" and was amazed to find out that it won't redirect the output to the file. So, may someone please shed some light over this? Avi. Well, your first misunderstanding appears to be the omission of the standard error file. Interactive messages and prompts are written to stderr, output to stdout: C:\Steve>python.exe > python.txt Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> 123 >>> 345 >>> ^Z C:\Steve>type python.txt 123 345 When you try to write a program that communicates with a client that's intended for interactive use (such as the Python interpreter when called with no arguments), you have the problem of divining exactly when the client is waiting for input. Rather than blame the Python interpreter, first write a program that interacts with (say) the Windows command-line interpreter. If your experience is substantially different then it *might* be a problem with the interpreter. If your experience is more or less the same then the problem is probably to do with the nature of the interactions, which are bad enough when only considering stdin and stdout. When you add the stderr stream into the picture it's sometimes impossible to know when the interactive client is waiting for input. One final comment: you haven't so far said *why* you want to interact with Python in this way. Given the availability of exec and eval(), just what is it that you are trying to do that they won't let you? regards Steve -- Steve Holden http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/ Holden Web LLC +1 703 861 4237 +1 800 494 3119 -- http://mail.python.org/mailman/listinfo/python-list
Re: Reading and Writing
-Galahad, Thank you very much. I will give it a shot and see if I can make it hapen. I think this will help a lot. I was just trying to implement a simple sorting algorithm that I knew from C++, for practice but I couldn't figure the mechanics of Python. Thanks again, Novitiate -- http://mail.python.org/mailman/listinfo/python-list
Re: list Integer indexing dies??
Ishwor wrote: On Thu, 23 Dec 2004 13:33:16 -0300, Batista, Facundo <[EMAIL PROTECTED]> wrote: [Ishwor] #- > What should 035[0] cough up? Be carefull it should #- #- >>>035[0] #- 3 # my own opinion. why 3? The reason we get 3 and not 0 here is the *fact* that Python knows that its an octal rep. and not decimal ;-) Except that, at the point where the indexing takes place, Python *doesn't* know that it's an octal rep. All integer literals, regardless of representation, generate exactly the same bytecode. >>> def f(): ... x = 035 ... y = 29 ... >>> dis.dis(f) 0 SET_LINENO 1 3 SET_LINENO 2 6 LOAD_CONST 1 (29) 9 STORE_FAST 1 (x) 12 SET_LINENO 3 15 LOAD_CONST 1 (29) 18 STORE_FAST 0 (y) 21 LOAD_CONST 0 (None) 24 RETURN_VALUE >>> Given that Python may not even have access to the .py file, only the .pyc (which has lost all record of the source representation), there's no way for the interpreter to do what you suggest. Jeff Shannon Technician/Programmer Credit International -- http://mail.python.org/mailman/listinfo/python-list
Re: list Integer indexing dies??
Ishwor wrote: On Thu, 23 Dec 2004 11:17:57 -0300, Batista, Facundo Well, because the integer is not a subscriptable object If i see this code 'a'[0] then what does it really say about semantics ?? Really its hard for me to digest that 'a'[0] is supported by Python where as 1[0] isn't. 5.2/3 is supported by Python, but 'a'/'b' isn't. -- Serhiy Storchaka -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda going out of fashion
Alex Martelli wrote: > I don't know what it IS about lambda that prompts so much dubious to > absurd use, but that's what I observed. I don't know if that plays any > role in Guido's current thinking, though -- I have no idea how much > "dubious Python" he's had to struggle with. Just a side comment, unrelated to the lambda issue: it just occurred to me that it might be very useful to have a collection of 'dubious python' available somewhere. Just as it is great for everyone to see good code in action, it is equally enlightening to see examples of bad practices (preferably with an explanation of why they are bad and the good alternatives). I suspect after your CB2 experience, you are in a uniquely well-qualified position to have such a collection handy. Whether you feel inclined to spend the necessary time assembling it for public consumption is a different story :) But I think it would be a very valuable resource, and a great way to point newbies to 'mandatory reading' before they travel down the same blind alleys for the n-th time. Cheers, and happy holidays, f -- http://mail.python.org/mailman/listinfo/python-list
Re: Reading and Writing
-Galahad, Thank you very much. I will give it a shot and see if I can make it hapen. I think this will help a lot. I was just trying to implement a simple sorting algorithm that I knew from C++, for practice but I couldn't figure the mechanics of Python. Thanks again, Novitiate -- http://mail.python.org/mailman/listinfo/python-list
Python Interactive Shell - outputting to stdout?
Hello, I was unable to use popen2.popen4 to grab python.exe's (2.3) output, for starts, it doesn't show the version information at the beginning and won't return anything when writing to the stdin pipe, it seems that if I give it some error nous expression, the pipe would return the exception data, though nothing else comes through. A friend of mine also tried this using win32api on delphi, and got the same result. I also tried "python.exe > data.txt" and was amazed to find out that it won't redirect the output to the file. So, may someone please shed some light over this? Avi. -- http://mail.python.org/mailman/listinfo/python-list
Re: Switch statement (was: Lambda going out of fashion)
Skip Montanaro <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
>
> Stephen> {
> Stephen> 'one': lambda x:x.blat(),
> Stephen> 'two': lambda x:x.blah(),
> Stephen> }.get(someValue, lambda x:0)(someOtherValue)
>
> One thing to remember is that function calls in Python are
> pretty damn expensive. If x.blat() or x.blah() are themselves
> only one or two lines of code, you might find that your "switch"
> statement is better written as an if/elif/else statement.
> You're making potentially three function calls (get(), lambda
> and x.blat() or x.blah()) to perform what might only be a small
> handful of inline statements. I'll ignore the readability cost
> of your solution vs. an if statement.
>
> Stephen> So, the questions I am asking are: Is this okay
> with everyone?
>
> Sure. I'll adjust.
>
> Stephen> Does anyone else feel that lambda is useful in this
> kind of Stephen> context?
>
> It's useful in this sort of context. It will probably always be
> limited to single expressions, which will always leave it a
> second-class citizen in Python. Interestingly enough, lambda in
> the Lisp world has the same limitation, however, since Lisp code
> is nothing but a series of s-expressions, that's not a problem.
>
> Stephen> Are there alternatives I have not considered?
>
> I've never seen a situation where if/elif/else wasn't adequate
> or was less clear than the many attempts at switch-like
> behavior.
>
> Folks (in general), there is still an open PEP on a switch
> statement for Python. It's been idle since late 2001:
>
> http://www.python.org/peps/pep-0275.html
>
> It would help if interested people were to take a look at it and
> identify open issues. If you google for pep 275 you will
> probably find relevant python-dev discussions from the 2001/2002
> timeframe. Thomas Wouters' patch for the interpreter would also
> need to be resurrected and brought up-to-date. I not longer
> remember why the PEP stalled.
>
It seems to me that it was regarded as misguidod.
--
rzed
--
http://mail.python.org/mailman/listinfo/python-list
Anyone have a python socket.pyd that support raw socket for windows?
Hi all, I got python 2.3 on a XP and win2k. I'm looking for a _socket.pyd that support raw socket (IP_HDRINCL). I did found someone guy that did compile his own _socket (pysockraw) but the web is not working anymore :/ I'm lazy to compile my own :) Thx, and Merry X-mas!! Simon Roses Femerling -- http://mail.python.org/mailman/listinfo/python-list
Re: Optional Static Typing
John Roth wrote: "Rocco Moretti" <[EMAIL PROTECTED]> wrote > Looking at C, it's doubtful error prevention and program clarification was a serious objective in the static typing system. It's more reasonable to conclude that C is statically typed because it allows the compiler to more easily allocate 1 vs 2 vs 8 bytes for a particular variable, and to make sure the proper addition opcodes get put down. The C language does not have strong typing in the sense that most people use the term today. Strong != Static As I understand it, strong typing means an object (variable) is what it is, and can't be changed to a different type without explicit conversion - weak typing being that an object can be any type, depending on which functions you use to look at it. Static typing is that a variable has a specific type, and can't hold a variable of a different type. This is opposed to dynamic typing, where the type of an (object in a) variable is flexible and determined at run time. Python - Strong, Dynamic C - Weak, Static Perl - Weak, Dynamic This is how I understand it. Could be wrong - wouldn't be surprised if I was, as it's a rather confusing issue at times. The question is, should Guido state "TDD is the one true way to program in Python.", or should concessions be made in the language design for those who don't "drink the TDD Kool-aide". Neither one. I hope you didn't mean that people who advocate TDD are suicidal fanatics, because that's exactly what "drink the kool-aid" means. The irony didn't travel well. All I meant is that in all the advocacy, it may get ignored that reasonable people might disagree about the value of TDD, that TDD is not a "be-all, end-all" for all people. "Concessions" also probably wasn't the right choice of word, as it implies the TDD people are giving something up. My point was, if Python is not going to be solely targeted at TDD, facilities that make other ways of doing things easier are likely (should) be included, as long as they don't negatively affect how the majority of the people who use Python do things. So the conclusion here is that static typing is an attempt to make programming safe for people that shouldn't be programming in the first place. I rebut it thusly: "elitist bastard." Bullshit. Where did you get your certificate in mind reading? Sorry. I didn't mean to imply that *you* were an elitist bastard. I merely meant that someone who would dismiss something as for "people that shouldn't be doing X in the first place" is likely biased by snobbery. You were merely restating someone else's opinion, and if I accidentally accused you of also holding it, I'm sorry. From the rest of your post, it seems we pretty much agree on the key point - different people have different ways of doing things, none of which are necessarily "wrong" in and of themselves. Python tries to be open and inclusive towards all who want to program, without sacrificing power for it's core users. Is there a group of people for whom static typing truly helps? I don't know. What I do know is that saying that you don't need static typing if you use TDD doesn't say anything about the helpfulness of static typing for those who don't use TDD. Whether the latter group is worth Python worrying about is a philosophical question on the future direction of Python best left to Guido. -- http://mail.python.org/mailman/listinfo/python-list
Re: error problems for import some copora with nltk
Dear Jeff, Thank you, it was the numeric. After I installed the numeric library which is Numeric-23.6.win32-py2.3.exe for python 2.3.4 verson, it is working correctly. Thank you again, Kyung -- http://mail.python.org/mailman/listinfo/python-list
hidding the "console" window + system global shortcut keys
Title: hidding the "console" window + system global shortcut keys Hi, it's a broad topic because they all poped in my head at the same time while writting the alpha version of a desktop-helper app. The app must be the less obstrusive possible. some history: It's mainly for win32. I started writting this to compensate the lack of posix tools and pipes on win32. in *NIX i could use wc, grep, sort, et al to deal with files(?). In windows, i mainly depend on my text editor. I strugle with no 'grep' or no 'cut' or no easy way to pass data between programs other then copy paste or saving the file. The actual method of saving, opening a w32 port of bash, and then doing the usual *NIX way is too intrusive in windows because you have to leave you "ambient", do things, go back to your previous "ambient". So, the program was to sit in the taskbar or in the systray. and by some mouse clicks or global key combinations transform the selected text or the clipboard content with a easy-to-input posix like syntax mimic by python functions. I haven't even scrateched the surface for all that. but for that pre-alpha i *really* want to mainly do those things: 1. Give a painfull death to the "console window" i will need console output only in debuging 2. Set global key biddings. #1 is really superfulous, i know, but #2 is really driving me nuts. the key bidings would be idealy in a multiplataform way, since i use* W32, Irix, BeOS and OSX. in that order :) Thanks for any hints Gabriel * I also use Plan9 but it has then times more 'pipes' suport in the GUI then any *NIX has in CLI hehe and yep, no linux/bsdish desktop here. the CLI enviroment fulfill perfectly my needs. X only gets in the way -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows XP - cron or scheduler for Python?
I have gone through the pain of trying to use those commands and use other available cron clients for Windows to find they are expensive, or have bugs and are not stable. So I wrote a very simple yet powerful script that handles all the basic functionality of Cron. It has been stable and used in production for about a year. The source code is in Python and you can read it, it is a simple page. I have also created a version for Windows with an installer that doesn't even require Python installed in the target machine. You can find the project here: http://sourceforge.net/projects/pycron Emilio. -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows XP - cron or scheduler for Python?
Cron clients for Windows to find they are expensive, or have bugs and are not stable. So I wrote a very simple yet powerful script that handles all the basic functionality of Cron. It has been stable and used in production for about a year. The source code is in Python and you can read it, it is a simple page. I have also created a version for Windows with an installer that doesn't even require Python installed in the target machine. You can find the project here: http://sourceforge.net/projects/pycron Emilio. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda going out of fashion
Jp> PyStones may be short (and be nearly lambda free!) but it is one Jp> opaque blob to me. I'd be hard pressed to rewrite it in any style, Jp> given its perverse use of global state. It's written that way on purpose, of course. Pystone is almost a direct translation of a similar program written in C (dhrystone *), which was itself a translation of a program written in Ada. The reason for the rather unusual coding style in those earlier programs was to defeat compiler optimization techniques and attempt to test a processor's integer performance. Skip (*) http://performance.netlib.org/performance/html/dhrystone.intro.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Optional Static Typing
"Rocco Moretti" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] John Roth wrote: One of the comments on Artima asks a rather profound question: static typing is an answer. What's the question? (That's a paraphrase.) The answer that everyone seems to give is that it prevents errors and clarifies the program. It might just be me, but I thought it was to simplify code analysis and compilation. (That is, for the use of static typing in general, not for Python in particular.) Looking at C, it's doubtful error prevention and program clarification was a serious objective in the static typing system. It's more reasonable to conclude that C is statically typed because it allows the compiler to more easily allocate 1 vs 2 vs 8 bytes for a particular variable, and to make sure the proper addition opcodes get put down. The C language does not have strong typing in the sense that most people use the term today. Now whether this would be useful for Python is an open question. Many of the supposed advantages simply aren't there when you go to the discipline of writing a test and then writing exactly the code needed to make the test pass, and not one keystroke more. ... This isn't to say TDD is the be-all and end-all of correctness. Right. And unit tests don't do anything for people who don't use them. Absolutely correct. The question is, should Guido state "TDD is the one true way to program in Python.", or should concessions be made in the language design for those who don't "drink the TDD Kool-aide". Neither one. I hope you didn't mean that people who advocate TDD are suicidal fanatics, because that's exactly what "drink the kool-aid" means. So the conclusion here is that static typing is an attempt to make programming safe for people that shouldn't be programming in the first place. I rebut it thusly: "elitist bastard." Bullshit. Where did you get your certificate in mind reading? Remember that all of the people who started this were computer science professors, and most of their experiance was with computer science students. They were also European computer science professors with a strong mathematical tendency; we have since learned that mathematicians and software developers think differently (see some comments by Don Knuth to that effect - don't have the reference handy.) They're the ones who were elitist: they strongly believed that you had to be a mathematician to be able to properly program, and that they were doing something good for the people who weren't fortunate enough to have a rigorous mathematical background by forcing them into the strait-jacket of static typing. Competent professional programmers are a different group, and need different facilities. One of the draws of Python is that it's welcoming to newcomers and programmers of all talents. You don't have to be an "uber-programmer" to use it and use it well. Should we hobble it to suit poor programmers? No. But that's no reason why it can't be made to be easier and safer to use for the hobbyist when it doesn't compromise usefulness for the power-programmer. (My opinion) Python shouldn't have a sign on the door saying: "You must be this 'leet to enter." And it won't. Python has always had the "consenting adults" philosophy. Will static typing be a boon for Python? Is it necessary? Or is it the trailhead on the road to Hades? Only time will tell. Since it won't happen, I'm not particularly worried about it. If it does, I'll find another language. John Roth -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda going out of fashion
On Thu, 23 Dec 2004 12:00:29 -0600, Skip Montanaro <[EMAIL PROTECTED]> wrote: > > >> While I'm sure it can be done, I'd hate to see a non-trivial Python > >> program written with lambda instead of def. > > Jp> What, like this? > > Jp> (lambda r,p,b:... > > Jp> OTOH, maybe that's still trivial, it's only a multiuser network > Jp> chat server, after all. > > You cheated by not rewriting Twisted using only lambda. That's why I > suggested pystone. While it's a very small program, it is pretty much > self-contained. > PyStones may be short (and be nearly lambda free!) but it is one opaque blob to me. I'd be hard pressed to rewrite it in any style, given its perverse use of global state. 'course, I'll probably end up trying anyway. Jp -- http://mail.python.org/mailman/listinfo/python-list
Re: Optional Static Typing
Doug Holton: >And there are some disadvantages to doing it this way. >It means Python is more flexible to use than Boo, I've just suggested the *syntax* that I like more. Bye, Bearophile -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem with msvcrt60 vs. msvcr71 vs. strdup/free
Scott David Daniels wrote: I encourage anyone who gets further into solving the "How do I use MinGW to build Python2.4 (and later) standard-distribution compatible modules (.pyd s)?" question to share any clues they have. The MS free compiler is useful to many, but not all of us. I think the simplest answer is "It works out of the box". Just do python setup.py build --compiler=mingw32 If it fails, report what the failure is (the first failure should be lack of libpython24.a, for which you can find build instructions in Google). Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem with ./configure (py2.3.4)
André Amram Duque wrote: I have problem with re-install python 2.3.4, when I execute ./configure is appear one message in config.log, follow below : configure:1710: gccconftest.cc >&5 gcc: installation problem, cannot exec `cc1plus': No such file or directory configure:1713: $? = 1 My gnu/linux is 2.6.8-1-386(debian/sarge) Somebody could help me? What is the version of gcc that you have installed (gcc -v)? Do you have g++ installed? If not, you should configure python --without-cxx. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
ADO, Python and MS Exchange
Hi all!
I'm new to python and I seem to have a hit a of a brick wall. I hope
you guys can help.
I'm trying to rewrite some of my vbscripts in python. This particular
script connects to a mailbox in MS Exchange via ADO and calculates the
mailbox size. I seem to have run into a couple of issues getting python
to talk to MS Exchange via ADO though. This is the code i'm using:
from win32com.client import Dispatch
conn = Dispatch('ADODB.Connection')
conn.ConnectionString = "URL=http://ctmx01/exchange/warren.ali";
conn.Open()
rs = Dispatch('ADODB.RecordSet')
rs.ActiveConnection = conn
rs.Open("Select http://schemas.microsoft.com/exchange/foldersize from
scope ('deep traversal of http://ctex01/exchange/warren.ali')",
conn.ConnectionString)
But running the code, all i get is this error message:
Traceback (most recent call last):
File "C:\Python24\ad.py", line 12, in -toplevel-
rs.Open("Select http://schemas.microsoft.com/exchange/foldersize
from scope ('deep traversal of http://ctex01/exchange/warren.ali')",
conn.ConnectionString)
File
"C:\Python24\lib\site-packages\win32com\gen_py\2A75196C-D9EB-4129-B803-931327F72D5Cx0x2x8\_Recordset.py",
line 93, in Open
return self._oleobj_.InvokeTypes(1022, LCID, 1, (24, 0), ((12, 17),
(12, 17), (3, 49), (3, 49), (3, 49)),Source, ActiveConnection,
CursorType, LockType, Options)
com_error: (-2147352567, 'Exception occurred.', (0, None, '', None, 0,
-2147217900), None)
Does anyone have any suggestions? I've kinda put the code together
based on this tutorial: http://www.mayukhbose.com/python/ado/index.php
but cant seem to adapt it to talk to exchange
This is the code that works via vbscript
http://support.microsoft.com/kb/2913
Set Rec = CreateObject("ADODB.Record")
Set Rs = CreateObject("ADODB.Recordset")
strURL = "http://exchangeserver/exchange/warren.ali";
Rec.Open strURL
sSQL = "Select"
sSQL = sSQL & "
""http://schemas.microsoft.com/exchange/foldersize""; "
'sSQL = sSQL & ", ""DAV:displayname"" "
sSQL = sSQL & " from scope ('deep traversal of " & Chr(34)
sSQL = sSQL & strURL & Chr(34) & "')"
'sSQL = sSQL & "Where ""DAV:isfolder""=true"
' Open the recordset.
Rs.Open sSQL, Rec.ActiveConnection
Thanks!!
--
Keeping it (sur)real since 1981. (now in
print:http://thinkingmachine.blogsome.com)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Unicode entries on sys.path
Thomas Heller wrote: It seems that Python itself converts unicode entries in sys.path to normal strings using windows default conversion rules - is this a problem that I can fix by changing some regional setting on my machine? You can set the system code page on the third tab on the XP regional settings (character set for non-unicode applications). This, of course, assumes that there is a character set that supports all directories in sys.path. If you have Japanese characters on sys.path, you certainly need to set the system locale to Japanese (is that CP932?). Changing this setting requires a reboot. Hm, maybe more a windows question than a python question... The real question here is: why does Python not support arbitrary Unicode strings on sys.path? It could, in principle, atleast on Windows NT+ (and also on OSX). Patches are welcome. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
Re: list Integer indexing dies??
> ;-) gotcha. But shouldn't this be valid too?? > >>> 123232[0] No, it shouldn't be valid. It makes the implicit assumption that you want the base 10 digit, which isn't really a good assumption to make in the world of computers. Programmers are just as likely to want hexadecimal, and arguments could be made for octal or binary too. Basically, there's no intuitive meaning for trying to slice an integer. Also, it seems like it would be very rare that anybody would want to do this. Most of those cases fall into one of two categories- (1) trying to display digits of a number in a human readable way, and (2) trying to do some kind of math. (1) is better handled by explicitly converting it to a string first, and (2) is likely better handled using logarithms. -- http://mail.python.org/mailman/listinfo/python-list
Re: list IndexError
Grant Edwards wrote: On 2004-12-23, Steven Bethard <[EMAIL PROTECTED]> wrote: Ah, my mistake, I missed the [:] after the source argument that was taking a copy... which brings up the question, how many other people would miss it? Too many. This is why I greatly prefer list(lst) To me, that's just as non-obvious. I would have guessed that calling list() on a list was a noop. I would be wrong. Surprised, but wrong. It makes a lot more sense when you remind yourself that list() et al are not conversion functions, but rather class constructors. (This is complicated by the fact that in old Pythons, int() and float() *were* conversion functions... but are not so any more.) Given a user-defined class, I think it wouldn't be any surprise to see that class Spam: # [] s1 = Spam( ... ) s2 = Spam(s1) results in two (probably almost identical) instances of Spam. Using list() to create a copy of a list is analogous, but we're used to thinking of list() as a converter rather than a constructor... Jeff Shannon Technician/Programmer Credit International -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda going out of fashion
Skip Montanaro wrote: >Jp> OTOH, maybe that's still trivial, it's only a multiuser network >Jp> chat server, after all. > > You cheated by not rewriting Twisted using only lambda. isn't twisted already written with lambdas only? why else would they call it "twisted"? -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda going out of fashion
"jfj" wrote: > Personally I'm not a fan of functional programming but lambda *is* useful > when I want to say for > example: > > f (callback=lambda x, y: foo (y,x)) > > I don't believe it will ever disappear. agreed. there's no reason to spend this christmas rewriting your programs, folks. I'm sure you all have better things to do ;-) cheers /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda going out of fashion
>> While I'm sure it can be done, I'd hate to see a non-trivial Python >> program written with lambda instead of def. Jp> What, like this? Jp> (lambda r,p,b:... Jp> OTOH, maybe that's still trivial, it's only a multiuser network Jp> chat server, after all. You cheated by not rewriting Twisted using only lambda. That's why I suggested pystone. While it's a very small program, it is pretty much self-contained. Skip -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda going out of fashion
[EMAIL PROTECTED] wrote: > o Why don't you just say all python can be written in equivalent java, your argumentation skills are awesome. -- http://mail.python.org/mailman/listinfo/python-list
Re: error problems for import some copora with nltk
[EMAIL PROTECTED] wrote: Hi, According to your advice, I installed the numeric library which is numarray-1.1.1.win32-py2.4.exe, but I got the error message as follows. Any help? frustrated... from nltk.corpus import gutenberg [...] import types, math, Numeric ImportError: No module named Numeric Numarray is not Numeric. You need to install Numeric, because NLTK doesn't use numarray. (As I understand it, numarray is intended as a replacement for Numeric, but modules/packages must be recoded to use it -- it doesn't happen automatically.) Jeff Shannon Technician/Programmer Credit International -- http://mail.python.org/mailman/listinfo/python-list
Re: Optional Static Typing
John Roth wrote: One of the comments on Artima asks a rather profound question: static typing is an answer. What's the question? (That's a paraphrase.) The answer that everyone seems to give is that it prevents errors and clarifies the program. It might just be me, but I thought it was to simplify code analysis and compilation. (That is, for the use of static typing in general, not for Python in particular.) Looking at C, it's doubtful error prevention and program clarification was a serious objective in the static typing system. It's more reasonable to conclude that C is statically typed because it allows the compiler to more easily allocate 1 vs 2 vs 8 bytes for a particular variable, and to make sure the proper addition opcodes get put down. Now whether this would be useful for Python is an open question. Many of the supposed advantages simply aren't there when you go to the discipline of writing a test and then writing exactly the code needed to make the test pass, and not one keystroke more. ... This isn't to say TDD is the be-all and end-all of correctness. Right. And unit tests don't do anything for people who don't use them. The question is, should Guido state "TDD is the one true way to program in Python.", or should concessions be made in the language design for those who don't "drink the TDD Kool-aide". So the conclusion here is that static typing is an attempt to make programming safe for people that shouldn't be programming in the first place. I rebut it thusly: "elitist bastard." One of the draws of Python is that it's welcoming to newcomers and programmers of all talents. You don't have to be an "uber-programmer" to use it and use it well. Should we hobble it to suit poor programmers? No. But that's no reason why it can't be made to be easier and safer to use for the hobbyist when it doesn't compromise usefulness for the power-programmer. (My opinion) Python shouldn't have a sign on the door saying: "You must be this 'leet to enter." Will static typing be a boon for Python? Is it necessary? Or is it the trailhead on the road to Hades? Only time will tell. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda going out of fashion
Thanks. :-) Two remarks. o One-liner fits the eyes & brains of a portion of people. o Why don't you just say all python can be written in equivalent java, can I assert that Guido doesn't want to get mixed with those mainstream>? -- http://mail.python.org/mailman/listinfo/python-list
RE: extract news article from web
Title: RE: extract news article from web Excel in later offices has the "web query" feature. (sorry about top posting) -Original Message- From: Steve Holden [mailto:[EMAIL PROTECTED]] Sent: quinta-feira, 23 de dezembro de 2004 12:59 To: python-list@python.org Subject: Re: extract news article from web Zhang Le wrote: > Thanks for the hint. The xml-rpc service is great, but I want some > general techniques to parse news information in the usual html pages. > > Currently I'm looking at a script-based approach found at: > http://www.namo.com/products/handstory/manual/hsceditor/ > User can write some simple template to extract certain fields from a > web page. Unfortunately, it is not open source, so I can not look > inside the blackbox.:-( > > Zhang Le > That's a very large topic, and not one that I could claim to be expert on, so let's hope that others will pitch in with their favorite techniques. Otherwise it's down to providing individual parsers for each service you want to scan, and maintaining the parsers as each group of designers modifies their pages. You might want to look at BeutifulSoup, which is a module for extracting stuff from (possibly) irregularly-formed HTML. regards Steve -- Steve Holden http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/ Holden Web LLC +1 703 861 4237 +1 800 494 3119 -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda going out of fashion
[EMAIL PROTECTED] wrote: I have this book called TEXT PROCESSING IN PYTHON by David Mertz on hand, it is a good book and in the first chapter it is really a show room for higher-order functions which I may now cite to remind you of the FLEXIBILITY of this keyword. I'm not exactly sure what you mean by "flexibility"; all of these examples can be written without lambdas: apply_each = lambda funs, args = []: map(apply, fns, [args]*len(fns)) def apply_each(fns, args=[]): return [fn(*args) for fn in fns] bools = lambda lst: mpa(truth, lst) def bools(lst): return [bool(x) for x in lst] bool_each = lambda fns, args = []: bools(apply_each(fns, args)) def bool_each(fns, args=[]): return bools(apply_each(fns, args)) conjoin = lambda fns, args = []: reduce(mul, bool_each(fns, args)) def conjoin(fns, args=[]): reduce(mul, bool_each(fns, args)) all = lambda fns: lambda arg, fns = fns: conjoin(fns, (arg,)) def all(fns): def _(arg): return conjoin(fns, (arg,)) return _ both = lambda f,g: all(f(f,g)) def both(f, g): return all(f(f,g)) all3 = lambda f,g,h: all((f,g,h)) def all3(f, g, h): return all((f,g,h)) and_ = lambda f,g: lambda x, f=f, g=g: f(x) and g(x) def and_(f, g): def _(x): return f(x) and g(x) return _ disjoin = lambda fns, args = []: reduce(add, bool_each(fns, args)) def disjoin(fns, args=[]): return reduce(add, bool_each(fns, args)) some = lambda fns: lambda arg, fns = fns: disjoin(fns, (arg,)) def some(fns): def _(arg): return disjoin(fns, (arg,)) return _ either = lambda f,g: some((f,g)) def either(f, g): return some((f,g)) anyof3 = lambda f,g,h: some((f,g,h)) def anyof3(f, g, h): return some((f,g,h)) compose = lambda f,g: lambda x, f=f, g=g: f(g(x)) def compose(f, g): def _(x): return f(g(x)) return _ compose3 = lambda f,g,h: lambda x, f=f, g=g, h=j: f(g(h(x))) def compose3(f, g, h): def _(x): return f(g(h(x))) return _ ident = lambda x:x def ident(x): return x Steve -- http://mail.python.org/mailman/listinfo/python-list
Re: PHP vs. Python
"Eric Pederson" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > My beloved Python-oriented webhost doesn't currently support Mod-Python You can always do what I did. I wrote the backend of my app in Python and run it as an XML-RPC server. I did the front end in PHP using the Smarty template tool. (The actual templates themselves were stored in the Python server and grabbed via XML-RPC). Effectively PHP/Smarty were formatting XML-RPC results, delivered as Python dicts which turn into Smarty arrays (and it all works fine with nested lists and dicts). That way I got the best of both worlds, didn't have to get mod-python installed, and *my opinion* is that Smarty is the nicest template tool I have tried in Python or PHP. Roger -- http://mail.python.org/mailman/listinfo/python-list
Problem with ./configure (py2.3.4)
I have problem with re-install python 2.3.4, when I execute ./configure is appear one message in config.log, follow below : configure:1710: gccconftest.cc >&5 gcc: installation problem, cannot exec `cc1plus': No such file or directory configure:1713: $? = 1 My gnu/linux is 2.6.8-1-386(debian/sarge) Somebody could help me? Regards, -- Andre Amram Duque Analista de Sistemas VARIG Brazilian Airlines - RIONS GGTI - Gerencia Geral de Tecnologia da Informacão Tel.: + 55-0XX-21-3814-5920 Fax:: + 55-0XX-21-3814-5796 e-mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Optional Static Typing
<[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Adding Optional Static Typing to Python looks like a quite complex thing, but useful too: http://www.artima.com/weblogs/viewpost.jsp?thread=85551 One of the comments on Artima asks a rather profound question: static typing is an answer. What's the question? (That's a paraphrase.) The answer that everyone seems to give is that it prevents errors and clarifies the program. I'm not convinced that it's all that effective at either objective. My viewpoint on this is that of someone who generally uses test first programming (as in Test Driven Development or Extreme Programming). Many of the supposed advantages simply aren't there when you go to the discipline of writing a test and then writing exactly the code needed to make the test pass, and not one keystroke more. Most of the kinds of error that static typing is supposed to catch simply don't persist for more than a minute when you do test driven development. This isn't to say TDD is the be-all and end-all of correctness. Formal methods and formal inspections both have very good reputations. In fact, the technique with the best reputation is embodied in a sign that was on the wall of every office of the old IBM: Think! So let's look a bit deeper. As far as I remember, static typing came out of the formal methods work in the '70s by people like Djikstra, Hoar and Wirth (to name only a few.) The thing is, if you properly use the formal program derivation methods they advocated, then you don't need it: your program will be as correct as it's possible to get short of your being promoted to godhood. So the conclusion here is that static typing is an attempt to make programming safe for people that shouldn't be programming in the first place. This may sound a bit cynical, but most real uber-programmers have either Lisp or Smalltalk in their backgrounds, and frequently both one. Neither of those languages have static typing, and they simply don't need it. So if the problem is reducing errors, then maybe we should be working on the places where errors show up. Another point that's sometimes raised is that it's useful to provide type information via reflection. I used to think that was a valid concern until I started work on PyFit. I had to put a rather simplistic metadata facility into the program to substitute for not having type information, and I found that it was incredibly useful for other things that you can't get from reflection on type data. John Roth Bear hugs, bearophile -- http://mail.python.org/mailman/listinfo/python-list
copying builtin types (WAS: list IndexError)
Grant Edwards wrote:
I would have guessed that calling list() on a list
was a noop. I would be wrong. Surprised, but wrong.
I guess it's probably worth pointing out that most builtin mutable types
can be copied using the type constructor:
py> def check(obj):
... copy = type(obj)(obj)
... print id(obj), id(copy)
... return copy
...
py> check([1, 2])
18124312 18124752
[1, 2]
py> check({1:2})
18102720 18126720
{1: 2}
py> check(set([1, 2]))
9675672 9675504
set([1, 2])
For immutable types, this is indeed basically a noop:
py> check(12)
3303412 3303412
12
py> check('12')
18120128 18120128
'12'
py> check((1, 2))
18122552 18122552
(1, 2)
Steve
--
http://mail.python.org/mailman/listinfo/python-list
Re: Lambda going out of fashion
I have this book called TEXT PROCESSING IN PYTHON by David Mertz on hand, it is a good book and in the first chapter it is really a show room for higher-order functions which I may now cite to remind you of the FLEXIBILITY of this keyword. ''' combinatorial.py from operator import mul, add, truth apply_each = lambda funs, args = []: map(apply, fns, [args]*len(fns)) bools = lambda lst: mpa(truth, lst) bool_each = lambda fns, args = []: bools(apply_each(fns, args)) conjoin = lambda fns, args = []: reduce(mul, bool_each(fns, args)) all = lambda fns: lambda arg, fns = fns: conjoin(fns, (arg,)) both = lambda f,g: all(f(f,g)) all3 = lambda f,g,h: all((f,g,h)) and_ = lambda f,g: lambda x, f=f, g=g: f(x) and g(x) disjoin = lambda fns, args = []: reduce(add, bool_each(fns, args)) some = lambda fns: lambda arg, fns = fns: disjoin(fns, (arg,)) either = lambda f,g: some((f,g)) anyof3 = lambda f,g,h: some((f,g,h)) compose = lambda f,g: lambda x, f=f, g=g: f(g(x)) compose3 = lambda f,g,h: lambda x, f=f, g=g, h=j: f(g(h(x))) ident = lambda x:x ''' And some other lambda function usage is when they are treated like objects, they can also fit in generators... THIS IS ART. Well, some may argue that it is hard for people to maintain these codes, put the problem to Haskell people and see how they respond(at least you don't need to scroll up and down...) Oh! So when did python adopt simplicity rather than verbosity? Q: It simply doesn't FIT. A: OK, OK, get all these map, filter stuff away, and go python, go and get mixed with them. -- http://mail.python.org/mailman/listinfo/python-list
Re: list Integer indexing dies??
Ishwor wrote: On Thu, 23 Dec 2004 13:33:16 -0300, Batista, Facundo <[EMAIL PROTECTED]> wrote: [Ishwor] #- > What should 035[0] cough up? Be carefull it should #- #- >>>035[0] #- 3 # my own opinion. #- #- > cough up the same as 29[0]. #- #- >>>29[0] #- 2 #again my own opinion Be aware that: 035 == 29 True Yup. Octal variation of 29. But that wasn't my point. Yes, but worse yet: py> 035 is 29 True So 035 and 29 refer to exactly the same object. They're just syntactic variants. So how's Python to know which syntactic variant you want the index taken from? AFAIK that information is not stored in a Python int or you wouldn't get results like: py> 035 29 Steve -- http://mail.python.org/mailman/listinfo/python-list
Re: list IndexError
On Thu, 23 Dec 2004 13:57:55 -0300, Batista, Facundo <[EMAIL PROTECTED]> wrote: > > > [Steven Bethard] > > #- True, true. Maybe you could lobby for copy as a builtin in > #- Python 3000? > > That's a good idea to me. But copy() as a builtin is not clear if it's > shallow or deep. IMHO its preferable to use shallow one as the built-in because deep is expensive op. for CPU. ~;-) > > . Facundo > > . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [snip] -- cheers, Ishwor Gurung -- http://mail.python.org/mailman/listinfo/python-list
RE: list IndexError
Title: RE: list IndexError [Steven Bethard] #- True, true. Maybe you could lobby for copy as a builtin in #- Python 3000? That's a good idea to me. But copy() as a builtin is not clear if it's shallow or deep. . Facundo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ADVERTENCIA. La información contenida en este mensaje y cualquier archivo anexo al mismo, son para uso exclusivo del destinatario y pueden contener información confidencial o propietaria, cuya divulgación es sancionada por la ley. Si Ud. No es uno de los destinatarios consignados o la persona responsable de hacer llegar este mensaje a los destinatarios consignados, no está autorizado a divulgar, copiar, distribuir o retener información (o parte de ella) contenida en este mensaje. Por favor notifíquenos respondiendo al remitente, borre el mensaje original y borre las copias (impresas o grabadas en cualquier medio magnético) que pueda haber realizado del mismo. Todas las opiniones contenidas en este mail son propias del autor del mensaje y no necesariamente coinciden con las de Telefónica Comunicaciones Personales S.A. o alguna empresa asociada. Los mensajes electrónicos pueden ser alterados, motivo por el cual Telefónica Comunicaciones Personales S.A. no aceptará ninguna obligación cualquiera sea el resultante de este mensaje. Muchas Gracias. -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda going out of fashion
Jp Calderone wrote: On Thu, 23 Dec 2004 10:19:33 -0600, Skip Montanaro <[EMAIL PROTECTED]> wrote: While I'm sure it can be done, I'd hate to see a non-trivial Python program written with lambda instead of def. What, like this? [snip horrible lambda expression] OTOH, maybe that's still trivial, it's only a multiuser network chat server, after all. Bad Jp! No biscuit! ;) Steve -- http://mail.python.org/mailman/listinfo/python-list
Re: list IndexError
Grant Edwards wrote: Wouldn't the clearest way to get a copy would be to do something like: copy(lst) # I still think copy.copy() is a bit verbose... True, true. Maybe you could lobby for copy as a builtin in Python 3000? Steve -- http://mail.python.org/mailman/listinfo/python-list
Re: list IndexError
On 2004-12-23, Steven Bethard <[EMAIL PROTECTED]> wrote: >> Ah, my mistake, I missed the [:] after the source argument >> that was taking a copy... which brings up the question, how >> many other people would miss it? > > Too many. This is why I greatly prefer > > list(lst) To me, that's just as non-obvious. I would have guessed that calling list() on a list was a noop. I would be wrong. Surprised, but wrong. > to > > lst[:] > > It's also clearer to me. Do I really want a "slice" of the > list? No, I want a list copy of the list... Wouldn't the clearest way to get a copy would be to do something like: copy(lst) # I still think copy.copy() is a bit verbose... or lst.copy() # doesn't exist, but I think it should :) -- Grant Edwards grante Yow! I had pancake makeup at for brunch! visi.com -- http://mail.python.org/mailman/listinfo/python-list
Re: list Integer indexing dies??
On Thu, 23 Dec 2004 13:33:16 -0300, Batista, Facundo <[EMAIL PROTECTED]> wrote: > > > [Ishwor] > > #- > What should 035[0] cough up? Be carefull it should > #- > #- >>>035[0] > #- 3 # my own opinion. why 3? The reason we get 3 and not 0 here is the *fact* that Python knows that its an octal rep. and not decimal ;-) 035[2] could return error here. Same for hex. No idea for binary. ~;-( > #- > #- > cough up the same as 29[0]. > #- > #- >>>29[0] > #- 2 #again my own opinion since it's decimal its fine to get 2 which is at offset 0. [snip] -- cheers, Ishwor Gurung -- http://mail.python.org/mailman/listinfo/python-list
Re: list Integer indexing dies??
On Thu, 23 Dec 2004 13:33:16 -0300, Batista, Facundo <[EMAIL PROTECTED]> wrote: > > > [Ishwor] > > #- > What should 035[0] cough up? Be carefull it should > #- > #- >>>035[0] > #- 3 # my own opinion. > #- > #- > cough up the same as 29[0]. > #- > #- >>>29[0] > #- 2 #again my own opinion > > Be aware that: > > >>> 035 == 29 > True > >>> Yup. Octal variation of 29. But that wasn't my point. > > . Facundo > > . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . > . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . > . . . . . . . . . . . . . . . > [snip] -- cheers, Ishwor Gurung -- http://mail.python.org/mailman/listinfo/python-list
RE: list Integer indexing dies??
Title: RE: list Integer indexing dies?? [Ishwor] #- > What should 035[0] cough up? Be carefull it should #- #- >>>035[0] #- 3 # my own opinion. #- #- > cough up the same as 29[0]. #- #- >>>29[0] #- 2 #again my own opinion Be aware that: >>> 035 == 29 True >>> . Facundo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ADVERTENCIA. La información contenida en este mensaje y cualquier archivo anexo al mismo, son para uso exclusivo del destinatario y pueden contener información confidencial o propietaria, cuya divulgación es sancionada por la ley. Si Ud. No es uno de los destinatarios consignados o la persona responsable de hacer llegar este mensaje a los destinatarios consignados, no está autorizado a divulgar, copiar, distribuir o retener información (o parte de ella) contenida en este mensaje. Por favor notifíquenos respondiendo al remitente, borre el mensaje original y borre las copias (impresas o grabadas en cualquier medio magnético) que pueda haber realizado del mismo. Todas las opiniones contenidas en este mail son propias del autor del mensaje y no necesariamente coinciden con las de Telefónica Comunicaciones Personales S.A. o alguna empresa asociada. Los mensajes electrónicos pueden ser alterados, motivo por el cual Telefónica Comunicaciones Personales S.A. no aceptará ninguna obligación cualquiera sea el resultante de este mensaje. Muchas Gracias. -- http://mail.python.org/mailman/listinfo/python-list
Re: Improving Python (was: Lambda going out of fashion)
Skip Montanaro wrote: > >Keith> My personal gripe is this. I think the core language, as of 2.3 >Keith> or 2.4 is very good, has more features than most people will ever >Keith> use, and they (Guido, et al.) can stop tinkering with it now and >Keith> concentrate more on the standard libraries. > > What keeps you from being part of the "et al"? as I've proven from time to time, joining the "et al" and *not* tinkering with the language doesn't mean that the language stays where it is. (I've said it before, and I'll say it again: native unicode and generators are the only essential additions I've seen since 1.5.2, with properties and sub- classable C types sharing a distant third place. the rest of the stuff has had zero impact on my ability to write solid code in no time at all, and negative impact on my ability to download stuff that others have written and expect it to work in any Python version but the latest...) -- http://mail.python.org/mailman/listinfo/python-list
Re: test
[Per Erik Stendahl <[EMAIL PROTECTED]>] > sdfdsafasd Generally speaking, yes, but not if you're concerned about Pythons before 1.5.2 too. If you are, a reasonable workaround is: try: sdfdsafasd except NameError: pass else: True = None is None and 1 != 2 False = None is not None or 1 == 2 Even so, it's rumored even that doesn't work under HP-UX in some Asian installations. Disabling threads may help in such cases -- although in a few of them, using floating-point instead of strings actually works much better. For more information, do "man sdfdsafasd" on a Tuesday, but not in a month containing "r". -- http://mail.python.org/mailman/listinfo/python-list
Re: Lambda going out of fashion
On Thu, 23 Dec 2004 10:19:33 -0600, Skip Montanaro <[EMAIL PROTECTED]> wrote:
>
> >> readability. Pythonic lambdas are just syntactic sugar in practice,
>
> Paul> Actually it's the other way around: it's named functions that are
> Paul> the syntactic sugar.
>
> While I'm sure it can be done, I'd hate to see a non-trivial Python program
> written with lambda instead of def.
What, like this?
(lambda
r,p,b:(r.listenTCP(6665,(type('F',(p.Factory,object),{'protocol':(type('P',(b.LineReceiver,object),{'connectionMade':lambda
s:s.factory.c.append(s),'lineReceived':lambda
s,m:(s.factory.m(m),None)[1]})),'c':[],'m':lambda s,m:[c.sendLine(m)for c in
s.c]}))()),r.run()))(*(lambda
p,i:(i(p,'reactor'),i(p,'protocol'),i('twisted.protocols.','basic')))('twisted.internet.',lambda
a,b:__import__(a+b,None,None,b)))
OTOH, maybe that's still trivial, it's only a multiuser network chat server,
after all.
plumbing-the-depths-ly,
Jp
--
http://mail.python.org/mailman/listinfo/python-list
Re: Keyword arguments - strange behaviour?
Fuzzyman wrote: Steven Bethard wrote: So, one of my really common use cases that takes advantage of the fact that default parameters are evaluated at function definition time: def foo(bar, baz, matcher=re.compile(r'...')): ... text = matcher.sub(r'...', text) ... Sure.. but you also gave an example of an alternative that was complex, Interesting. I would have thought that my example was pretty simple. Maybe it would be helpful to generalize it to: def foo(bar, baz, spam=badger(x, y, z)): ... All it does is use a default value that was produced by a function call. I'm surprised you haven't run into this situation before... Of course, what is complex or simple is a matter of personal opinion. I use this pattern so often that it's quite simple to me, but I guess I can understand that if you don't use such a pattern, it might seem foreign to you. Steve -- http://mail.python.org/mailman/listinfo/python-list
